GF100: Seine Architektur und Technologie

[Gipsel]

http://www.beyond3d.com/content/reviews/55
NVIDIA Fermi GPU and Architecture Analysis
Am besten finde ich ja fast diese Passage:
GPU makers in general and NVIDIA in particular would like us to call these cores, but if we start counting SIMD lanes as cores at Beyond3D we might as well give up and hand the keys to Sontin.Na was meinst Du LovesuckZ, zählt das als "honorable mention"? :lol:

[LovesuckZ]

Na was meinst Du LovesuckZ, zählt das als "honorable mention"? :lol:

Ich überleg ja meine Ban-Message in die Signatur zu packen. Aber das ist dann doch irgendwie zu ironisch für ein Forum, dass von 80% AMD Fanboys besucht wird, die jeden nVidia Thread zu müllen und noch mehr unsinn schreiben als hier. Komisch, komisch diese nicht deutschen. :freak:


You have been banned for the following reason:
If I want an IHV evangelist on the forum, I'll ask one of the pros to login, they at least have insight to provide. It's clear you're incapable of anything more than base shilling for NV/trolling of the competition, so take that somewhere else.

Date the ban will be lifted: Never


Ich finde es erstaunlich, dass sie behaupten, dass die TS komplett durch die Recheneinheiten erledigt werden, aber nVidia in deutlicher Form bestreitet von dedizierter Hardware in der (dedizierten) Polymorphunit spricht...

To be more precise, we think that on [GF100], tessellation is entirely handled on the ALUs – the first phase which deals with tessellation factor processing/conditioning being a native fit, since it uses 32-bit FP math, and the second, which actually dices the domain and uses a 16-bit fraction fixed-point format, leveraging the more than adequate INT throughput available. It's possible that there are actually 16 separate dedicated hardware blocks implementing this stage, but we're not sure how beneficial it would be, since it would require extra wiring/routing, as well as some extra transistors (not too many, mind you, a tessellator is a rather simple/cheap thing overall).

[deekey777]

Zwischen "Behaupten" und "Denken" ist ein Riesenunterschied.

[LovesuckZ]

Zwischen "Behaupten" und "Denken" ist ein Riesenunterschied.

Das weiß ich. Nur schreiben sie es nieder, also ist es eine Behauptung (=These).
Als Laie sehe ich keine Erklärung in dem Text, die vorallem so einleuchtend ist, dass AMD nicht auch auf die Recheneinheiten hätte gehen würden.

Es gibt das Paper von der HPG2010 (http://www.google.de/url?sa=t&source=web&cd=1&ved=0CBkQFjAA&url=http%3A%2F%2Fwww.highperformancegraphics.org%2Fmedia%2FHot3D%2FHPG2010_Hot3D _NVIDIA.pdf&ei=n3rDTOvBApCaOoa31MsL&usg=AFQjCNFfUoCkNR2v1x3YlM_KWXgeXUqxaw&sig2=OS2dakXVKpHut7_j4zpQNg), indem sie genau diese Umsetzung als unpassend abgelehnt haben. Da ich aber leider wegen "IHV evangelist (ich lach immer noch)" dort gebannt wurde, kann ja jemand mal nachfragen. Vielleicht liefern sie eine vernünftige Erklärung (ergo Argumente für die These).

/edit: Müssen denn Dreiecke bei nVidia wirklich 8 Pixel umfassen? Laut dem Paper sollten sie so klein wie möglich sein, um 100% Auslastung zu ermöglichen.

[deekey777]

Wenn man etwas behauptet, dann belegt man das mit Tatsachen. Ich sehe da keine Tatsachen, sondern Vermutungen, auch wenn sie schlüssig erscheinen.
Ich merke, dass es spät ist, denn irgendwie finde ich in der HPG-Präsentation keine Aussage darüber, dass die Verlagerung der FF-Aufgaben (TU) auf die Shader ein Nachteil ist.

[Gipsel]

@LovesuckZ:
Ich überleg ja meine Ban-Message in die Signatur zu packen. Aber das ist dann doch irgendwie zu ironisch für ein Forum, dass von 80% AMD Fanboys besucht wird, die jeden nVidia Thread zu müllen und noch mehr unsinn schreiben als hier. Komisch, komisch diese nicht deutschen.Nun, vielleicht sollte Dir das aber auch zu denken geben, wie Du auf das eher technisch orientierte Publikum dort gewirkt hast. Du hast ja längst nicht so lange und oft gepostet wie hier und ich muß zugeben, daß Du Dich dort sogar noch relativ zurückgehalten hast (zumindest anfangs, später bist Du wohl etwas mutiger geworden). Trotzdem hast Du jetzt dort die Rote(?) Karte gesehen (und es sogar in einen Artikel geschafft ;)).

Vielleicht solltest Du das nicht einfach so abtun ("alles AMD Fanboys") sondern mal drüber nachdenken? Nur mal so als kleiner und ehrlich wohlgemeinter Ratschlag. Denn ich will Dir ja auch nichts Böse oder so, ich bin primär an einer sachlichen Diskussion interessiert. Polemik kann ich im Notfall selber ganz gut. :)
On topic:
Ich finde es ja recht interessant, daß die mit dem Artikel fast mehr Licht auf die Cypress-Tesselation geworfen haben als auf die Fermis. Insbesondere scheint der Tessellationsdurchsatz nicht strikt auf 1/3 limitiert zu sein (sie erreichen ~60% des Wertes ohne Tess) und tatsächlich hauptsächlich vom mangelnden Puffergrößen limitiert zu sein (wo die HD6800er ein wenig abhelfen).

Und das Fazit sollten sich auch mal alle genau durchlesen! ;)

[LovesuckZ]

Wenn man etwas behauptet, dann belegt man das mit Tatsachen. Ich sehe da keine Tatsachen, sondern Vermutungen, auch wenn sie schlüssig erscheinen.

These = Behauptung != Tatsache.


Ich merke, dass es spät ist, denn irgendwie finde ich in der HPG-Präsentation keine Aussage darüber, dass die Verlagerung der FF-Aufgaben (TU) auf die Shader ein Nachteil ist.

Seite 10, Seite 14.

@LovesuckZ:
Nun, vielleicht sollte Dir das aber auch zu denken geben, wie Du auf das eher technisch orientierte Publikum dort gewirkt hast. Du hast ja längst nicht so lange und oft gepostet wie hier und ich muß zugeben, daß Du Dich dort sogar noch relativ zurückgehalten hast (zumindest anfangs, später bist Du wohl etwas mutiger geworden). Trotzdem hast Du jetzt dort die Rote(?) Karte gesehen (und es sogar in einen Artikel geschafft ;)).

Vielleicht solltest Du das nicht einfach so abtun ("alles AMD Fanboys") sondern mal drüber nachdenken? Nur mal so als kleiner und ehrlich wohlgemeinter Ratschlag. Denn ich will Dir ja auch nichts Böse oder so, ich bin primär an einer sachlichen Diskussion interessiert. Polemik kann ich im Notfall selber ganz gut. :)


Ich habe nichts gemacht. Außer Dave Baumann gefragt, wieso die Filterqualität gesenkt wurde. Naja und, dass AMD irgendwas für den PC Markt machen sollte. Z.B. eine eigene Terrain-Tessellation-Demo anbieten, um ihr Statement zu überprüfen. Anscheinend war meine Mindermeinung in dem Forum wohl nicht geduldet...
Und ja, das Forum besteht heutzutage nur noch bedingt aus einem "eher technisch orientiertem Publikum".


Und das Fazit sollten sich auch mal alle genau durchlesen! ;)

Wenn man sowas liest, dann muss man selbst als Laie den Kopfschütteln:
it's not a monumental departure on any front (even the GEOD, which we like quite a bit, doesn't qualify for that).

Wenn man den Schritt von serieller zu paralleler Abarbeitung der Geometrie schafft, dann ist dies ein "monumental departure". Diese Aussage ist auch im Zuge von AMD's Implementierung reinster Hohn.

[mapel110]

Hm, Fermi ist also scheiße und die Software-Support-Abteilung bei nvidia reißt es raus. Najo, Software-Firma halt, wie sie schon letztes Jahr selbst gesagt haben.

Wenn man sich die ganzen synthetischen Balken anschaut, kann man sich als Laie wirklich nur fragen, was ATI so langsam macht.

[Gipsel]

Wenn man sowas liest, dann muss man selbst als Laie den Kopfschütteln:

Wenn man den Schritt von serieller zu paralleler Abarbeitung der Geometrie schafft, dann ist dies ein "monumental departure". Diese Aussage ist auch im Zuge von AMD's Implementierung reinster Hohn.
Siehst Du, genau das ist Dein Problem. Du scheinst nicht fähig, den Artikel oder auch nur die Zusammenfassung in der Gesamtheit aufzunehmen sondern greifst Dir einen Halbsatz raus, der Dir nicht paßt, und fängst das Geflame an. Das ist nicht hilfreich. Und daß B3D gerade in dem von Dir kritisierten Abschnitt den GF100 ausdrücklich lobt, scheint Dir irgendwie entgangen zu sein.

Edit:
Hier mal der volle Abschnitt, um den es LovesuckZ ging:
So, is GF100 a new NV30? Absolutely not: it's great hardware in our opinion that performs well in general and implements some interesting architectural choices. Is the architecture an orgasmic changer of the computing landscape? Absolutely not, irrespective of what you might've been told: it's not a monumental departure on any front (even the GEOD, which we like quite a bit, doesn't qualify for that).Für alle, die den Artikel nicht gelesen haben, GEOD ist B3D-Slang für "geometry engine of doom".
Ehrlich hesagt, würde ich das bald genau so sehen. Fermi ist eben nicht die Umsetzung des Pomegranate-Konzepts, auch wenn sicher einige Ideen daher stammen. Aber letztendlich ist es "nur" eine Setupkonfiguration mit maximal 4 Dreiecken pro Takt (wobei laut B3D untesselliert Fermi auch nur unter 1 Tri/clock kann und zum Teil deutlich hinter Cypress liegt). Pomegranate ging konzeptionell deutlich weiter (beschränkte sich längst nicht nur auf den Part vor den Rasterizern).

[Gipsel]

Hm, Fermi ist also scheiße und die Software-Support-Abteilung bei nvidia reißt es raus. Najo, Software-Firma halt, wie sie schon letztes Jahr selbst gesagt haben.
Na so ganz das sagen sie nicht. Fermi sieht durch die Software-Seite (die ja auch zum Produkt gehört!) nur etwas besser aus, als man es beim Vergleich der reinen Hardwarefähigkeiten erwarten würde.
Genau das sage ich übrigens schon seit RV770-Zeiten ;)
Wenn man sich die ganzen synthetischen Balken anschaut, kann man sich als Laie wirklich nur fragen, was ATI so langsam macht.
Es gibt noch ein oder zwei mehr Aspekte (dort nicht angesprochen/getestet), bei denen nvidia etwas im Vorteil ist. Aber im Prinzip ist es schon ein wenig so, da hast Du recht.
Am Artikel war übrigens auch gut, daß mal die These vom voll auf GPGPU ausgerichtetem Design etwas geradegerückt wurde (wobei mir die Entscheidung für half rate DP immer noch schleierhaft ist). Die Tests der atomic operations hatte ich so auch noch nicht gesehen (wußte aber, daß Cypress bei local atomics deutlich schneller ist).

[LovesuckZ]

Siehst Du, genau das ist Dein Problem. Du scheinst nicht fähig, den Artikel oder auch nur die Zusammenfassung in der Gesamtheit aufzunehmen sondern greifst Dir einen Halbsatz raus, der Dir nicht paßt, und fängst das Geflame an. Das ist nicht hilfreich. Und daß B3D gerade in dem von Dir kritisierten Abschnitt den GF100 ausdrücklich lobt, scheint Dir irgendwie entgangen zu sein.

Ich habe den Artikel gelesen. Und wenn mir jemand nach der ausführlichen Darstellung dann schlussfolgert, dass das Durchbrechen der einschränkenden, seriellen Geometriepipeline kein fundenmentaler Schritt nach vorne wäre, dann ist dies keine objektive Schlussfolgerung, sondern eine politisch, beeinflussende Meinung.*
Das Design von GF100 ist für weitläufigen Einsatz von vielen, kleinen Dreiecken ausgelegt. Nur deswegen ist es möglich auch die Vorteile von Tessellation im vernünftigen Maße umzusetzen: Geringere Polymodelle, hoher Tessellationfaktor, vernünftiges adaptives LoD.

Ist es nicht bezeichnend, dass AMD im neuen Deux Ex Spiel für die Charaktermodelle ein Grundmodell mit 6000 oder 7000 Polygone verwendet und diese dann auf sagenhafte 17000 hochskaliert?

Du kannst gerne darlegen, warum das Grundmodell aus 7000 Polys bestehen sollte. Als Laie dachte ich, dass man erst Recht mit weniger auskommen möchte.

*Achja: Und das Pufferproblem hat nVidia auch aufgrund der parallen Abarbeitung in deutlich reduzierter Form, weil eben mehrere Einheiten sich die Erzeugung der Dreiecke widmen und somit auch einen geringeren Pufferbedarf benötigen.

[Gipsel]

Ich habe den Artikel gelesen. Und wenn mir jemand nach der ausführlichen Darstellung dann schlussfolgert, dass das Durchbrechen der einschränkenden, seriellen Geometriepipeline kein fundenmentaler Schritt nach vorne wäre, dann ist dies keine objektive Schlussfolgerung, sondern eine politisch, beeinflussende Meinung.
Nach irgendeiner Definition würden wir dann ständig Schranken durchbrechen :rolleyes:
Regst Du wirklich auf, weil die da dem GF100 keinen "orgasmic change of the computing landscape" zubilligen? Sorry, aber das ist es wirklich nicht. Es ist ein Schritt am Anfang weiterer.
Das ist zwar eine Milchmädchenrechnung, aber manchmal ganz illustrativ:
2 Millionen Pixel pro Frame * 1 Tri/Pixel * 120 fps = 240 MTri/s.
Das Design von GF100 ist für weitläufigen Einsatz von vielen, kleinen Dreiecken ausgelegt.Nein, das stimmt so nicht. Ich denke, Du hast den Artikel gelesen? Hohe Polylast (ohne Tess) handhabt ein Cypress dort (Damian Triolet war wohl etwas besser darin, Bedingungen zu finden, wo Fermi etwas mehr schafft, zeigt aber, das Fermi längst nicht immer soo schnell bei Geometrie ist) mit ~80% höherer Performance als eine GTX470, auch (oder gerade) bei 1 Pixel Dreiecken (843 vs. 466 Millionen Dreiecke/s).

http://www.beyond3d.com/images/reviews/Slimer-arch/TriSetupDepthOnlyNoTess-big.jpg

Nur deswegen ist es möglich auch die Vorteile von Tessellation im vernünftigen Maße umzusetzen: Geringere Polymodelle, hoher Tessellationfaktor, vernünftiges adaptives LoD.Du vermengst da was so lange, bis es keinen Sinn mehr ergibt.

Achja: Und das Pufferproblem hat nVidia auch aufgrund der parallen Abarbeitung in deutlich reduzierter Form, weil eben mehrere Einheiten sich die Erzeugung der Dreiecke widmen und somit auch einen geringeren Pufferbedarf benötigen.Das funktioniert nicht ganz so ;)

[AnarchX]

zeigt aber, das Fermi längst nicht immer soo schnell bei Geometrie ist) mit ~80% höherer Performance als eine GTX470, auch (oder gerade) bei 1 Pixel Dreiecken (843 vs. 466 Millionen Dreiecke/s).

Das sieht wohl eher danach aus, dass man etwas gefunden hat, wo nur ein GPC ausgelastet wird.
Fragt sich in welchen Anwendungen so etwas passieren könnte?

[Aquaschaf]

Aber letztendlich ist es "nur" eine Setupkonfiguration mit maximal 4 Dreiecken pro Takt (wobei laut B3D untesselliert Fermi auch nur unter 1 Tri/clock kann und zum Teil deutlich hinter Cypress liegt). Pomegranate ging konzeptionell deutlich weiter (beschränkte sich längst nicht nur auf den Part vor den Rasterizern).

Sie schreiben doch dass das eine künstliche Beschränkung ist - eine Quadro erreicht ohne Tesselation die selbe Tri/clock-Rate wie eine Geforce oder Tesla mit Tesselation.

[Gipsel]

Sie schreiben doch dass das eine künstliche Beschränkung ist - eine Quadro erreicht ohne Tesselation die selbe Tri/clock-Rate wie eine Geforce oder Tesla mit Tesselation.
Okay, muß man also eine Quadro kaufen, um die volle Setup-Rate zu bekommen (die dann gut 2x so schnell wäre wie ein Cypress, ist dann aber auch noch ein wenig mager für eine Revolution, den Faktor hat Cypress in anderen Aspekten auch als Vorteil ;)).

[deekey777]

Welchen Einfluß hat Tri-Setup auf GPU-Computing?

[Gipsel]

Welchen Einfluß hat Tri-Setup auf GPU-Computing?
Da fällt mir spontan nichts ein. Ein indirekter Einfluß könnte sein, daß natürlich bestimmte Kommunikationswege nicht nur für die Geometrie-Engine genutzt werden können, sondern für alle Aufgaben zur Verfügung stehen. Aber das ist dann nichts, was man so direkt dem Setup zuordnen könnte sondern eher der generellen Auslegung. Deswegen ist der von LovesuckZ kritisierte Abschnitt m.M. auch ein kleiner Seitenhieb auf Charlie (Auslegung auf Compute mit Grafik später drangeklatscht), aber solche Feinheiten der Deutungsmöglichkeit hat LS wohl übersehen.

[AnarchX]

Whitepaper zu den Dual Copy Engines auf GF100: http://www.nvidia.com/docs/IO/40049/Dual_copy_engines.pdf

http://www.geeks3d.com/20101024/nvidia-quadro-dual-copy-engines-for-real-gpu-asynchronous-texture-transferts-explained/

Damit wurde doch auch das verbesserte Speichermanagment für die GeForce-Karten realisiert?

[LovesuckZ]

Wird es auch für Geforce angeboten? Laut dem Comments bei Geeks3d.com angeblich nicht.

[AnarchX]

Auf GeForce 400 könnte wohl nur eine DMA Engine aktiv sein, was aber immer noch ein Fortschritt gegenüber den offenbar DMA-losen GF8-GF200 GPUs ist.

Mir stellt sich die Frage, ob man damit vielleicht auch etwas in Bezug auf schnelles SFR machen könnte.

[Coda]

Fermi hat zwei DMA-Einheiten, kann also gleichzeitig vom Host lesen und schreiben. Davor gab's nur eine.

[Bucklew]

Fermi hat zwei DMA-Einheiten, kann also gleichzeitig vom Host lesen und schreiben. Davor gab's nur eine.
Ist bei den GeForce-Karten aber eine deaktiviert.

[Coda]

Kann ich mir kaum vorstellen, weil sie dadurch Performance verschenken würden - auch in Spielen.

Vermutlich ist nur kein gleichzeitiges Lesen und Schreiben erlaubt.

[Gipsel]

http://beyond3d.com/content/reviews/55/7

Gipsel,

Da Du schon mitliest, aus dem B3D Artikel (link oben):
Ich würde zur ersten Variante tendieren.
Wenn die Vermutung von AlexV da stimmen würde, könnten auch die 32bit Integer Multiplikationen wohl nur in einem der SMs ausgeführt werden (der Multiplier einer DP-Einheit ist locker breit genug dafür, der einer SP-Einheit aber nicht). Zumindest offiziell besteht aber für die 32Bit-Integer-Multiplikation keine solche Beschränkung des Dual-Issues wie für DP.
Aber wenn ich die Tests richtig lese, dann sind aber auch alle 32Bit Integer Operationen (sogar ADD, da ist ein Cypress potentiell 5 mal so schnell!) auch nur half rate.
David Kanter schrieb bei RealworldTech mal dazu, daß die ALUs für 32Bit Int jeweils 2 Takte benötigen, warum auch immer. Da wäre es mal interessant zu sehen, wie das bei einer GF104 aussieht. So richtig klar ist momentan nicht, was nvidia da mit den ALUs genau macht. Aber eins kann man sagen, die Angaben im GF100-Whitepaper dazu stimmen entweder nicht, da funktioniert etwas nicht so wie es soll, oder der Treiber bremst da auch an Integer-Sachen rum (Aber warum sollte das so sein? Das wird sogar für normalen Consumerkram benötigt). Aber es zeigt mir wieder mal, daß man den Herstellerangaben nicht unbedingt vertrauen sollte (genau wie bei dem GPC-Kram ;)), bei den Blockdiagrammen und Beschreibungen hat anscheinend das Technical Marketing seine Finger doch etwas zuviel im Spiel.

[aths]

David Kanter schrieb bei RealworldTech mal dazu, daß die ALUs für 32Bit Int jeweils 2 Takte benötigen, warum auch immer.Vermutlich weil die Mantisse bei FP32 nur 24 Bit breit ist und das Rechenwerk entsprechend ausgelegt wurde. Eine 32-Bit-"Mantisse" (also ein 32-Bit-Integer) braucht dann zwei Takte.

[Coda]

Ich vermute sie verwenden einfach die DP-Logik für Int, da haben sie dann 53 Bit Mantisse.

[aths]

Die Frage ist, ob sie überhaupt solche DP-Units haben oder Units nehmen für DP zwei Takte brauchen (oder zwei SP-Unit zu einer DP-Unit verschalten.) Da böten sich im Detail etliche Möglichkeiten an.

[Coda]

DP sollte Dual-Issue sein, also zwei SP-ALUs arbeiten zusammen an einer DP-Op.

[Gipsel]

Vermutlich weil die Mantisse bei FP32 nur 24 Bit breit ist und das Rechenwerk entsprechend ausgelegt wurde. Eine 32-Bit-"Mantisse" (also ein 32-Bit-Integer) braucht dann zwei Takte.
Aber warum sowohl für MUL als auch ADD?
Ein 32Bit Multiplier ist erheblich mehr Aufwand (und läßt sich nicht mal einfach aus 2x24 Bit zaubern) als ein 32Bit Addierer. Bei Cypress ist z.B. ein Int32-ADD 1:1 zu FP32 (was uns doch schon sagen sollte, daß das wirklich billig ist, oder?), 32Bit Integer MUL aber im Prinzip 1:4 (bei Evergreen macht es noch die t-Einheit, auch wenn xyzw das durch Zusammenlegen angeblich auch können [gab es mal in einer Präsentation zu sehen, Shadercompiler nutzt das aber nicht], mit dem kommenden VLIW4 wird es dann 1:4 von xyzw gemacht).
Ich vermute sie verwenden einfach die DP-Logik für Int, da haben sie dann 53 Bit Mantisse.Dagegen spricht die Aussage nvidias, daß Dual-Issue dafür angeblich funktioniert (und das sie gegenüber David Kanter behauptet haben, daß das über 2 Takte looped [aber wie zur Hölle soll das genau gehen? Sinn macht das nicht.]). Ergo, richtig zusammenpassen tut da keine Variante.

Mein Favorit wäre ja immer noch, daß auf GF100 (GF104 macht es ja wohl deutlich anders) 32Bit Integer-Befehle genau wie DP abgearbeitet werden (bloß nicht vom Treiber ausgebremst). Das heißt Dual-Issue geht für diese Befehle auch nicht, da beide 16er Shader-Blöcke von der Instruktion belegt werden (DP wird also durch Zusammenlegen der Blöcke realisiert, nicht durch einen DP und einen SP-Block, ansonsten sollte nämlich Dual-Issue auch bei DP zumindest ab und zu mal funktionieren!). Diese angeblich vorhandene Integer-ALU in jedem SP gibt es gar nicht. Da gibt es nur ein wenig zusätzliche Logik (hauptsächlich Multiplier), damit man durch Zusammenlegen davon eben ein DP-FMA hinbekommt. Aber wenn man das schon so macht, dann hätte man in dem Abwasch auch 32Bit Integer Fullrate machen können (und wenn ich mich richtig erinnere, hat nvidia sogar davon gesprochen, also eventuell klappt da bloß irgendwas nicht ganz richtig).

[Gipsel]

DP sollte Dual-Issue sein, also zwei SP-ALUs arbeiten zusammen an einer DP-Op.
Das favorisiere ich auch. Allerdings heißt das im nvidia-Sprech, daß für DP kein Dual-Issue geht, also nur eine einzige Instruktion issued wird (die die Resourcen beider SP-Blöcke belegt).

[aths]

Aber warum sowohl für MUL als auch ADD?Das raffe ich auch nicht. Ein Mul in doppelter Breite kostet normalerweise vier mal so viel Takte. Allerdings habe ich bisher auch die FMA-Unit noch nich geistig durchdrungen, das soll ja eben kein MAD sein sondern mehr Schaltungsaufwand erfordern.

[aths]

Nach irgendeiner Definition würden wir dann ständig Schranken durchbrechen :rolleyes:
Regst Du wirklich auf, weil die da dem GF100 keinen "orgasmic change of the computing landscape" zubilligen? Sorry, aber das ist es wirklich nicht. Es ist ein Schritt am Anfang weiterer.Nvidia ist zudem seit langem bekannt, in kleinen, aber vielen Schritten zu entwickeln. Seit eh und je wird jeder Einzelfortschritt als der endgültige Durchbruch hochgejubelt.

Was mich tierisch aufregt, ist, dass Nvidia ständig versucht, die "Cores" ihrer GPU als irgendwie vergleichbar mit dem Core einer aktuellen Multicore-CPU gleichzusetzen. Eine aktuelle CPU hat pro Core eine dicke SIMD-Unit die mehr als ein FP32-MAD pro Takt schafft.

[Gipsel]

Allerdings habe ich bisher auch die FMA-Unit noch nich geistig durchdrungen, das soll ja eben kein MAD sein sondern mehr Schaltungsaufwand erfordern.
Im Prinzip mußt Du "lediglich" die 106 Bit der Mantisse des Resultats der Multiplikation korrekt berechnen statt nur die ersten 53 Bits beim MADD und bei der folgenden Addition die dann auch alle berücksichtigen. Da ist ein wenig mehr Cleverness gefragt, will man nicht einen 106Bit-Addierer einbauen (den man nicht wirklich benötigt, da das Ergebnis hinterher ja wieder nur 53Bit hat, man benötigt also nur einen 53Bit Addierer + die Fähigkeit das 106 Bit Ergebnis unter Berücksichtigung eines Übertrages von der Addition schnell zu runden).

[Gipsel]

Was mich tierisch aufregt, ist, dass Nvidia ständig versucht, die "Cores" ihrer GPU als irgendwie vergleichbar mit dem Core einer aktuellen Multicore-CPU gleichzusetzen. Eine aktuelle CPU hat pro Core eine dicke SIMD-Unit die mehr als ein FP32-MAD pro Takt schafft.
Da ist nvidia aber nicht der Einzige. Ein ähnliches Problem gibt es mit der Begriffsverwirrung um "Threads". Ich finde ja die OpenCL-Terminologie halbwegs in Ordnung. Da heißt ein "Thread" einfach "work item", was der datenparallelen SIMD-Abarbeitung schon eher gerecht wird. Eine OpenCL "compute unit" entspricht einer SIMD-Engine bzw. SM bei GPUs und einem Kern bei CPUs. Damit kann ich leben.

[LovesuckZ]

Nvidia ist zudem seit langem bekannt, in kleinen, aber vielen Schritten zu entwickeln. Seit eh und je wird jeder Einzelfortschritt als der endgültige Durchbruch hochgejubelt.


nVidia's Front-End ist aber kein kleiner Schritt. Hier hat man zu 95% der zukünftigen Arbeit erledigt. Das jemand wie Gipsel das nicht so sieht, ist eine politische Entscheidung. Wenn man betrachtet, dass AMD jeden Furz in ihrer Tessellation-Implementierung als neue Generation verkauft, dann ist dies hier ein klarer "orgasmic change of the computing landscape".

[aths]

Im Prinzip mußt Du "lediglich" die 106 Bit der Mantisse des Resultats der Multiplikation korrekt berechnen statt nur die ersten 53 Bits beim MADDIn diese Richtung ging meine Vorstellung auch, dass ein FMA, wenn es denn im Gegensatz zum MAD in jedem Fall beste Genauigkeit liefern sollte, intern doch eigentlich eine doppelt so breite Mantisse braucht.

und bei der folgenden Addition die dann auch alle berücksichtigen. Da ist ein wenig mehr Cleverness gefragt, will man nicht einen 106Bit-Addierer einbauen (den man nicht wirklich benötigt, da das Ergebnis hinterher ja wieder nur 53Bit hat, man benötigt also nur einen 53Bit Addierer + die Fähigkeit das 106 Bit Ergebnis unter Berücksichtigung eines Übertrages von der Addition schnell zu runden).Muss beim FMA nicht auch die Multiplikation genauer sein oder geht es nur um den Übergang vom Mul zum Add?


Da ist nvidia aber nicht der Einzige. Ein ähnliches Problem gibt es mit der Begriffsverwirrung um "Threads". Ich finde ja die OpenCL-Terminologie halbwegs in Ordnung. Da heißt ein "Thread" einfach "work item", was der datenparallelen SIMD-Abarbeitung schon eher gerecht wird. Eine OpenCL "compute unit" entspricht einer SIMD-Engine bzw. SM bei GPUs und einem Kern bei CPUs. Damit kann ich leben.... und der Pixel Shader heißt Fragment Shader, was ich auch sinnvoller finde.

[aths]

nVidia's Front-End ist aber kein kleiner Schritt. Hier hat man zu 95% der zukünftigen Arbeit erledigt. Das jemand wie Gipsel das nicht so sieht,... ist seine Meinung die er auch begründen kann. Du kannst deine Ansicht ebenfalls begründen. Vielleicht gibt es keine objektive Wahrheiten was Begriffe wie "orgasmic change of the computing landscape" angeht.

[Gipsel]

nVidia's Front-End ist aber kein kleiner Schritt. Hier hat man zu 95% der zukünftigen Arbeit erledigt.Das würde ich mal glatt bestreiten. Wie kommst Du auf 95%?!? Glaubst Du wirklich, alle noch weiter möglichen Verbesserungen sind nur 5% der Änderungen von GT200 auf GF100 wert? Falls ja, brauchen wir wirklich nicht weiter diskutieren. :rolleyes:

[Gipsel]

Muss beim FMA nicht auch die Multiplikation genauer sein oder geht es nur um den Übergang vom Mul zum Add?
Ja, die Multipliklation muß 106Bit korrekt bestimmen, nicht nur die ersten 53. Bei der Multiplikation kommt man ja mathematisch immer auf 106 Bit für's Ergebnis. Bei einem normalen MADD (oder auch MUL) kann man da ein wenig sparen, da man ein korrekt gerundetes 53Bit-Ergebnis mit ein paar Shortcuts auch etwas einfacher hinbekommt, ohne wirklich alle 106 Bits ausrechnen und dann runden zu müssen.

[aths]

Ja, die Multipliklation muß 106Bit korrekt bestimmen, nicht nur die ersten 53. Bei der Multiplikation kommt man ja mathematisch immer auf 106 Bit für's Ergebnis. Bei einem normalen MADD (oder auch MUL) kann man da ein wenig sparen, da man ein korrekt gerundetes 53Bit-Ergebnis mit ein paar Shortcuts auch etwas einfacher hinbekommt, ohne wirklich alle 106 Bits ausrechnen und dann runden zu müssen.Ich weiß nicht wie genau die Multiplikation schalttechnisch ausgeführt wird, mir fielen einige Möglichkeiten ein, zum Beispiel pro Stelle die Mantisse um eine Stelle nach recht zu setzen und dann die Spalten addieren. (Entspricht mathematisch einer parallelen Ausführung der russischen Multiplikation.) Ich bin mir fast sicher, dass das in der Praxis deutlich eleganter gemacht wird.

edit: Lt. B3D-Artikel nutzt er für die SFUs eine quadratische Interpolation. Das ergibt Sinn da die anzunähernden Funktionen alle "schön rund" sind. Aber wie viele Ops braucht man für so eine Interpolation? Ein Lerp besteht ja aus nur drei Ops (2x Mul, 1x Add oder andersherum.) Reicht die Komplexität zweier Lerps bereits für eine quadratische Interpolation? Wenn ich das richtig sehe, läuft es eher auf ein Lerp von zwei Lerp-Ergebnissen hinaus, das wären dann immerhin neun Ops.

[Coda]

Mein Favorit wäre ja immer noch, daß auf GF100 (GF104 macht es ja wohl deutlich anders) 32Bit Integer-Befehle genau wie DP abgearbeitet werden (bloß nicht vom Treiber ausgebremst). Das heißt Dual-Issue geht für diese Befehle auch nicht, da beide 16er Shader-Blöcke von der Instruktion belegt werden (DP wird also durch Zusammenlegen der Blöcke realisiert, nicht durch einen DP und einen SP-Block, ansonsten sollte nämlich Dual-Issue auch bei DP zumindest ab und zu mal funktionieren!).
Öh, sorry, das meinte ich damit. Co-Issue wäre wohl richtiger gewesen :)

[Bucklew]

Die zweite DMA-Engine hilft gegen die enorm abrupten Framerateneinbrüche, wenn der Grafikspeicher zur Neige geht (haben die Radeons übrigens schon seit R600 an Bord).
Naja, nur weil es hilft ist es noch lange nicht gut. Der Grafikspeicher sollte einfach nicht zuende gehen.

Und DP hat ein Cypress auch (sogar mit etwas mehr Leistung als es bei nvidia zu kaufen gibt). So what?
Cypress schafft ein SP : DP-Verhältnis von 5:1, Fermi eines von 2:1. Das ist schon ein kleiner Unterschied, findest du nicht?

ECC? Das ist im Verhältnis gar nicht so teuer. Das schleppt z.B. praktisch die billigste Consumer-CPU schon seit Ewigkeiten mit sich rum. Und nv hat sich ja sogar noch die zusätzlichen Datenleitungen dafür im Speichercontroller gespart.
Es kostet trotzdem Transistoren und Chipfläche :rolleyes:

[Gipsel]

Naja, nur weil es hilft ist es noch lange nicht gut. Der Grafikspeicher sollte einfach nicht zuende gehen.Wie Coda schon sagte, es hilft. Aus irgendeinem Grund wird es ATI ja schon ab R600 eingebaut haben, oder? :rolleyes:

Oder anders gesagt, Du magst Dir zwar ein Festmahl wünschen, aber wenn Du die Wahl zwischen gar nichts essen und einer Stulle Brot hast, was nimmst Du dann?
Cypress schafft ein SP : DP-Verhältnis von 5:1, Fermi eines von 2:1. Das ist schon ein kleiner Unterschied, findest du nicht?Cypress schafft 544 GFlop/s in DP als HD5870 und 528 GFlop/s als Firestream 9370. Ein GF100 schafft maximal (als Tesla M2070/C2070) 515 GFlop/s in DP. Das ist kein großer Unterschied, findest Du nicht?

Kleine Anmerkung am Rande, für ADDs schafft Cypress ein Verhältnis von 5:2 und ist damit (528/544 Gadds/s gegenüber 258 Gadds/s) potentiell bis zu doppelt so schnell wie eine Tesla 2070.
Es kostet trotzdem Transistoren und Chipfläche :rolleyes:Habe ich ja nicht bestritten. Es ist aber nicht viel (weniger als 5%).

[Bucklew]

Wie Coda schon sagte, es hilft. Aus irgendeinem Grund wird es ATI ja schon ab R600 eingebaut haben, oder? :rolleyes:
Ob 5 oder 0,5 fps macht nun keinen großen Unterschied...

Cypress schafft 544 GFlop/s in DP als HD5870 und 528 GFlop/s als Firestream 9370. Ein GF100 schafft maximal (als Tesla M2070/C2070) 515 GFlop/s in DP. Das ist kein großer Unterschied, findest Du nicht?
Ausgehend von 2,7 vs. 1,3 GFlops in SP ist der Unterschied minimal. Und natürlich kostet dieser geringe Performancedrop zwischen SP und DP nicht unwesentliche Menge an Transistoren und Chipfläche. Für Nvidia.

Habe ich ja nicht bestritten. Es ist aber nicht viel (weniger als 5%).
Sind schonmal 5% und ein Link würde mich ziemlich interessieren ;)

[Gipsel]

Cypress schafft 544 GFlop/s in DP als HD5870 und 528 GFlop/s als Firestream 9370. Ein GF100 schafft maximal (als Tesla M2070/C2070) 515 GFlop/s in DP. Das ist kein großer Unterschied, findest Du nicht?Ausgehend von 2,7 vs. 1,3 GFlops in SP ist der Unterschied minimal.Ich habe mal das Wesentliche hervorgehoben. :rolleyes:
Und natürlich kostet dieser geringe Performancedrop zwischen SP und DP nicht unwesentliche Menge an Transistoren und Chipfläche. Für Nvidia.Aha, daß Cypress grob die doppelte SP-Rohleistung hat als GF100 bei etwa gleicher DP-Leistung kostet also nvidia eine Menge Transistoren und Chipfläche. Hmm, irgendwie sollte nvidia nochmal über ihr Konzept nachdenken so wie Du es beschreibst. :lol:

Edit:
Also Du sagst im Prinzip, daß wenn nvidia den GF100 so ändern würde, daß man die SP-Leistung (bei Beibehaltung der DP-Leistung) verdoppelt, daß man dann Transistoren und Fläche sparen kann? :freak:
Sind schonmal 5% und ein Link würde mich ziemlich interessieren ;)
Ich wollte zuerst deutlich weniger als 5% schreiben, weil meine Abschätzung für GF100 auf nicht mehr als 3 Prozent hinauslief. Damit hast Du übrigens Deine Quelle auch schon gleich. Die bin nämlich ich und nenne es einfach einen educated guess. Und ob Du es glaubst oder nicht, sowas kann ich meist halbwegs passabel ;).
Falls Du wissen willst, wie ich darauf komme, überlege Dir einfach mal, wieviel ECC-Bits überall drinstecken, schlag noch was drauf für die Logik zum Berechnen und Vergleichen dieser Bits und Du bist da.

[deekey777]

...

Oder anders gesagt, Du magst Dir zwar ein Festmahl wünschen, aber wenn Du die Wahl zwischen gar nichts essen und einer Stulle Brot hast, was nimmst Du dann?
Cypress schafft 544 GFlop/s in DP als HD5870 und 528 GFlop/s als Firestream 9370. Ein GF100 schafft maximal (als Tesla M2070/C2070) 515 GFlop/s in DP. Das ist kein großer Unterschied, findest Du nicht?

Kleine Anmerkung am Rande, für ADDs schafft Cypress ein Verhältnis von 5:2 und ist damit (528/544 Gadds/s gegenüber 258 Gadds/s) potentiell bis zu doppelt so schnell wie eine Tesla 2070.
....
Vergiss nicht den Mixed-Mode. Aber wird bal wohl Geschichte sein. ;(

[LovesuckZ]

... ist seine Meinung die er auch begründen kann. Du kannst deine Ansicht ebenfalls begründen. Vielleicht gibt es keine objektive Wahrheiten was Begriffe wie "orgasmic change of the computing landscape" angeht.

Begriffe wie Evolution und Revolution haben aber eine Definition. Und die Art und Weise wie Fermi die Anforderungen von DX11-Tessellation umgesetzt hat, ist ein revolutionärer Sprung über mehrere Evolutionsstufen gewesen. Es ist nicht nur das Front-End, sondern auch das deutlich überarbeiterte interne Speichersystem, dass zu dieser Geometrieleistung beiträgt. Natürlich ist es alles nur Mittel zum Zweck. Nur ohne Fermi würde sich die Implementierung von Tessellation sehr lange verzögern (Cayman kommt ca. 11 Monate nach den Dev Boards raus) und nur auf sehr geringere Teile eines Frames beschränkt sein. Denn AMD's Implementierung führt den Gedanken hinter DX11/OpenGL4 Tessellation ad absurdum und deckt sich in keinster Weise, wie es von AMD, MS und nVidia vermarket wird.
Das komplette Gerüst zur Erledigung der Aufgabe ist ein "orgasmic change of the computing landscape". Denn wäre es nicht so, dürfte mit dem selben Workload und ohne spezielle Optimierung auf die Hardware GF100 nicht 6-8x schneller sein. AMD's Leistung ist abnormal schlecht, nämlich genau dann, wenn Tessellation wirklich sinn macht.

[Fetza]

Was willst Du wissen? Eine Antwort auf Deine ursprüngliche Frage, warum GF100 so viel Strom zieht (trotz niedrigerer Spannung nicht weniger pro Transistor als Cypress)?
Das liegt vornehmlich an der genauen Auslegung der Schaltungen, sprich der Anzahl der benutzten Transistoren mit hoher bzw. niedriger Schwellspannung (Threshold, Vt).
So ein Prozeß hat ja nicht nur eine Sorte von Transistor sondern verschiedene. Der Designer kann festlegen, ob ein Transistor ein schnell schaltendes Exemplar (niedrige Vt), ein normales oder ein relativ langsamer Transistor ist (hohe Vt). Der Haken an der Sache ist natürlich, daß die schnellen Transistoren beträchtlich mehr Strom ziehen (nicht nur unter Last, Leakage geht deutlich hoch). Das wird natürlich möglichst so gewählt, daß man viele langsame, stromsparende Transistoren benutzen kann und trotzdem die angepeilte Taktfrequenz erreicht, also nur die kritischen Pfade mit den schnellsten Transistoren ausstattet.
Wenn man das Verhalten seiner Schaltung nicht perfekt einschätzen kann (oder auch die Schaltung insgesamt kein optimales Design aufweist), muß man mehr schnelle, stromhungrige Transistoren benutzen, der Stromverbrauch steigt also. Bei einem Base-Layer Respin (oder einem abgeändertem Design) kann man das korrigieren, wodurch der Stromverbrauch bei gleicher Transistorzahl sinken kann (und/oder der Takt steigt).

Wenn es Dir um stromfressende Features geht, dann sind wie gesagt nicht die Features an sich so wichtig, sondern eher ihre Umsetzung und Auslegung. Nvidia benutzt traditionell eine deutlich aufwendigere Verwaltung der Einheiten, die natürlich auch entsprechend Transistoren kostet. Dadurch kann man aber prinzipiell an den Ausführungseinheiten selber etwas sparen, da sie mit etwas höherer Auslastung laufen. Das ist also ein Kompromiß, der unterschiedlich ausfallen kann.
Nvidia hat sich entschieden, die Leistung der Ausführungseinheiten pro Transistor durch eine Shaderdomain für den Takt zu erhöhen. Leider kostet so eine Auslegung sowohl Transistoren (mehr Pipelinestufen) als eventuell auch Stromverbrauch (mehr Transistoren müssen niedrige Vt haben). Außerdem vereinfacht das die Verwaltung der Einheiten auch nicht unbedingt (höhere Latenzen, mehr Instruktionen in flight). Wie gesagt, alles eine Frage des Kompromisses.

Nvidia hat sich entschieden, DP mit halber SP Geschwindigkeit einzubauen. Dies ist insofern unverständlich (meiner Meinung nach eine Kopfgeburt), als daß das wirklich aufwendiger als z.B. 1/4 ist. Die GeForces könnten bei anderer Auslegung auf gleicher Fläche bestimmt 20% mehr SP-Leistung haben, die DP-Leistung wäre dann immerhin auch noch 60% der heutigen (theoretisch möglichen, es wird ja keine Tesla mit GTX480 Takten und SP-Anzahl verkauft; bei Erreichen des Designzieles hätte man dann ausgehend von 512 SP [+20%] bei 1.5GHz auch 460GFlop/s DP erreicht, jetzt stehen die Teslas bei 515 GFlop/s oder so).

Nene danke. Du hattest meine frage, ob es überhaupt wirklich etwas im gf100 gibt, was man für einen auf gaming spezialisierten gf110 wegrationalisieren kann, ja beantwortet. Aber danke für die ausführliche erklärung. :)

[PulsarS]

AMD's Leistung ist abnormal schlecht, nämlich genau dann, wenn Tessellation wirklich sinn macht.
Nö. AMDs Leistung ist genau wo es Sinn macht ausreichend genug.
Siehe die ganzen Spiele bis jetzt.
Es gibt kein einziges, wo die Tesselationsleistung limitieren würde, selbst bei einem Cypress nicht.
Man kann das natürlich auf die Spitze treiben und bis geht nicht mehr tesselieren...
Nur hat man dann einen Performancedrop, der den Gewinn an BQ nicht rechtfertigt. Ab einem bestimmten Tesselierungsgrad hast nämlich nur minimale BQ-Verbesserungen (je nach Engine), die den Verlust an Performance kaum rechtfertigen.

[Bucklew]

Ich habe mal das Wesentliche hervorgehoben. :rolleyes:
Ja, der Unterschied ist gering. Anders als bei SP. Und das zeigt doch schon ziemlich eindeutig, dass eine nicht unwesentlich Zahl Transistoren (und damit Chipfläche) bei Fermi dafür geopfert wurde, dass der Einbruch zwischen SP und DP gering ist. Verglichen mit Cypress ist er das ja auch.

Aha, daß Cypress grob die doppelte SP-Rohleistung hat als GF100 bei etwa gleicher DP-Leistung kostet also nvidia eine Menge Transistoren und Chipfläche. Hmm, irgendwie sollte nvidia nochmal über ihr Konzept nachdenken so wie Du es beschreibst. :lol:
Laber nicht so einen Müll. Ich habe schon ziemlich eindeutig geschrieben, dass der UNTERSCHIED zwischen SP und DP Nvidia eine große Menge Transistoren kostet. Anders als ATI. Und deshalb bricht der Cypress mit DP auch gut 250% stärker ein als Fermi.

Edit:
Also Du sagst im Prinzip, daß wenn nvidia den GF100 so ändern würde, daß man die SP-Leistung (bei Beibehaltung der DP-Leistung) verdoppelt, daß man dann Transistoren und Fläche sparen kann? :freak:
Hör auf Bullshit zu erzählen, wenn du kein Gegenargument hast. Dreh mir die Worte nicht im Mund herum.

Ich wollte zuerst deutlich weniger als 5% schreiben, weil meine Abschätzung für GF100 auf nicht mehr als 3 Prozent hinauslief. Damit hast Du übrigens Deine Quelle auch schon gleich. Die bin nämlich ich und nenne es einfach einen educated guess. Und ob Du es glaubst oder nicht, sowas kann ich meist halbwegs passabel ;).
Naja, wenn ich mir den Quatsch oben so durchlese - kein Kommentar :rolleyes:

[Gipsel]

Laber nicht so einen Müll. Ich habe schon ziemlich eindeutig geschrieben, dass der UNTERSCHIED zwischen SP und DP Nvidia eine große Menge Transistoren kostet. Anders als ATI. Und deshalb bricht der Cypress mit DP auch gut 250% stärker ein als Fermi.

Hör auf Bullshit zu erzählen, wenn du kein Gegenargument hast. Dreh mir die Worte nicht im Mund herum.Mit Verlaub, ich kann ja nichts dafür wenn Deine Argumente nicht ziehen. Wenn man nach dem "Einbruch" immer noch auf/über GF100 Niveau liegt, kann der ja wohl nicht so schlimm sein ;).

Fakt ist, Cypress erreicht mit seiner DP-Hardware den gleichen Durchsatz wie Fermi. Davon ausgehend, was kostet wohl mehr Transistoren, nur doppelte SP-Leistung im Vergleich zu DP zu schaffen oder die vierfache? Na, klingelts?

Falls Du zufällig gerade nicht drauf kommen solltest, kann ich Dir die Antwort verraten: Bei gleicher DP-Leistung kostet ein 4:1 SP : DP Verhältnis mehr als 2:1.
Ich hoffe, ich muß Dir nicht auch noch erklären warum. :rolleyes:

PS:
Ich habe hier irgendwo kürzlich schon mal erklärt, wieso ich die 1:2 Entscheidung nicht für gelungen halte und daß man mit 1:4 auf deutlich mehr SP-Leistung bei optimalerweise nur moderat sinkender DP-Leistung gekommen wäre.
Also ja, 1:2 ist teuer, aber mit 1:4 erhält man nicht die doppelte SP-Leistung bei gleicher DP-Leistung sondern eben merklich mehr SP-Leistung aber eben auch weniger DP-Leistung auf gleicher Fläche (oder gleiche SP-Leistung aber deutlich weniger DP-Leistung auf etwas kleinerer Fläche, such's Dir aus). Jetzt rumzujammern, 1:2 DP koste soviel Fläche, ändert nichts daran, daß man auch mit einer anderen Entscheidung hinten gelegen hätte. Nur eben gleichmäßiger, d.h. mit ähnlichem Faktor bei SP und DP. In der Metrik Flops/mm² liegen die GeForces nun einmal hinten, da beißt die Maus keinen Faden ab.

Dies läßt sich auch gut am GF104 zeigen. Selbst ein hypothetischer Vollausbau bei 800/1600MHz liegt bei etwas größerer Fläche als Cypress nur bei weniger als der Hälfte der SP-Peakleistung (1,23 vs. 2,72 TFlop/s) und bei DP sieht es noch mieser aus (102 vs. 544 GFlop/s). Da (bei 1:12) kostet DP ja wohl kaum noch Fläche, oder? Das ganze Argument von dem großen Die-Flächen-Verbrauch aufgrund 1:2 ist einfach Blödsinn, da man ja noch nicht mal in DP vorne liegt. Nvidia hat sich also durch ihre Entscheidungen in diesem Aspekt einen prinzipiellen Nachteil aufgehalst. Da kannst Du mich noch so lange beschimpfen, das wird sich trotzdem nicht ändern.

[Kalmar]

Dies läßt sich auch gut am GF104 zeigen. Selbst ein hypothetischer Vollausbau bei 800/1600MHz liegt bei etwas größerer Fläche als Cypress nur bei weniger als der Hälfte der SP-Peakleistung (1,23 vs. 2,72 TFlop/s) und bei DP sieht es noch mieser aus (102 vs. 544 GFlop/s). Da (bei 1:12) kostet DP ja wohl kaum noch Fläche, oder? Das ganze Argument von dem großen Die-Flächen-Verbrauch aufgrund 1:2 ist einfach Blödsinn, da man ja noch nicht mal in DP vorne liegt. Nvidia hat sich also durch ihre Entscheidungen in diesem Aspekt einen prinzipiellen Nachteil aufgehalst. Da kannst Du mich noch so lange beschimpfen, das wird sich trotzdem nicht ändern.


was wäre denn nen guter weg aus diesem nachteil ggf. einen schwächeren oder nen vorteil wieder zu gewinnen ? zurück auf 1/4 ? wie könnte eine lösung ausehen ggf kann man ja das was für die nächste gen draus schließen... denke bei nv werden sich köpfe ähnlich gedanken machen .. oder findet nv ihr konzept gelungen ?

[|MatMan|]

Dies läßt sich auch gut am GF104 zeigen. [...] Das ganze Argument von dem großen Die-Flächen-Verbrauch aufgrund 1:2 ist einfach Blödsinn [...]
Danke für deine Erläuterungen, aber hier widersprichst du dir etwas selbst. Wenn also DP doch nicht so viel Die-Fläche verbraucht, dann war doch die Design-Entscheidung für GF100 am Ende richtig?!
(jetzt mal andere mögliche Auswirkungen wie Taktbarkeit, Stromverbrauch, ... außen vor gelassen)

[Mancko]

Wenn AMD laut Gipsel so toll ist bei SP und vor allem DP frage ich mich wieso die im professionellen Umfeld nach wie vor eine Witznummer sind. Dort sind Kunden bereit für Nvidia Produkte richtig viel Geld - viel mehr Geld als für AMD - zu zahlen. Der Softwarevorsprung alleine wirds ja wohl nicht sein, wenngleich der für Nvidia recht beruhigend sein dürfte. Bis AMD dort mal richtig aufgeholt hat vergehen Jahre.

Das ist im übrigen auch ein Grund wieso Fermi für den Gamer nicht ganz so optimal ist, bzw. vieles mitschleppt, wovon der Gamer im ersten Momentan nichts hat. Aber mit Gamern wird in Zukunft kaum noch Geld verdient werden. Sieht man ja eindeutig an den Ergebnissen von AMD' GPU Abteilung und mit den integrierten Chips wird das noch schlimmer werden. Die Margen für solche Produkte sind gleich 0.

[Nighthawk13]

Warum gibt es eigentlich keine Fermi Karten mit 3+ gleichzeitig ansteuerbaren Monitorausgängen?

Dort sehe ich (neben dem Stromverbauch) die grösste Schwäche gegenüber AMD Karten(2 Monitore+Fernseher dran ist ja nicht so exotisch, z.B.).

Der Nvidia-Treiber kann ja offensichtlich bis zu 4 Monitore mit 2 Karten, also liegt es nicht an der Software. 3 physikalische Ausgänge(2xDVI+HDMI) sind ja auch auf jeder GTX470/480.
Warum kann der Riesen-Chip nur 2 davon betreiben, so viele Transistoren kann eine DVI-Ansteuerelektronik doch nicht kosten? :confused:

[=Floi=]

man könnte tesselation wie AA sehen. je mehr, desto besser. ;)

LS hat aber recht, wenn er die tesselationsleistung beim GF100 als überdurchschnittlich hinstellt und man auch den DEVs ermöglicht, dies in ihren aktuellen entwicklungen umzusetzen. Erst dadurch werden sehr hohe tesselationsgrade von morgen möglich.

[=Floi=]

wie wollt ihr denn die aufteilung auf 4 Rasterizer denn sonst beschreiben? imho war das doch der so oft propagandierte NÖTIGE schritt um die nächsten jahre wettbewerbsfähig zu sein.
nun erklärt mal, warum das nicht so sein soll?

[Gipsel]

was wäre denn nen guter weg aus diesem nachteil ggf. einen schwächeren oder nen vorteil wieder zu gewinnen?
Ich hatte im Kepler-Thread schon mal kurz was dazu geschrieben (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8354395#post8354395).
Danke für deine Erläuterungen, aber hier widersprichst du dir etwas selbst. Wenn also DP doch nicht so viel Die-Fläche verbraucht, dann war doch die Design-Entscheidung für GF100 am Ende richtig?!Meiner Meinung nach nein, denn sie verstärkt eine Schwäche (relativ wenig arithmetische Leistung) des GF100 noch, um für den sehr kleinen Markt des GPGPU-Computing mit DP einen zweifelhaften Vorteil zu gewinnen. Denn noch nicht mal da schafft man es ja, AMDs Karten zu übertrumpfen.
Wenn AMD laut Gipsel so toll ist bei SP und vor allem DP frage ich mich wieso die im professionellen Umfeld nach wie vor eine Witznummer sind. Dort sind Kunden bereit für Nvidia Produkte richtig viel Geld - viel mehr Geld als für AMD - zu zahlen. Der Softwarevorsprung alleine wirds ja wohl nicht sein, wenngleich der für Nvidia recht beruhigend sein dürfte. Bis AMD dort mal richtig aufgeholt hat vergehen Jahre.Doch, die Software ist genau der Punkt, den ich inzwischen schon seit Jahren anspreche. Die Radeon-Hardware kann eigentlich erstaunlich viel, wenn man sich damit mal beschäftigt, die mußte sich höchst selten vor nvidia verstecken.

Vielleicht ganz interessant ist der letzte Artikel auf B3D zu dem Thema (http://www.beyond3d.com/content/reviews/55/14). Mal ein paar Auszüge:

Another useful tool is represented by atomics, with a fast implementation of them making a number of algorithms possible. Atomics can use operands both from shared memory as well as from VRAM – let's look at the first case (prepare for a bit of shock):
[picture]
Hoping that everyone who fainted was exposed to smelling salts, let's underline that the above is correct: in our considerable experience, Cypress is ~12 times faster here.
[..]
The final slice of so called goodies has us look at atomics in global memory [..], using the {Increment,Decrement}Counter [..] functionality and, last but not least, Append/Consume Buffers. Excluding [global] atomics, where it's roughly 3 times faster, [Fermi] loses everywhere here too. That's a bit surprising for a GPU that supposedly forfeited graphics for compute, and is probably just a retrofitted compute only device. So what's the story?
[..]
we think that [Fermi] can only perform atomics using the ROPs on operands that are in the L2; as such, when doing atomic ops on shared memory operands, what actually happens is that the bank holding the offending value gets locked and its data is written out to the L2, the operation is performed at the ROP and the result written back, with the bank being unlocked afterwards.

You also need to look at ROP throughput in graphics tasks, which is also eerily close to the rates we're seeing, or more specifically to what happens when doing blends on a 32-bit Integer render target – that's pretty much an atomic op right there, and explains the performance we measured. In contrast to this, ATI actually opted for putting dedicated hardware into their shared memory implementation, handling everything involved from conflict analysis to the actual op, and it shows.

The reason why performance with Counters or Append/Consume buffers in D3D looks comparatively bad is tied to this as well: ATI has some in-hardware tweaks for those usage scenarios, making extensive use of the GDS, which also has hardware for atomics, mind you, which is perky since counter management is also pretty much an atomic op, and some dedicated pathways. That's in contrast to NVIDIA, who seem to have opted for a fully generic path.
[..]
Fermi's biggest problem was its time to market, and its biggest strength is NVIDIA's great software prowess. Many people tend to intentionally or unintentionally fumble this, by using things like CUDA as arguments for hardware superiority -- make no mistake, CUDA is an outstanding software product, for which many talented software engineers sweat blood.

Great performance with the newest games is in great part-owed to developer relations superiority -- we're sure we'll get some hate-mail over this statement, but we're at a point where we can call them as they are, rather than cater to anyone's sensibilities -- rather than some intrinsic mystic hardware unit that exists only in NVIDIA's products.

And all of this put together underlines the truth that some still choose to ignore: great hardware is nothing without software. We dare say that NVIDIA's great software stack made Fermi look a bit better competitively than its hardware would have allowed (just look at sheer measured throughput!) -- luckily for them, it appears that this particular situation won't be changing soon, with no competitive pressure on the horizon on the software front.
Ich befinde mich also in ganz guter Gesellschaft ;)

[Coda]

Naja. ECC, ein globaler Adressraum mit indirekter Adressierung und Exception-Handling sind Dinge die AMD noch fehlen. Unterstützt AMD eigentlich Debugging auf der Hardware mit Breakpoints etc.?

Das wären zumindest für mich schon überzeugende Argumente wenn ich einen Supercomputer bauen müsste. Aber vielleicht schätz ich das ja falsch ein.

Das AMD die performantere Hardware für Compute hat bestreite ich nicht.

[LovesuckZ]

Sollte die News bzgl. des neuen #1 Supercomputers stimmen, wäre nVidia somit in #1 und #2 vertreten. Soviel zu AMD's überlegender "Compute-Architecture" - scheint wohl nicht jeder der Meinung von Beyond3d.com und Gipsel zu sein.

Und die netten Chinamenschen haben sogar die AMD GPUs durch nVidia's Tesla Serie ersetzt...

[deekey777]

Vielleicht hat NVIDIA einfach das bessere Angebot gemacht?
Und da es noch keine Top500 gibt, warten wir noch etwas ab, nicht dass der Jaguar in der Herbst-Liste auf dem ersten Platz landet.

[PulsarS]

man könnte tesselation wie AA sehen. je mehr, desto besser. ;)
Schlechter Vergleich, da kaum Analogie besteht.
Man könnte ja auch sagen... je mehr Shader, desto besser usw.
Ist nicht zielführend solche Denkweise. :)

LS hat aber recht, wenn er die tesselationsleistung beim GF100 als überdurchschnittlich hinstellt und man auch den DEVs ermöglicht, dies in ihren aktuellen entwicklungen umzusetzen. Erst dadurch werden sehr hohe tesselationsgrade von morgen möglich.
Dem stimme ich durchaus zu.
Nur meint LS, dass die AMD-Karten zu wenig Tesselationspower haben, was einfach nicht der Realität entspricht.
Andersrum wird es wohl richtiger sein... nicht AMD hat zu wenig Tesselationspower, sondern der GF100 einfach zu viel für die heutige Praxis (Games) und die absehbare Zukunft.
Wen ich aber Dev wäre und wählen müsste, dann würde ich wohl auch einen GF100 haben wollen. Zumindest wenn ich eine Engine für die Zukunft programmieren wollte. Das ist ganz klar.
Für den Gamer stellt die Tesselationsleistung aber zur Zeit noch kein Problem dar und dies wird sich auch nicht von heute auf morgen ändern.

[Dural]

naja bei DP sind beide in etwa gleich (theoretisch) aber wie sieht es in der praxis aus?!? Ich denke da schon nur mal an 6GB Speicher / 384Bit / ECC usw.

was am ende dabei raus kommt dürfte bei NV sicher überzeugender sein... erst recht wenn man bedenkt das NV in dem bereich jahre vorsprung hat!

Ich meine es ist ja überdeutlich wenn man die X2 von AMD raus nimmt und Tesla einbaut die es bei der anschafung der X2 damals ja noch nicht gab, das sagt für mich alles... AMD kauft man wohl nur weil es nichts anderes gibt oder wegen dem Preis, wenn man was rechtes will geht man halt zu NV :)

Edit: mir viel gerade auf, das ist im Gamer Markt ja genau gleich ;)

[AnarchX]

Warum gibt es eigentlich keine Fermi Karten mit 3+ gleichzeitig ansteuerbaren Monitorausgängen?

Dort sehe ich (neben dem Stromverbauch) die grösste Schwäche gegenüber AMD Karten(2 Monitore+Fernseher dran ist ja nicht so exotisch, z.B.).

Der Nvidia-Treiber kann ja offensichtlich bis zu 4 Monitore mit 2 Karten, also liegt es nicht an der Software. 3 physikalische Ausgänge(2xDVI+HDMI) sind ja auch auf jeder GTX470/480.
Warum kann der Riesen-Chip nur 2 davon betreiben, so viele Transistoren kann eine DVI-Ansteuerelektronik doch nicht kosten? :confused:
Hat man einfach versäumt und keine große Priorität eingeräumt und auf AMD konnte man auch nicht reagieren, da diese Eyefinity und dessen Entwicklung sehr verborgen haben.

Aber bei den kommenden GF11x-GPUs könnte ich mir vorstellen, dass man hier mehr als zwei Ausgabegeräte ansteuern kann.

[aths]

Begriffe wie Evolution und Revolution haben aber eine Definition. Und die Art und Weise wie Fermi die Anforderungen von DX11-Tessellation umgesetzt hat, ist ein revolutionärer Sprung über mehrere Evolutionsstufen gewesen.Das sehe ich nicht so. ATI versuchte mehrfach, Tesselation zu forcieren doch man kann Geometrie-Content nicht so einfach interpolieren. Jetzt ist der Vorteil noch die LOD-Bestimmung um zu kleine Dreiecke zu vermeiden. Dann allerdings halst man sich wieder Aliasingprobleme in der Geometrie auf.

Eine "Revolution" auf einem Einzelgebiet welches noch auf längere Sicht ohne Relevanz ist, ist keine Revolution. Nvidia hat nur mal wieder ein Feature für Entwickler brauchbar implementiert. Wenn Tesselation (falls das überhaupt so kommen sollte) hier und da in Standardspielen zum Tragen kommt, sind auch ATI-Mittelklasse-Karten gut genug. Ich bin mir zudem sicher, dass der GF100 für solche Spiele dann nicht mehr in Frage kommt, weil dann klar wird, welche Flaschenhälse er für die breite Praxisanforderung noch hat.


man könnte tesselation wie AA sehen. je mehr, desto besser. ;) Das funktionierte schon bei TruForm nicht so.

[aths]

Nene danke. Du hattest meine frage, ob es überhaupt wirklich etwas im gf100 gibt, was man für einen auf gaming spezialisierten gf110 wegrationalisieren kann, ja beantwortet. Aber danke für die ausführliche erklärung. :)Der GF100 ist doch auf Gaming spezialisiert. Das meiste was an Schaltkreisen für General Computing genutzt wird, wird auch für Spiele verwendet.

[Bucklew]

Mit Verlaub, ich kann ja nichts dafür wenn Deine Argumente nicht ziehen. Wenn man nach dem "Einbruch" immer noch auf/über GF100 Niveau liegt, kann der ja wohl nicht so schlimm sein ;).
Natürlich ist ein Einbruch auf 25% schlimmer als ein Einbruch um 50%. Auch wenn du dir die Sache gerade so hinbiegen willst, wie sie dir gerade in den Kram passt...

Fakt ist, Cypress erreicht mit seiner DP-Hardware den gleichen Durchsatz wie Fermi. Davon ausgehend, was kostet wohl mehr Transistoren, nur doppelte SP-Leistung im Vergleich zu DP zu schaffen oder die vierfache? Na, klingelts?
Angesichts der unterschiedlichen Architekturen ist der Nvidia-Weg deutlich Transistor-intensiver.

Ich habe hier irgendwo kürzlich schon mal erklärt, wieso ich die 1:2 Entscheidung nicht für gelungen halte und daß man mit 1:4 auf deutlich mehr SP-Leistung bei optimalerweise nur moderat sinkender DP-Leistung gekommen wäre.
Was bringt denn ATI ihre SP-Leistung? Wenn wir mal von Games ausgehen, gibt es kein einziges, in dem auch nur ansatzweise die theoretisch auf dem Papier stehenden Werte erreicht werden. Da ist ein GF100 dann immer noch schneller als ein Cypress, obwohl dieser theoretisch doppelt soviel SP-Leistung hätte. Das nenne ich nicht gerade gelungen, wenn man einfach nur Shaderpower auf den Chip klatscht, ohne das man davon hinterher einen spürbaren Effekt hat.

Ich meine es ist ja überdeutlich wenn man die X2 von AMD raus nimmt und Tesla einbaut die es bei der anschafung der X2 damals ja noch nicht gab, das sagt für mich alles... AMD kauft man wohl nur weil es nichts anderes gibt oder wegen dem Preis, wenn man was rechtes will geht man halt zu NV :)
ATI soll die X2-Karten an die Chinesen wohl quasi verschenkt haben, damit diese die einbauen und man die schön in die Marketingpräsos einbauen kann.

[deekey777]

Was wäre dann die alternative GT200-Teslas mit deren Monster-DP-Performance?

[Bucklew]

Wer sagt, dass sie DP genutzt haben?

[deekey777]

Wer sagt, dass sie DP genutzt haben?
Wie sind sie dann in der Top500 gelandet, wenn sie kein DP genutzt haben?

[Gipsel]

Natürlich ist ein Einbruch auf 25% schlimmer als ein Einbruch um 50%. Auch wenn du dir die Sache gerade so hinbiegen willst, wie sie dir gerade in den Kram passt...
Jaja, ist natürlich total schlimm, daß die ATIs bei gleicher DP-Leistung (also nicht langsamer als die Teslas!) in SP dann schneller sind. :rolleyes:
Ehrlich, da müssen wir nicht mehr drüber diskutieren. Wenn die Zypressen nur in SP schneller wären und in DP dann langsamer, dann könnte man über die unterschiedlichen Stärke der "Einbrüche" reden, aber so (Cypress hat praktisch in jeder Lebenslage mehr arithmetische Leistung als eine Tesla) ist das eine ziemlich irrwitzige Diskussion.
Angesichts der unterschiedlichen Architekturen ist der Nvidia-Weg deutlich Transistor-intensiver.Ich habe das ja schon mal gesagt: Vielleicht sollte nvidia dann nochmal über ihren Weg nachdenken? Offensichtlich ist es ja noch nicht der Heilige Gral des GPU-Designs.
Was bringt denn ATI ihre SP-Leistung? Wenn wir mal von Games ausgehen, gibt es kein einziges, in dem auch nur ansatzweise die theoretisch auf dem Papier stehenden Werte erreicht werden. Da ist ein GF100 dann immer noch schneller als ein Cypress, obwohl dieser theoretisch doppelt soviel SP-Leistung hätte. Das nenne ich nicht gerade gelungen, wenn man einfach nur Shaderpower auf den Chip klatscht, ohne das man davon hinterher einen spürbaren Effekt hat.Was glaubst Du wohl, wie die Radeons mit halbierter Shaderpower abschneiden würden? Es ist doch ganz einfach, man sieht sich die typischen Workload für die GPUs an und überlegt sich, wie man mit minimalem Mehraufwand an Transistoren und Verbrauch eine maximale Steigerung hinbekommt.

Was ATI mit ihren Entscheidungen erreicht hat, ist daß man recht selten (im Gegensatz zu den nvidia-GPUs) durch die Shaderpower limitiert wird (man stößt da eher an andere Limits der Chips). Insgesamt ist dieser Ansatz momentan ganz offensichtlich flächeneffizienter (das müssen wir jetzt hier nicht wirklich nochmal aufkochen, oder?), auch wenn Du das als "nicht gelungen" ansiehst.
Den nvidia GPUs würde dagegen ein wenig mehr Shaderpower schon enorm gut zu Gesicht stehen. Dies ist ein wichtiger Punkt, an dem sie für die Zukunft arbeiten werden.

Vielleicht solltest Du mal ein paar mehr meiner Posts hier lesen. Ich habe oft davon gesprochen, wie die meisten der Entscheidungen beim Design und Auslegung eines Chips durch Kompromisse gekennzeichnet sind. Für jeden dieser Kompromisse gibt es natürlich Gründe, warum er je nach Hersteller so oder so ausfällt. Beiden ist aber natürlich wichtig, was unterm Strich als Leistung zu Buche steht. Deswegen werden beide auch danach streben, ihre Lösungen zu verbessern.
Dabei bedarf es wohl keiner Glaskugel, um zu behaupten, daß beide verstärkt an Ihren jeweiligen Schwächen arbeiten werden. Auf Seiten nvidias wird das voraussichtlich eine höhere Flächen- und auch Energieeffizienz der Shaderarchitektur sein, bei der man den relativ großen Anteil des Verwaltungsoverheads dort zu drücken versucht (natürlich möglichst ohne sich dort gravierende Nachteile einzuhandeln). Bei AMD wird man wohl tendenziell das ganze unter umgekehrten Vorzeichen beobachten können.

[Bucklew]

Wie sind sie dann in der Top500 gelandet, wenn sie kein DP genutzt haben?
Wer sagt, dass die X2-Karten bei der Leistungsberechnung für die Top500 überhaupt einbezogen wurden?

Jaja, ist natürlich total schlimm, daß die ATIs bei gleicher DP-Leistung (also nicht langsamer als die Teslas!) in SP dann schneller sind. :rolleyes:
Eben: Ineffizenter. Wenn wir den Einbruch SP vs. DP betrachten. Um nichts anderes geht es.

Ehrlich, da müssen wir nicht mehr drüber diskutieren. Wenn die Zypressen nur in SP schneller wären und in DP dann langsamer, dann könnte man über die unterschiedlichen Stärke der "Einbrüche" reden, aber so (Cypress hat praktisch in jeder Lebenslage mehr arithmetische Leistung als eine Tesla) ist das eine ziemlich irrwitzige Diskussion.
Also ein Auto, dass mit 1000PS 200km/h Spitzengeschwindigkeit schafft ist besser als ein Auto, welches 190km/h mit 100PS schafft?

Ich habe das ja schon mal gesagt: Vielleicht sollte nvidia dann nochmal über ihren Weg nachdenken? Offensichtlich ist es ja noch nicht der Heilige Gral des GPU-Designs.
Welchen Grund gibt es denn dafür? In Spielen nutzt ATI die doppelte Shaderpower überhaupt nichts. Also warum in diesem Bereich große Anstrengungen investieren?

Was glaubst Du wohl, wie die Radeons mit halbierter Shaderpower abschneiden würden? Es ist doch ganz einfach, man sieht sich die typischen Workload für die GPUs an und überlegt sich, wie man mit minimalem Mehraufwand an Transistoren und Verbrauch eine maximale Steigerung hinbekommt.
Da die ATI-Karten trotz doppelter Shaderleistung langsamer sind, wohl offensichtlich genau da so, wie sie auch heute abschneiden würde. Genau deswegen stellt sich ja die Frage, warum man unbedingt Brute-Force machen muss und Shaderleistung ohne Ende in den Chip klatschen muss, die man unterm Strich absolut gar nicht nutzen kann.

Was ATI mit ihren Entscheidungen erreicht hat, ist daß man recht selten (im Gegensatz zu den nvidia-GPUs) durch die Shaderpower limitiert wird (man stößt da eher an andere Limits der Chips). Insgesamt ist dieser Ansatz momentan ganz offensichtlich flächeneffizienter (das müssen wir jetzt hier nicht wirklich nochmal aufkochen, oder?), auch wenn Du das als "nicht gelungen" ansiehst.
Den nvidia GPUs würde dagegen ein wenig mehr Shaderpower schon enorm gut zu Gesicht stehen. Dies ist ein wichtiger Punkt, an dem sie für die Zukunft arbeiten werden.
Eben, ATI baut kein ausbalanciertes Design (zumindest aus dem Gaming-Gesichtspunkt). Die Shaderleistung verpufft an anderen Ecken des Chips und damit kann man sich im Grunde genommen die zusätzliche Shaderleistung auch einfach sparen. Aber klar, es macht sich gut auf den Marketingpräsentationen und so mancher Käufer lässt sich natürlich davon blenden und glaubt, dass so ein Cypress doppelt so schnell wie ein GF100 ist. Naja, knapp daneben ;)

Vielleicht solltest Du mal ein paar mehr meiner Posts hier lesen. Ich habe oft davon gesprochen, wie die meisten der Entscheidungen beim Design und Auslegung eines Chips durch Kompromisse gekennzeichnet sind. Für jeden dieser Kompromisse gibt es natürlich Gründe, warum er je nach Hersteller so oder so ausfällt. Beiden ist aber natürlich wichtig, was unterm Strich als Leistung zu Buche steht. Deswegen werden beide auch danach streben, ihre Lösungen zu verbessern.
Ja, Kompromisse. Schönes Stichwort, denn genau die hat Nvidia bei GF100 nunmal massenweise in Kauf genommen um Grafikkarten in Bereiche verkaufen zu können, die vorher verschlossen worden wären. Mit eben dem Problem, dass man selbst den größten Consumerchip massiv beschneiden muss und es viel Chipfläche gibt, die er gar nicht nötig hätte. Nichts anderes habe ich im Ausgangsposting gesagt, von daher ist es (wie üblich) mal wieder fraglich, warum du mir unbedingt mit Aussagen- und Tatsachenverdrehungen widersprechen musst.

[hmx]

Jaja, ist natürlich total schlimm, daß die ATIs bei gleicher DP-Leistung (also nicht langsamer als die Teslas!) in SP dann schneller sind. :rolleyes:
Ehrlich, da müssen wir nicht mehr drüber diskutieren. Wenn die Zypressen nur in SP schneller wären und in DP dann langsamer, dann könnte man über die unterschiedlichen Stärke der "Einbrüche" reden, aber so (Cypress hat praktisch in jeder Lebenslage mehr arithmetische Leistung als eine Tesla) ist das eine ziemlich irrwitzige Diskussion.
Ich habe das ja schon mal gesagt: Vielleicht sollte nvidia dann nochmal über ihren Weg nachdenken? Offensichtlich ist es ja noch nicht der Heilige Gral des GPU-Designs.
Was glaubst Du wohl, wie die Radeons mit halbierter Shaderpower abschneiden würden? Es ist doch ganz einfach, man sieht sich die typischen Workload für die GPUs an und überlegt sich, wie man mit minimalem Mehraufwand an Transistoren und Verbrauch eine maximale Steigerung hinbekommt.

Was ATI mit ihren Entscheidungen erreicht hat, ist daß man recht selten (im Gegensatz zu den nvidia-GPUs) durch die Shaderpower limitiert wird (man stößt da eher an andere Limits der Chips). Insgesamt ist dieser Ansatz momentan ganz offensichtlich flächeneffizienter (das müssen wir jetzt hier nicht wirklich nochmal aufkochen, oder?), auch wenn Du das als "nicht gelungen" ansiehst.
Den nvidia GPUs würde dagegen ein wenig mehr Shaderpower schon enorm gut zu Gesicht stehen. Dies ist ein wichtiger Punkt, an dem sie für die Zukunft arbeiten werden.

Vielleicht solltest Du mal ein paar mehr meiner Posts hier lesen. Ich habe oft davon gesprochen, wie die meisten der Entscheidungen beim Design und Auslegung eines Chips durch Kompromisse gekennzeichnet sind. Für jeden dieser Kompromisse gibt es natürlich Gründe, warum er je nach Hersteller so oder so ausfällt. Beiden ist aber natürlich wichtig, was unterm Strich als Leistung zu Buche steht. Deswegen werden beide auch danach streben, ihre Lösungen zu verbessern.
Dabei bedarf es wohl keiner Glaskugel, um zu behaupten, daß beide verstärkt an Ihren jeweiligen Schwächen arbeiten werden. Auf Seiten nvidias wird das voraussichtlich eine höhere Flächen- und auch Energieeffizienz der Shaderarchitektur sein, bei der man den relativ großen Anteil des Verwaltungsoverheads dort zu drücken versucht (natürlich möglichst ohne sich dort gravierende Nachteile einzuhandeln). Bei AMD wird man wohl tendenziell das ganze unter umgekehrten Vorzeichen beobachten können.


Irgendwie kommt es mir aber schon recht seltsam vor wie wenig da von der höheren Shaderleistung bei den Atis rüberkommt. Insbesondere beim Einsatz von AA. Da ist schon die Frage angebracht, ob das denn alles so sinnvoll ist. Zudem fällt (warum auch immer) auf, dass die gf1xx Karten bei DX11-Spielen auch ohne Tesselation besser aussehen. Ich sehe da bei Spielen eher weniger eine Limitierung durch die Rechenleistung.

[Gipsel]

Wer sagt, dass die X2-Karten bei der Leistungsberechnung für die Top500 überhaupt einbezogen wurden?Das sagt uns der simple Fakt, daß die gemessene Peakleistung, mit der das System in den Top500 steht, höher ist, als die theoretische Peakleistung der verbauten CPUs :rolleyes:
Eben: Ineffizenter. Wenn wir den Einbruch SP vs. DP betrachten. Um nichts anderes geht es.

Also ein Auto, dass mit 1000PS 200km/h Spitzengeschwindigkeit schafft ist besser als ein Auto, welches 190km/h mit 100PS schafft?
;D
Was soll denn jetzt was sein? Also ich sehe ein Auto mit 550PS, daß weniger als 20% schneller ist als ein Auto mit 350PS. :lol:

Autos sind eigentlich immer schlechte Analogien, aber das ist ja zum Kringeln! Nun gut, dann will ich auch mal solchen Blödsinn verzapfen.

Cypress ist also ein Kleintransporter, der mit lediglich 3,3t zulässigem Gesamtgewicht von jedem mit einem normalen Führerschein gefahren werden darf. Unbeladen (SP) schafft der auf der Autobahn maximal ganze 272 km/h, wenn es die Straßenverhältnisse denn mal zulassen. Mit einem schweren Anhänger dran (DP) geht es immerhin noch mit 54 km/h voran. Dabei bleibt der Verbrauch immer unter 20l/100km.
So eine Tesla ist da schon ein schwereres Kaliber mit einem zulässigem Gesamtgewicht von 5,5t, weswegen man da dann schon den LKW-Führerschein benötigt, für den man ordentlich löhnen darf. Trotzdem schafft das Ding mit dem gleichen Anhänger aus unverständlichen Gründen und trotz der expliziten Bewerbung als "Schwerlasttransporter" nur 51km/h, und ohne Anhänger dann läppische 103 km/h. Davon gibt es dann noch eine Version für de Alltagsgebrauch mit etwas verbesserter Aerodynamik, die deshalb ohne Anhänger dann immerhin schon 134 km/h schafft und die man sogar ohne LKW-Führerschein fahren darf. Der Haken an der Sache ist, daß man mit Anhänger dann auf 17km/h limitiert ist, da man keinen LKW-Führerschein hat. Dazu kommt noch, daß die Kiste bis zu 30l/100km verbraucht.

So, und jetzt ganz ehrlich: Welches Modell würdest Du wählen? :lol:

Also auf dem Niveau müssen wir wirklich nicht weitermachen!
Welchen Grund gibt es denn dafür? In Spielen nutzt ATI die doppelte Shaderpower überhaupt nichts. Also warum in diesem Bereich große Anstrengungen investieren?Ich muß schon sagen: Du kennst Dich aber aus! ;D
Vielleicht überlegst Du mal, was zu unterschiedlichen Zeiten beim Rendern eines Frames so alles limitieren kann! Dann fällt Dir vielleicht auf, daß der Rest Deines Postings zu dem Teil ziemlicher Blödsinn war, den ich deswegen hier auch nicht mehr zitiere.
Ja, Kompromisse. Schönes Stichwort, denn genau die hat Nvidia bei GF100 nunmal massenweise in Kauf genommen um Grafikkarten in Bereiche verkaufen zu können, die vorher verschlossen worden wären. Mit eben dem Problem, dass man selbst den größten Consumerchip massiv beschneiden muss und es viel Chipfläche gibt, die er gar nicht nötig hätte. Nichts anderes habe ich im Ausgangsposting gesagt, von daher ist es (wie üblich) mal wieder fraglich, warum du mir unbedingt mit Aussagen- und Tatsachenverdrehungen widersprechen musst.
Nun, ich mache es mal kurz und zitiere aths:
Der GF100 ist doch auf Gaming spezialisiert. Das meiste was an Schaltkreisen für General Computing genutzt wird, wird auch für Spiele verwendet.
Zusätzlich kann ich nur nochmal den schon von mir verlinkten B3D-Artikel empfehlen. Dort wird auch geschildert, daß für bestimmte Compute-Sachen ATI dedizierte Hardware verbaut hat, nvidia aber nicht. Also soo schlimm kann es mit dem Overhead dafür ja wohl nicht sein, oder?
Irgendwie kommt es mir aber schon recht seltsam vor wie wenig da von der höheren Shaderleistung bei den Atis rüberkommt. Insbesondere beim Einsatz von AA. Da ist schon die Frage angebracht, ob das denn alles so sinnvoll ist.Was hat MSAA nochmal genau mit Shaderleistung zu tun? Und seit wann verlieren die Radeons mit AA überproportional viel?
Irgendwie habe ich im Hinterkopf, daß ein GF100 so um die 50% mehr ROPs hat, die theoretisch sogar jeweils die doppelte Z-Test-Leistung haben sollen, was dann schon zusammen einen Faktor 3(!) pro Takt bei MSAA gegenüber Cypress ausmachen sollte. Irgendwie vermisse ich diesen Faktor in Benchmarks. GF100 muß dann ja wohl eine höllisch miese ROP-Architektur haben, daß sie aus diesem Vorteil so wenig machen :rolleyes:
Du siehst, es ist nicht immer alles so einfach. ;)
Zudem fällt (warum auch immer) auf, dass die gf1xx Karten bei DX11-Spielen auch ohne Tesselation besser aussehen. Ich sehe da bei Spielen eher weniger eine Limitierung durch die Rechenleistung.
Wie oben schon angedeutet, limitieren beim Rendern eines Frames verschiedene Sachen der GPU jeweils für eine bestimmte Zeit. Es geht darum, die größten Bremsen (möglichst günstig) etwas zu lösen (sprich, die Dauer innerhalb eines Frames, an der es bei einer bestimmten Komponente bremst, zu verringern). Ganz entfernen kann man einen Flaschenhals praktisch nie.

[deekey777]

Wer sagt, dass die X2-Karten bei der Leistungsberechnung für die Top500 überhaupt einbezogen wurden?


....
Also wirklich.
Wie dreist muss man sein, um so etwas zu schreiben?

[hmx]

Das sagt uns der simple Fakt, daß die gemessene Peakleistung, mit der das System in den Top500 steht, höher ist, als die theoretische Peakleistung der verbauten CPUs :rolleyes:

;D
Was soll denn jetzt was sein? Also ich sehe ein Auto mit 550PS, daß weniger als 20% schneller ist als ein Auto mit 350PS. :lol:

Autos sind eigentlich immer schlechte Analogien, aber das ist ja zum Kringeln! Nun gut, dann will ich auch mal solchen Blödsinn verzapfen.

Cypress ist also ein Kleintransporter, der mit lediglich 3,3t zulässigem Gesamtgewicht von jedem mit einem normalen Führerschein gefahren werden darf. Unbeladen (SP) schafft der auf der Autobahn maximal ganze 272 km/h, wenn es die Straßenverhältnisse denn mal zulassen. Mit einem schweren Anhänger dran (DP) geht es immerhin noch mit 54 km/h voran. Dabei bleibt der Verbrauch immer unter 20l/100km.
So eine Tesla ist da schon ein schwereres Kaliber mit einem zulässigem Gesamtgewicht von 5,5t, weswegen man da dann schon den LKW-Führerschein benötigt, für den man ordentlich löhnen darf. Trotzdem schafft das Ding mit dem gleichen Anhänger aus unverständlichen Gründen und trotz der expliziten Bewerbung als "Schwerlasttransporter" nur 51km/h, und ohne Anhänger dann läppische 103 km/h. Davon gibt es dann noch eine Version für de Alltagsgebrauch mit etwas verbesserter Aerodynamik, die deshalb ohne Anhänger dann immerhin schon 134 km/h schafft und die man sogar ohne LKW-Führerschein fahren darf. Der Haken an der Sache ist, daß man mit Anhänger dann auf 17km/h limitiert ist, da man keinen LKW-Führerschein hat. Dazu kommt noch, daß die Kiste bis zu 30l/100km verbraucht.

So, und jetzt ganz ehrlich: Welches Modell würdest Du wählen? :lol:

Also auf dem Niveau müssen wir wirklich nicht weitermachen!
Ich muß schon sagen: Du kennst Dich aber aus! ;D
Vielleicht überlegst Du mal, was zu unterschiedlichen Zeiten beim Rendern eines Frames so alles limitieren kann! Dann fällt Dir vielleicht auf, daß der Rest Deines Postings zu dem Teil ziemlicher Blödsinn war, den ich deswegen hier auch nicht mehr zitiere.

Nun, ich mache es mal kurz und zitiere aths:

Zusätzlich kann ich nur nochmal den schon von mir verlinkten B3D-Artikel empfehlen. Dort wird auch geschildert, daß für bestimmte Compute-Sachen ATI dedizierte Hardware verbaut hat, nvidia aber nicht. Also soo schlimm kann es mit dem Overhead dafür ja wohl nicht sein, oder?
Was hat MSAA nochmal genau mit Shaderleistung zu tun? Und seit wann verlieren die Radeons mit AA überproportional viel?
Irgendwie habe ich im Hinterkopf, daß ein GF100 so um die 50% mehr ROPs hat, die theoretisch sogar jeweils die doppelte Z-Test-Leistung haben sollen, was dann schon zusammen einen Faktor 3(!) pro Takt bei MSAA gegenüber Cypress ausmachen sollte. Irgendwie vermisse ich diesen Faktor in Benchmarks. GF100 muß dann ja wohl eine höllisch miese ROP-Architektur haben, daß sie aus diesem Vorteil so wenig machen :rolleyes:
Du siehst, es ist nicht immer alles so einfach. ;)

Wie oben schon angedeutet, limitieren beim Rendern eines Frames verschiedene Sachen der GPU jeweils für eine bestimmte Zeit. Es geht darum, die größten Bremsen (möglichst günstig) etwas zu lösen (sprich, die Dauer innerhalb eines Frames, an der es bei einer bestimmten Komponente bremst, zu verringern). Ganz entfernen kann man einen Flaschenhals praktisch nie.

Das mit den ROPs gilt aber nicht für den gf104. Und es hat was mit AA zu tun in der Hinsicht als dass die Radeons die Rohleistung dann nicht mehr ausspielen können.

[aths]

Da die ATI-Karten trotz doppelter Shaderleistung langsamer sind, wohl offensichtlich genau da so, wie sie auch heute abschneiden würde. Genau deswegen stellt sich ja die Frage, warum man unbedingt Brute-Force machen muss und Shaderleistung ohne Ende in den Chip klatschen muss, die man unterm Strich absolut gar nicht nutzen kann. Absolut gar nicht? Anteilig kann man die Zusatzrohleistung schon nutzen. Es ist für den Anwender egal ob die Leistung durch Rohleistung oder durch gute Auslastung kommt. Beides kostet Transistoren.

[AnarchX]

Würde es eigentlich schon bemerkt, dass der Geometrie-Durchsatz, ebenso wie der reine Pixeldurchsatz an der Streamig-Multiprozessoren/Clustern hängt?

Wenn man man sich die Quadro-Dreiecksrate anschaut, sieht man schnell dass sich der Durchsatz auf 0,25 Tri/Takt pro SM beläuft.

Die GPCs bieten wohl 1 Tri/Takt, aber wie auch bei den ROPs ist der Flaschenhals an einer anderen Stelle.

Das erklärt auch warum PCGH auf der GT 430 (2 SMs @ 700MHz) nicht Nvidias 700MTri/s messen konnte. (http://www.pcgameshardware.de/aid,793709/Geforce-GT-430-im-Kurztest-Was-taugt-Fermi-fuer-unter-70-Euro/Grafikkarte/Test/)

Dazu existiert noch neben der reinen Geometrie-Drossel auch eine Tessellationsdrossel für die GeForce Versionen von GF104 und GF100:
http://img266.imageshack.us/img266/2/img0029676.png
http://www.behardware.com/articles/800-7/roundup-10-workstation-graphics-cards.html

Quadro 5000 (11 SMs je 0,25 Tri/Takt @513MHz): 1411 MTri/s
GTX 480 (15 SMs je 0,25 Tri/Takt @700MHz): 2625 MTri/s
GTX 460 (7 SMs je 0,25 Tri/Takt @675MHz): 1181 MTri/s

Peak Leistung vs gemessene Leistung(0% culled):
Peak Leistung gemessene Leistung
GTX 480 222% 219%
Quadro 5000 120% 175%
GTX 460 100% 100%

Bei GF106 und kleiner fällt diese Drossel am geringsten aus:
http://img222.imageshack.us/img222/7114/img0029526.gif
http://www.hardware.fr/articles/801-5/dossier-sparkle-geforce-gts-450s.html

[Bucklew]

So, und jetzt ganz ehrlich: Welches Modell würdest Du wählen? :lol:
Das kommt darauf an. Rein technisch allerdings gesehen, ist das schnellere Modell natürlich das deutlich ineffizentere, weil der Einbruch durch den Hänger viel größer ist.

Das Leistung eben nicht alles ist zeigen ja auch sehr schön die Spielebenchmarks (wie schon erwähnt) und ja eben auch der chinesische Supercomputer. Warum sollten sie wohl die Radeons rausschmeißen und gegen ach so langsame Teslas austauschen (die noch dazu deutlich teurer sind), wenn man daraus keinen Vorteil zieht?

Wie gesagt: Die TFlops machen sich schön in der Marketingpräso, wirklich viel bei rum kommt unterm Strich in der Praxis allerdings auch nicht.

Ich muß schon sagen: Du kennst Dich aber aus! ;D
Vielleicht überlegst Du mal, was zu unterschiedlichen Zeiten beim Rendern eines Frames so alles limitieren kann! Dann fällt Dir vielleicht auf, daß der Rest Deines Postings zu dem Teil ziemlicher Blödsinn war, den ich deswegen hier auch nicht mehr zitiere.
Eben, alles mögliche kann limitieren. Dann sag mir doch mal den Sinn genau das massiv aufzubohren, was normalerweise gar nicht limitiert?

Wie gesagt: Zeig mir doch mal einen (Spiele-)Benchmark, in dem eine Cypresskarte doppelt so schnell wie eine GF100-Karte ist. Und dann können wir ja nochmal über den Sinn und Unsinn von soviel Shaderleistung reden.

Nun, ich mache es mal kurz und zitiere aths:

Zusätzlich kann ich nur nochmal den schon von mir verlinkten B3D-Artikel empfehlen. Dort wird auch geschildert, daß für bestimmte Compute-Sachen ATI dedizierte Hardware verbaut hat, nvidia aber nicht. Also soo schlimm kann es mit dem Overhead dafür ja wohl nicht sein, oder?
Und was haben jetzt von ATI verbaute und von Nvidia nicht verbaute Compute-Schaltkreise mit dem Overhead zu tun, den Nvidia aktuell im GF100 (deaktiviert) mit sich herumschleppt? Außer gar nichts?

Also wirklich.
Wie dreist muss man sein, um so etwas zu schreiben?
Aha, also kein Beleg dafür?

[Aquaschaf]

Das kommt darauf an. Rein technisch allerdings gesehen, ist das schnellere Modell natürlich das deutlich ineffizentere, weil der Einbruch durch den Hänger viel größer ist.

Um bei der Analogie zu bleiben: geringerer Verbrauch, geringeres Gewicht und mehr Leistung. Und auf GPUs umgemünzt: mehr Leistung/Fläche und mehr Leistung/Watt. Das ist effizienter, nicht ineffizienter.. und auch nicht "rein technisch gesehen". In Hinsicht auf die Shaderprozessoren sieht AMDs Architektur gerade klar besser aus. Bei anderen Teilen der GPU ist es eben umgekehrt.

Damit es hier kein Missverständnis gibt: dass die Peak-Leistung von der real erreichbaren bei AMD mehr abweicht als bei Nvidia gilt nur für SP, nicht für DP.

[LovesuckZ]

Würde es eigentlich schon bemerkt, dass der Geometrie-Durchsatz, ebenso wie der reine Pixeldurchsatz an der Streamig-Multiprozessoren/Clustern hängt?

Wenn man man sich die Quadro-Dreiecksrate anschaut, sieht man schnell dass sich der Durchsatz auf 0,25 Tri/Takt pro SM beläuft.

Die GPCs bieten wohl 1 Tri/Takt, aber wie auch bei den ROPs ist der Flaschenhals an einer anderen Stelle.

Das erklärt auch warum PCGH auf der GT 430 (2 SMs @ 700MHz) nicht Nvidias 700MTri/s messen konnte. (http://www.pcgameshardware.de/aid,793709/Geforce-GT-430-im-Kurztest-Was-taugt-Fermi-fuer-unter-70-Euro/Grafikkarte/Test/)

Dazu existiert noch neben der reinen Geometrie-Drossel auch eine Tessellationsdrossel für die GeForce Versionen von GF104 und GF100:
http://img266.imageshack.us/img266/2/img0029676.png
http://www.behardware.com/articles/800-7/roundup-10-workstation-graphics-cards.html

Quadro 5000 (11 SMs je 0,25 Tri/Takt @513MHz): 1411 MTri/s
GTX 480 (15 SMs je 0,25 Tri/Takt @700MHz): 2625 MTri/s
GTX 460 (7 SMs je 0,25 Tri/Takt @675MHz): 1181 MTri/s

Peak Leistung vs gemessene Leistung(0% culled):
Peak Leistung gemessene Leistung
GTX 480 222% 219%
Quadro 5000 120% 175%
GTX 460 100% 100%

Bei GF106 und kleiner fällt diese Drossel am geringsten aus:
http://img222.imageshack.us/img222/7114/img0029526.gif
http://www.hardware.fr/articles/801-5/dossier-sparkle-geforce-gts-450s.html

Laut nVidia schafft man praktisch ca. 3,2 Dreiecke/Takt. Das liegt vorallem am Sammeln der Dreiecke vor dem Rastern, um die Rendervorgabe der API einzuschalten. Und da jede zusätzliche Arbeit weitere Latenz bringt, kann man jede zusätzliche Setup-Engine über 1 nicht vollständig ausnutzen.
Ohne Tessellation ist es jedoch egal und mit, erreicht man sowieso nur ca. 1,6 Mrd pro Sekunde.

[Gipsel]

Das mit den ROPs gilt aber nicht für den gf104. Und es hat was mit AA zu tun in der Hinsicht als dass die Radeons die Rohleistung dann nicht mehr ausspielen können.Na klar gilt das auch für GF104. Der hat hat zwar genau so viele ROPs wie HD5850/70 und HD6850/70, allerdings können die aber ebenfalls doppelt so viele Z-Tests machen, wobei man theoretisch bei einem Faktor 2 Vorteil pro Takt ankommt. Den kriegen die aber praktisch nirgendwo auf die Straße.
Außerdem verschiebt AA (außer SSAA) die Last recht deutlich weg von den Shaderleistung (da die Pixelshader nicht für jedes Subpixel ausgeführt werden sondern nur einma pro Pixel), weswegen das alles andere als "seltsam" ist (wie Du es ausgedrückt hast), daß die Shaderleistung dort nicht mehr eine ganz so große Rolle spielt. Es ist viel eher seltsam, daß nvidia aus ihrem ROP-Vorteil dort so wenig machen und nicht vollkommen wegziehen.

[Gipsel]

Eben, alles mögliche kann limitieren. Dann sag mir doch mal den Sinn genau das massiv aufzubohren, was normalerweise gar nicht limitiert?

Wie gesagt: Zeig mir doch mal einen (Spiele-)Benchmark, in dem eine Cypresskarte doppelt so schnell wie eine GF100-Karte ist. Und dann können wir ja nochmal über den Sinn und Unsinn von soviel Shaderleistung reden.Du hast offensichtlich nicht verstanden, wie die Zeit, die man für das Rendern eines Frames benötigt, zustande kommt.
Und was haben jetzt von ATI verbaute und von Nvidia nicht verbaute Compute-Schaltkreise mit dem Overhead zu tun, den Nvidia aktuell im GF100 (deaktiviert) mit sich herumschleppt? Außer gar nichts?Du meinst, außer das Cypress (oder auch die ganze Evergreen-Reihe) ebenfalls eine Menge Zeugs mit sich rumschleppt, welches in einem Spiel selten Beschäftigung findet? Dein Argument ist ganz einfach keine Einbahnstraße.
Aha, also kein Beleg dafür?
;D
Wie wäre es den mal mit einem Beleg Deinerseits? Viel Spaß beim Versuch, eine gemessene Leistung deutlichst oberhalb der Peakleistung der verbauten CPUs zu erklären! Darauf habe ich Dich übrigens oben schon mal hingewiesen. Ein wenig Nachdenken kann man wohl schon verlangen!

[deekey777]

;D
Wie wäre es den mal mit einem Beleg Deinerseits? Viel Spaß beim Versuch, eine gemessene Leistung deutlichst oberhalb der Peakleistung der verbauten CPUs zu erklären! Darauf habe ich Dich übrigens oben schon mal hingewiesen. Ein wenig Nachdenken kann man wohl schon verlangen!
Du siehst doch, dass der Typ so verblendet ist, dass er direkt in die Sonne schauen kann.
Unglaublich, einfach unglaublich.
Hier, lieber Bucklew:
http://www.ece.neu.edu/groups/nucar/GPGPU/GPGPU-2/Fatica.pdf
In LinPack wird DP-Performance gezählt.
Hier die Daten des Tianhe:
http://www.top500.org/blog/2009/11/13/tianhe_1_chinas_first_petaflop_s_scale_supercomputer
Soll ich dir noch die DP-Leistung einzelner CPUs geben?

Unglaublich diese Dreistigkeit.

[Captain Future]

Cypress ist also ein Kleintransporter, der mit lediglich 3,3t zulässigem Gesamtgewicht von jedem mit einem normalen Führerschein gefahren werden darf. Unbeladen (SP) schafft der auf der Autobahn maximal ganze 272 km/h, wenn es die Straßenverhältnisse denn mal zulassen. Mit einem schweren Anhänger dran (DP) geht es immerhin noch mit 54 km/h voran. Dabei bleibt der Verbrauch immer unter 20l/100km.
So eine Tesla ist da schon ein schwereres Kaliber mit einem zulässigem Gesamtgewicht von 5,5t, weswegen man da dann schon den LKW-Führerschein benötigt, für den man ordentlich löhnen darf. Trotzdem schafft das Ding mit dem gleichen Anhänger aus unverständlichen Gründen und trotz der expliziten Bewerbung als "Schwerlasttransporter" nur 51km/h, und ohne Anhänger dann läppische 103 km/h. Davon gibt es dann noch eine Version für de Alltagsgebrauch mit etwas verbesserter Aerodynamik, die deshalb ohne Anhänger dann immerhin schon 134 km/h schafft und die man sogar ohne LKW-Führerschein fahren darf. Der Haken an der Sache ist, daß man mit Anhänger dann auf 17km/h limitiert ist, da man keinen LKW-Führerschein hat. Dazu kommt noch, daß die Kiste bis zu 30l/100km verbraucht.

So, und jetzt ganz ehrlich: Welches Modell würdest Du wählen? :lol:
Du hast aber ein paar Dinge vergessen zu erwähnen in deinem Beispiel, ich mach mal weiter.

• Beim Schwerlaster sind die Europaweiten Autobahngebühren bereits inklusive (software-environment)
• Totschlagargument: Schwerlaster dürfen auf Autobahnen eh nur 100 fahren, daher sind 103 kmh ausreichend. :ulol:
• Der Schwerlaster hat zwar circa dieselbe Zuladung (DP-FLOPS), aber ein deutlich höheres Laderaumvolumen, sodass er manchmal mit einer anstelle von zwei Touren auskommt (6 GB)
• Der Cypress hat drei (manche Modelle sogar 6) Anhängerkupplungen, der Schwerlaster nur zwei
• Bis auf zwei gelten für die Cypress-Anhängerkupplungen aber besondere Voraussetzungen, die nicht jeder Anhänger hat und die man für teuer Geld nachrüsten muss
• Der Alltagsschwerlaster hat noch einen bequemeren Fahrersitz und eine besser geschliffene Frontscheibe, durch die man klarer sieht.
• Im Durchschnitt vieler Strassenverhältnisse kann der Alltagsschwerlaster 15-30 Prozent schneller fahren als der Cypress-Laster - bergauf, Kopfsteinpflaster usw.

Ok, schluss dann mit lustig, lies bitte trotzdem weiter. ;)



Irgendwie habe ich im Hinterkopf, daß ein GF100 so um die 50% mehr ROPs hat, die theoretisch sogar jeweils die doppelte Z-Test-Leistung haben sollen, was dann schon zusammen einen Faktor 3(!) pro Takt bei MSAA gegenüber Cypress ausmachen sollte. Irgendwie vermisse ich diesen Faktor in Benchmarks. GF100 muß dann ja wohl eine höllisch miese ROP-Architektur haben, daß sie aus diesem Vorteil so wenig machen :rolleyes:
Du siehst, es ist nicht immer alles so einfach. ;)
Zeig mir einen reinen Test, der die ROP-z-Leistung isoliert. Die meisten machen ja schon wegen der Pixelbegrenzung auf 2/clk/sm vorher dicht, und darum ist der theoretisch mögliche ROP-Durchsatz auf den Chip bezogen nicht 268 Gz, sondern nur 168 Gz.

Mit Takt (der gehört ja zu den Produkten dazu) wäre es bei deinem Ansatz theoretischer Faktor 2,47.

[Captain Future]

Das kommt darauf an. Rein technisch allerdings gesehen, ist das schnellere Modell natürlich das deutlich ineffizentere, weil der Einbruch durch den Hänger viel größer ist.
Das kommt auf die Perspektive an.

Rein technisch gesehen, ist der Cypress-Laster schon drei KM/h schneller, mit SP wird er sogar mehr als doppelt so schnell. :ulol:

[Gipsel]

Zeig mir einen reinen Test, der die ROP-z-Leistung isoliert. Die meisten machen ja schon wegen der Pixelbegrenzung auf 2/clk/sm vorher dicht, und darum ist der theoretisch mögliche ROP-Durchsatz auf den Chip bezogen nicht 268 Gz, sondern nur 168 Gz.

Mit Takt (der gehört ja zu den Produkten dazu) wäre es bei deinem Ansatz theoretischer Faktor 2,47.
Die Tests gibt es zur Genüge z.B. von Damien bei hardware.fr (http://www.hardware.fr/articles/787-7/dossier-nvidia-geforce-gtx-480-470.html). Und ja, die zeigen sehr deutlich, daß selbst bei Z-Only mit 8xMSAA (wo die 8Z-Tests/Takt ja optimal durchschlagen sollten, sprich genau das isoliert wird) eine GTX480 lächerliche 47% vor einem Cypress liegt (also nix mit Faktor 2,47). Lächerlich deswegen, weil man dazu 50% mehr ROPs mit nominell doppelt so großen Fähigkeiten benötigt. Und der Takt ist ja mit 700 zu 850MHz jetzt auch nicht soo unterschiedlich.

Wozu benötigt also ein GF100 48 ROPs mit 8Z-Tests/Takt? Daß diese nie genutzt werden können, ist auch ein Zeichen von Ineffizienz.

Die ROPs alleine könnten theoretisch 48*8*0,7 = 269 GZSample/s. Die Geschichte mit den SMs limitiert das dann schon auf 15*2*8*0,7 = 168 GZSample/s, messen kann man dann noch knapp 158 GZSample/s.

Cypress hat 32 ROPs mit 4 Z-Tests/Takt, macht also theoretisch 108,8 GZSample/s und bei einer Messung kommen dabei 107,2 GZSample/s rüber.

Also ganz ehrlich, ich kann da nicht erkennen, daß die nv-Variante besonders elegant oder gar effizient aussieht.

PS:
Ich glaube, Du hast die Intention meiner von Dir zitierten Ausführungen mißverstanden. Die Diskussion ging doch darum, daß Cypress seine extrem hohe Shaderleistung nicht 1:1 in Spieleperformance übersetzen kann. Das stimmt natürlich, ist nicht weiter verwunderlich und überdies auch kein Einzelfall, wie ich das am Beispiel der ROPs des GF100 zeigen wollte. Da kommt die extrem hohe theoretisch vorhandene Z-Test-Leistung durch anderweitige Limitierungen und Ineffizienzen auch nicht zum Tragen.

[AnarchX]

Sollte CSAA nicht die ROP-Leistung jenseits des SM-Limits nutzen können?

[LovesuckZ]

Nachdem AMD es selbst im 9. Anlauf nicht geschafft hat ein robustes Front-End für Tessellation zu designen, will hier noch jemand behaupten, dass nVidia's Front-End nicht ein "monumental departure on any front" wäre?

Logik schlägt immer Propaganda.

[robbitop]

Das ist keine Frage von Können / Nichtkönnen. Sondern eine von Ressourcenverteilung. Ein solches Front End hätte mehr Transistoren gekostet. AMD war der Meinung, dass Tesselation im Moment noch nicht so wichtig ist und hat halt weniger dorthin investiert. Immerhin haben sie es verbessert. Wenn es absolut relevant wäre, hätte man auch mehr Augenmerk investiert.

edit:
9. Genereation ist auch ziemlich hergeleiert.
1. C1 / Xenos
2. R600
3. RV770 (RV670 war ja nur ein Shrink!)
4. RV870
5. RV970
6. RV1070

Wobei ich mir nichtmal sicher bin, ob sie vor RV870 überhaupt großartig was an der Tesselationseinheit vom C1 geändert haben.

[mapel110]

Immerhin haben sie Ressourcen in einen Treiber-Schalter für dieses Feature gesteckt, falls das doch mal wichtig werden sollte. :uup:

[deekey777]

Das ist keine Frage von Können / Nichtkönnen. Sondern eine von Ressourcenverteilung. Ein solches Front End hätte mehr Transistoren gekostet. AMD war der Meinung, dass Tesselation im Moment noch nicht so wichtig ist und hat halt weniger dorthin investiert. Immerhin haben sie es verbessert. Wenn es absolut relevant wäre, hätte man auch mehr Augenmerk investiert.

edit:
9. Genereation ist auch ziemlich hergeleiert.
1. C1 / Xenos
2. R600
3. RV770 (RV670 war ja nur ein Shrink!)
4. RV870
5. RV970
6. RV1070

Wobei ich mir nichtmal sicher bin, ob sie vor RV870 überhaupt großartig was an der Tesselationseinheit vom C1 geändert haben.
Du hast den R200 vergessen (TruForm).
R200 -> der nichtveröffentlichte R400 -> Xenos/C1 -> R600 -> RV770 -> Cypress -> Barts -> Cayman -> Tahiti

[LovesuckZ]

Das ist keine Frage von Können / Nichtkönnen. Sondern eine von Ressourcenverteilung. Ein solches Front End hätte mehr Transistoren gekostet. AMD war der Meinung, dass Tesselation im Moment noch nicht so wichtig ist und hat halt weniger dorthin investiert. Immerhin haben sie es verbessert. Wenn es absolut relevant wäre, hätte man auch mehr Augenmerk investiert.


Das Front-End ist alleine deswegen schon wichtig, um die Rohleistung auf den Boden zubringen. Man muss sich also schon fragen, wieso nicht dort investiert wird, wo es den größten Nutzen hat.
Und für Tessellation ist es einfach immer noch nicht in der Lage vernünftig mit den Faktoren zu skalieren. Hier kann man sich nicht von GF110 absetzen und in Spielen verringert sich der Abstand zwischen der 7970 und der GTX580.

Da die Spezifikationen bis 64 gehen, könnte man mal nachfragen, ob AMD davon derbe überrascht wurde hat bei der Planung ihrer Architektur.

[Raff]

Das Front-End ist alleine deswegen schon wichtig, um die Rohleistung auf den Boden zubringen. Man muss sich also schon fragen, wieso nicht dort investiert wird, wo es den größten Nutzen hat.
Und für Tessellation ist es einfach immer noch nicht in der Lage vernünftig mit den Faktoren zu skalieren. Hier kann man sich nicht von GF110 absetzen und in Spielen verringert sich der Abstand zwischen der 7970 und der GTX580.

Da die Spezifikationen bis 64 gehen, könnte man mal nachfragen, ob AMD davon derbe überrascht wurde hat bei der Planung ihrer Architektur.

Das Front-End Tahitis genügt zumindest dort, wo man eine High-End-Grafikkarte vorwiegend braucht: bei hübschen Pixeln (viele pro Polygon, nicht mehrere Polygone pro Pixel ;)). Außerdem regelt der Chip bis zum Tessellationsfaktor 8 ziemlich krass, darüber hinaus säuft Tahiti aber wieder stark ab und wird spätestens bei Faktor 16+ wieder von Fermi (dem echten, nicht GF1x4) vernichtet: http://www.pcgameshardware.de/aid,860536/Test-Radeon-HD-7970-Die-erste-Grafikkarte-mit-DirectX-111-PCI-Express-30-und-28nm/Grafikkarte/Test/bildergalerie/?iid=1607694&vollbild

MfG,
Raff

[Captain Future]

Doch, denn gerade vernünftig tut sie sehr wohl skalieren. Nämlich mit Faktoren, die sinnvoll sind und keinen Overkill darstellen. zwischen 4 und 8 sieht man wohl noch Unterschiede, zwischen 24 und 28 aber wohl kaum noch:
http://www.pcgameshardware.de/aid,860536/Test-Radeon-HD-7970-Die-erste-Grafikkarte-mit-DirectX-111-PCI-Express-30-und-28nm/Grafikkarte/Test/bildergalerie/?iid=1607694

edit:
ROFL@RAFF

[LovesuckZ]

Das Front-End Tahitis genügt zumindest dort, wo man eine High-End-Grafikkarte vorwiegend braucht: bei hübschen Pixeln (viele pro Polygon, nicht mehrere Polygone pro Pixel ;)). Außerdem regelt der Chip bis zum Tessellationsfaktor 8 ziemlich krass, darüber hinaus säuft Tahiti aber wieder stark ab und wird spätestens bei Faktor 16+ wieder von Fermi (dem echten, nicht GF1x4) vernichtet: http://www.pcgameshardware.de/aid,860536/Test-Radeon-HD-7970-Die-erste-Grafikkarte-mit-DirectX-111-PCI-Express-30-und-28nm/Grafikkarte/Test/bildergalerie/?iid=1607694&vollbild

MfG,
Raff

Du zeigst keine Skalierung, du zeigst, wenn das Front-End nicht limitiert, die Karte ihre Rohleistung ausspielen kann. Das aber tat auch schon Cayman. Durch das Cachesystem kann man nun länger die Daten "ontheChip" halten und massiv Leistung durch den Offchip-Transfer einsparen. Aber das macht auch Fermi. Und bei Faktor 12(!) von 64 liegt man dann nur noch auf dem Niveau der GTX580. Und wirst in Zukunft nicht verhindern, dass die Entwickler bei 12 cappen. :D

/edit: Die Karte hat bei Faktor 11 schon mehr als die Hälfte ihrer Rohleistung verloren. Bei Faktor 14 nochmal mehr als die Hälfte. Das nennst du "Skalierung"? Ab Faktor 14 pendelt es sich ein, aber dort ist man schon massiv langsamer als GF110 und nur noch auf dem Niveau der GF114...

Doch, denn gerade vernünftig tut sie sehr wohl skalieren. Nämlich mit Faktoren, die sinnvoll sind und keinen Overkill darstellen. zwischen 4 und 8 sieht man wohl noch Unterschiede, zwischen 24 und 28 aber wohl kaum noch:
http://www.pcgameshardware.de/aid,860536/Test-Radeon-HD-7970-Die-erste-Grafikkarte-mit-DirectX-111-PCI-Express-30-und-28nm/Grafikkarte/Test/bildergalerie/?iid=1607694

edit:
ROFL@RAFF

Die Mär vom overkill. Mal einlesen, wieso man hohe Faktoren will. Oder besser: Wieso bist du der Meinung, dass hohe Faktoren Overkill wären, aber anscheinend Microsoft und die Khronos Gruppe es anders sehen?

Aber um Tessellation in Bezug auf "Overkill" will ich hier nicht reden. Führt sowieso zu nichts.

/edit2: Am Ende kommt dann sowas bei raus:
http://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=41488&stc=1&d=1324553864
http://www.ixbt.com/video3/tahiti-part2.shtml

[Raff]

Um ehrlich zu sein, wissen wir doch alle nicht genau, wo "Overkill" anfängt. Ich könnte dir nicht ad hoc sagen, wie viele Pixel bei einem modernen Spiel im Durchschnitt auf einem Polygon liegen und wie viele es sind, wenn man Tessellation dazu gibt.

Klar ist, dass schon Tessellationsfaktor 8, also die Teilung jedes einzelnen Polygons in 8 kleinere Vielecke, eine enorme Steigerung wäre. Und die kann man sehen. 16 womöglich auch noch. Es wäre bereits ein riesen Sprung, wenn jedes Spiel in jeder Szene mit Faktor 8 (Radeon rockt) oder 16 (Geforce rockt) tesselliert wäre.

Später jedoch, bei noch höheren Stufen, stellt sich die Frage nach dem Nutzen, für den man die hohen Kosten (selbst auf Fermi "XT") aufwendet. Die ganzen Ecken wollen auch geglättet werden. Sobald das Bild mit Faktor 32 oder gar 64 vollgepumpt wird, gibt's oft mehr Polygone als Bildschirmpixel (abhängig vom LOD). Das ist bei Popel-Auflösungen wie Full-HD für die Katz und man knüppelt am besten Supersampling drauf. Das kostet wieder.

MfG,
Raff

[LovesuckZ]

Um ehrlich zu sein, wissen wir doch alle nicht genau, wo "Overkill" anfängt. Ich könnte dir nicht ad hoc sagen, wie viele Pixel bei einem modernen Spiel im Durchschnitt auf einem Polygon liegen und wie viele es sind, wenn man Tessellation dazu gibt.

In Hawx2 sind die Dreiecke im Durchschnitt 8x2 Pixel groß mit Tessellation. :)


Später jedoch, bei noch höheren Stufen, stellt sich die Frage nach dem Nutzen, für den man die hohen Kosten (selbst auf Fermi "XT") aufwendet. Die ganzen Ecken wollen auch geglättet werden. Sobald das Bild mit Faktor 32 oder gar 64 vollgepumpt wird, gibt's oft mehr Polygone als Bildschirmpixel (abhängig vom LOD). Das ist bei Popel-Auflösungen wie Full-HD für die Katz und man knüppelt am besten Supersampling drauf. Das kostet wieder.

MfG,
Raff

Es geht bei Tessellation darum mit einem so klein (Anzahl an Controlpoints) wie möglichen Grundmesh die entsprechende gewünschte Qualität zu erreichen. Je größer das Spektrum an Stufen ist, um besser gelingt es. Dabei reden wir nichtmal von "32 oder 64". AMD hat bei Stufe 14 weniger als 1/5 der Ausgangsleistung. Fermi erreicht das erst bei ca. Stufe 32.

[Captain Future]

Es geht bei Tessellation darum mit einem so klein (Anzahl an Controlpoints) wie möglichen Grundmesh die entsprechende gewünschte Qualität zu erreichen. Je größer das Spektrum an Stufen ist, um besser gelingt es. Dabei reden wir nichtmal von "32 oder 64". AMD hat bei Stufe 14 weniger als 1/5 der Ausgangsleistung. Fermi erreicht das erst bei ca. Stufe 32.

Solange wir nicht in der konsolenlosen Zukunft angekommen sind, geht es erstmal darum, dass auch DX9-Level Hardware ohne Tessellation ein Bild produzieren kann, bei dem einem die Kotze nicht im Strahl aus dem Gesicht fliegt - anders also als in Endless City.

[LovesuckZ]

Solange wir nicht in der konsolenlosen Zukunft angekommen sind, geht es erstmal darum, dass auch DX9-Level Hardware ohne Tessellation ein Bild produzieren kann, bei dem einem die Kotze nicht im Strahl aus dem Gesicht fliegt.

Aber in vielen Bereichen sind diese Spiele doch polygonarm und bieten somit die perfekte Möglichkeit für Tessellation und DM. Wände z.B. Paar Dreiecke und eine Mauertextur. Flach wie eine Flunder. Was Crytek in Crysis 2 aus den Wänden, Steinen und generell der Umgebung gemacht hat, ist genial. Und wie man an SI sieht, ist es eben nicht "Overkill", sondern AMD's 40nm Generation einfach zu schlecht für den vernünftigen, auch optisch verändernden Einsatz.

[Captain Future]

Ja, besonders gefallen mir die genialen Bordsteine in Crysis 2... :ulol:
http://www.hardware.fr/medias/photos_news/00/32/IMG0032909_1.jpg

http://www.hardware.fr/articles/838-6/tessellation-loupe.html

[Captain Future]

Klar ist, dass schon Tessellationsfaktor 8, also die Teilung jedes einzelnen Polygons in 8 kleinere Vielecke, eine enorme Steigerung wäre.

Tessellation funktioniert ein wenig anders. Jede Seite eines Meshs wird unterteilt. Da kommen ganz andere tolle Zahlen bei rum.

Kleines Beispiel für Lovesuckz aus der Nvidia Island11 Demo: Mit einer statischen Tessellation von Faktor 13 liegt das durchschnittliche Aufblasen bei Faktor 330 pro Input-Primitive. Da kriegt man schon einiges mit rund.

Und nur zum besseren Verständnis: Bei maximaler Tessellation von 63 und 1 Mrd. Primitives kackt auch die Geforce mit <15 Fps ab.

[LovesuckZ]

Kleines Beispiel für Lovesuckz aus der Nvidia Island11 Demo: Mit einer statischen Tessellation von Faktor 13 liegt das durchschnittliche Aufblasen bei Faktor 330 pro Input-Primitive. Da kriegt man schon einiges mit rund.


Ich kenne die Demo, die Zahlen und die entsprechende Qualität. Nur will niemand einen statischen Faktor über den gesamten Frame haben. ;)

[Captain Future]

Dynamisches LOD ändert daran nichts.

[LovesuckZ]

Dynamisches LOD ändert daran nichts.

Je nach Abstand stimmt es. Da aber die Input-Primitives statisch sind, ist es eben ein Unterschied ob nur 1.000 oder 100.000 erfasst werden.

[Captain Future]

Der Faktor bleibt auch bei dynamischem LOD dreistellig. Und du willst aus einem einzelnen Dreieck ja keinen Kreis machen.

[LovesuckZ]

Der Faktor bleibt auch bei dynamischem LOD dreistellig. Und du willst aus einem einzelnen Dreieck ja keinen Kreis machen.

Natürlich. Das ist doch gerade der Sinn von Tessellation. Ich kann aus einem geringen Grundmesh machen, was ich will. Crytek macht aus einer 4-eckigen eine deutlich dünnere und gewölbte Stange! Aus einer geraden Linie wird eine abgesprochene Kante, die erst den Begriff Natürlichkeit verdient.

Es geht am Ende ja nicht um 13 oder 31. Es geht beim Front-End darum, dass es nicht dermaßen limitiert, dass nur noch 1/5 der Rohleistung bei Faktor 14 von 64 übrig bleibt bzw. zu solch einem zeitlichen Verzug führt, dass die Verarbeitung unnötig Zeit verschwendet.

[Captain Future]

Ich habe gezeigt, eine Verwievielfachung Faktor 13 bereits darstellt. Das genügt locker um aus einem sechseckigen Fass ein rund wirkendes zu machen.

[LovesuckZ]

Ich habe gezeigt, eine Verwievielfachung Faktor 13 bereits darstellt. Das genügt locker um aus einem sechseckigen Fass ein rund wirkendes zu machen.

Trotzdem geht die Spezifikation bis Faktor 64 und AMD hat bei Faktor 14 - ja eins mehr - nur noch 1/5 der Rohleistung. Ich werde darüber auch nicht mehr reden, ob mehr sinn macht oder nicht. Die Spezifikation steht fest. Alles andere ist eben verlorene Zeit. Selbst AMD hat mit ihrer Pre-DX11 Hardware Faktoren bis 32 unterstützt.

[boxleitnerb]

Meinst du, Nvidia wird bei Kepler die Tessleistung nochmal deutlich aufbohren (mind. Faktor 2) oder sich erstmal ausruhen - einen gesunden Vorsprung hat man ja immer noch.

[Captain Future]

Trotzdem geht die Spezifikation bis Faktor 64 und AMD hat bei Faktor 14 - ja eins mehr - nur noch 1/5 der Rohleistung.

Völlig unbestritten. Nur ist diese Rohleistung von vornherein deutlich höher als bei Nvidia. Vielleicht sollte AMD auch mal eine völlig bescheuerte Bremse zwischen Shaderkernen und ROPs einbauen und so die Füllraten niedrig halten damit die Leistungsaufnahme nicht explodiert.

Oh - und zur Info: Nvidia hat bei Faktor 30 auch nur 1/5 seiner Rohleistung übrig und die Spezifikation geht bis Faktor 64... :biggrin:

[Coda]

Das ist doch so gar nicht auslegbar. Wenn ich ein riesiges Dreieck mit 64x Tesselation habe und nah genug ran geht, dann können die resultierenden Dreiecke trotzdem noch sehr groß sein. Da gibt es keinen absoluten Maßstab.

Es wundert mich ohnehin, warum sie nicht einfach ein quasi unendliches Limit definiert haben. Der Hardware könnte das sogar egal sein, je nach Aufbau.

[Captain Future]

Sag' das bitte Lovesuckz. :)

[Coda]

Wer?

[Captain Future]

del

[robbitop]

Du hast den R200 vergessen (TruForm).
R200 -> der nichtveröffentlichte R400 -> Xenos/C1 -> R600 -> RV770 -> Cypress -> Barts -> Cayman -> Tahiti
Truform ist Tesselation?
R400 und C1 sind sich ziemlich nah. C1 wurde schließlich aus R400 gebastelt.
IMO ist "9. Generation" ziemlich auf die Kacke gehauen. :D
So viel hat man an der Einheit eigentlich nicht gedreht. (auch wenn zwischenzeitlich immer neue GPUs herauskamen)

[Coda]

Ja, Truform war Tesselation, aber nichts was du mit dem heutigen Zeug vergleichen kannst.

[kunibätt]

Wie ist eigentlich ein Tesselationsfaktor von zum Beispiel 12 zu verstehen?
Heißt das nun das nach dem Applizieren 12 mal soviele Polygone vorhanden sind?
Ich frage deshalb, weil in vielen (allen?) Modellingprogrammen eine Stufe von Subdivisions den Polygoncount vervierfacht.
Auch würde mich mal der Speicherverbrauch (VRAM) interessieren, der durch Tesselation entsteht. Eine Heightmap pro Objekt (wenn denn wirklich alles tesseliert werden sollte) hat man ja in jedem Fall. Wäre der Speicherverbrauch durch die Geometrie hoch? Und ja der von dem adaptiven LOD abhängig, sprich davon wie nahe ich mich an einem Objekt befinde?

[Coda]

http://fgiesen.wordpress.com/2011/09/06/a-trip-through-the-graphics-pipeline-2011-part-12/

[Gipsel]

Wie ist eigentlich ein Tesselationsfaktor von zum Beispiel 12 zu verstehen?
Heißt das nun das nach dem Applizieren 12 mal soviele Polygone vorhanden sind?
Um mal die Beschreibung in Codas Verlinkung auf das Minimum runterzubrechen:
Die Polygonzahl skaliert quadratisch mit dem Tessfaktor. Im Einzelfall nicht exakt und abhängig von den Edge-Faktoren, der Frage Quad oder Tri und auch gerade oder ungerader Faktor, aber als Daumenregel stimmt es gar nicht so schlecht.
Eine Verdopplung des Tessfaktors bewirkt also eine Vervierfachung der Polygonzahl. Startet man vom Basemesh (also Faktor 1), geht mit niedrigen Faktoren die Dreieckszahl relativ schnell hoch. Die Steigerung von 20 auf 30 ist dann relativ gesehen aber gar nicht mehr so groß (nur ~2,25 mal mehr Polygone, 10 auf 20 vervierfacht sie).

In Deinem Fall mit TF12 wären also über den Daumen grob 144 resultierende Polygone zu erwarten. Das gilt bei tessellierten Quads exakt (falls die Edge-Faktoren auch 12 betragen), was dann also 288 Dreiecke wären. Bei tessellierten Dreiecken wird es etwas komplizierter und ich bin jetzt zu faul das genau auszurechnen ;).

[deekey777]

Truform ist Tesselation?
R400 und C1 sind sich ziemlich nah. C1 wurde schließlich aus R400 gebastelt.
IMO ist "9. Generation" ziemlich auf die Kacke gehauen. :D
So viel hat man an der Einheit eigentlich nicht gedreht. (auch wenn zwischenzeitlich immer neue GPUs herauskamen)
Man muss ja kreativ sein. Schließlich ist Nvidia erst bei Generation 3 angekommen (Ur-NV30 sollte ja auch einen Tessellator haben).

(Wobei der R400 auf der Shader-Seite anders aufgebaut sein soll als Xenos/C1.)

[Felixxz2]

Meinst du, Nvidia wird bei Kepler die Tessleistung nochmal deutlich aufbohren (mind. Faktor 2) oder sich erstmal ausruhen - einen gesunden Vorsprung hat man ja immer noch.

nVidia hat ja keine wirkliche Wahl. Ihre Architektur ist so aufbaut, dass sie für sich selbst skaliert. GF110 hat 4 CUs (heißen die so?) und jede hat für sich ein eigenes, für die Rohleistung gut ausreichendes Front End (1xGeometry, 1x Rasterizer 8Pixel/Takt, 4x Tesselatoren). Wenn du für Kepler die Shader auf 1024 verdoppelst erhälst du automatisch 32 Tesselatoren über den Chip und damit in höheren Tess-Stufen wieder deutlich mehr Leistung. In niedrigen Faktoren wird man aber wohl kaum Steigerungen ggüb. GF110 erzielen können.

In jedem Fall wird das Front End aber deutlich fetter und leistungsfähiger ausfallen als bei der Radeon (Kepler hat dann 8xGeometry, 8xRasterizer mit insg. 64 Pixel/Takt und 32xTesselation; Tahiti kommt nur auf 2xGeometry, 2xRaserizer mit insg. 32 Pixel/Takt und 2xTesselation). Ob das allerdings die deutlich höheren fps/GFLOP/s erklärt würd ich mal bezweifeln.

[Coda]

Man muss ja kreativ sein. Schließlich ist Nvidia erst bei Generation 3 angekommen (Ur-NV30 sollte ja auch einen Tessellator haben).
Wieso drei? Ich zähle zwei. NV20 und Fermi. Niemals ausgeliefertes zählt eher nicht ;)

GF110 hat 4 CUs (heißen die so?) und jede hat für sich ein eigenes, für die Rohleistung gut ausreichendes Front End (1xGeometry, 1x Rasterizer 8Pixel/Takt, 4x Tesselatoren).
Es sind GPCs (Graphics Processing Cluster). Und die Tesselatoren eines GPC sind eben nicht nur für den lokalen GPC zuständig.

In niedrigen Faktoren wird man aber wohl kaum Steigerungen ggüb. GF110 erzielen können.
Um die Leistung mit der Rechenleistung möglichst linear zu skalieren muss man für die gleiche Tesselations-Faktoren eben mehr Tesselatoren/Rasterizer verbauen.

Die Frage ist hier nur inwiefern der Interconnect skaliert. Falls das momentan noch simple Crossbars sind (sind ja nur vier Punkte zu verbinden bei Fermi) wird man das irgendwann in irgend ein Netz umbauen müssen.

In jedem Fall wird das Front End aber deutlich fetter und leistungsfähiger ausfallen als bei der Radeon (Kepler hat dann 8xGeometry, 8xRasterizer mit insg. 64 Pixel/Takt und 32xTesselation; Tahiti kommt nur auf 2xGeometry, 2xRaserizer mit insg. 32 Pixel/Takt und 2xTesselation). Ob das allerdings die deutlich höheren fps/GFLOP/s erklärt würd ich mal bezweifeln.
Ja, da müssen sie ran. Ich traue den Leuten ohne weiteres zu so etwas wie Pommegranate/Fermi zu bauen, aber es kostet halt enorm R&D-Aufwand, weil es ein riesiger Bruch mit den bestehenden Verfahren ist.

Meiner Meinung nach verhungert der Chip aber daran und das nicht nur bei Tesselation.

[Captain Future]

Das "schlimmste" am Fermi ist aber wohl, dass die Threads nach der Tessellation wieder neu durch den Scheduler laufen und nicht in einer Einheit festhängen, also ein Fabric, welches am Ende der 16 SMs liegt. Sowas fehlt bei Radeon kpl.

[Felixxz2]

Ja, da müssen sie ran. Ich traue den Leuten ohne weiteres zu so etwas wie Pommegranate/Fermi zu bauen, aber es kostet halt enorm R&D-Aufwand, weil es ein riesiger Bruch mit den bestehenden Verfahren ist.

Meiner Meinung nach verhungert der Chip aber daran und das nicht nur bei Tesselation.

Du wärst also auch der Meinung dass Tahiti "verhungert"? Hätte man also von allem 4 Stück nehmen sollen oder gleich das Front End neu entwickeln?

Finde es zumindest bei Tahiti enorm komisch, denn das fps/GFLOP/s Verhältnis ist schlechter als bei Cayman. Im Prinzip ist die Auslastung also nicht gestiegen, sondern sogar leicht gesunken und das trotz 1D Shader. Irgendwas stimmt da auf jeden Fall überhaupt nicht.

[Coda]

Am Compute-Teil liegt es nicht, das sieht man an GPGPU-Sachen. Die ROPs/Cache-Architektur wird es auch nicht sein.

Bleibt also nur noch der Rasterizer etc. AMD hat aber auch einen Nachteil, weil sie 64er Thread-Groups benutzen, statt 32er. Der Verschnitt ist also höher. Man sieht ja auch, dass sie dadurch Vorteile in höheren Auflösungen (= größere Polygone) haben.

Die Sache ist, dass sie jetzt eigentlich mit den CUs durch sind für eine Weile, deshalb erwarte ich für die nächste Generation da eigentlich Fortschritte.

[Felixxz2]

Jop stimmt, das bekräftigt die These sehr. In GPGPU ist die 7970 ja ca. doppelt so schnell wie die 6970, in Spielen sinds nur 35-40%. Also haben sie anscheinend durch ein schlechtes Frontend mal wieder massig Leistung verschenkt.

Ist ja nicht so, als ob das das erste Mal wäre :freak:

[Coda]

Naja, es gibt auch noch den Fall, dass die Bandbreite limitieren würde. Aber das kann ich mir bei 384 bit GDDR5 bei dem Takt eigentlich nicht vorstellen.

Texturleistung ist auch massig vorhanden.

[Felixxz2]

Jop und die ROPs reichen auch aus. Von der Rohleistung ist der Chip echt ziemlich krass, ich mein 3,8 TeraFLOP/s, 118 GigaTEXEL/s und 264GB/s :eek:
Aber was davon auf die Straße kommt ist mehr als kläglich....

Mal schauen was GK100 macht, 1024 Shader bei ~800MHz/1600MHz/2750MHz wären wohl schneller als GTX580 SLI.

[Nighthawk13]

Bleibt also nur noch der Rasterizer etc. AMD hat aber auch einen Nachteil, weil sie 64er Thread-Groups benutzen, statt 32er. Der Verschnitt ist also höher. Man sieht ja auch, dass sie dadurch Vorteile in höheren Auflösungen (= größere Polygone) haben.
Wie funktioniert denn die Anbindung Rasterizer->CU genau(für Pixelshader)?

Beim Rasterizer fallen hinten 2x2-Pixel-Quads raus, 16 Quads ergeben eine Wavefront(16*4=64) für die Pixel-Shaderberechnung(nehm ich mal an).
Müssen die Quads für eine Wavefront aus einem Dreieck kommen oder können das bis zu 16 Mini-Dreiecke sein?