Diskussion zu: Ein erster Blick auf die G80-Technologie

[Leonidas]

Link:
http://www.3dcenter.org/artikel/2006/12-28_a.php

[The Master]

im artikel ist die kommentarfunktion falsch verlinkt ;)

[Leonidas]

jau, wird gefixt.

[la.ultima]

Hi!

Toller Bericht, obwohl mir etwas der Kopf geraucht hat beim lesen!

Da ich erst wieder vor kurzem auf eine 8800GTX (vorher ATI) umgestiegen bin, gehe ich nach dem Bericht davon aus, Antisotrope Filterung 16x und AA 8xQ bringt mir die beste Bildqualität! Richtig??

Was sollte man aber zuerst senken, vorallem bei "hungrigen" Games, AF runter oder AA?? Wohl AA oder liege ich da falsch?

Grüße

[blackbox]

Habe den Artikel überfolgen, vermissen tu ich aber einen Kritikpunkt: Der Energiebedarf der GPU. Der sollte aus technischer Sicht nicht fehlen.

[AnarchX]

Habe den Artikel überfolgen, vermissen tu ich aber einen Kritikpunkt: Der Energiebedarf der GPU. Der sollte aus technischer Sicht nicht fehlen.

Warum sollte man die gute pro-Watt-Leistung des G80 kritisieren? ;)

[Ronny145]

Warum sollte man die gute pro-Watt-Leistung des G80 kritisieren? ;)



Wenns um den Idle Werte geht, den darf man schon kritisieren. Oder wurde das schon behoben?

[AnarchX]

Wenns um den Idle Werte geht, den darf man schon kritisieren. Oder wurde das schon behoben?
Ja, das ist natürlich noch ein Problem, aber welches wohl bald per neuem Treiber gelöst werden soll.

[Ronny145]

Ja, das ist natürlich noch ein Problem, aber welches wohl bald per neuem Treiber gelöst werden soll.


Daran glaube ich ehrlich gesagt nicht. Ich dachte NVIDIA hätte das sogar dementiert.

[Hvoralek]

Wenn ich das richtig verstanden habe, führen die einzelnen Kanäle einer Vec16- ALU jeweils genau dieselbe Operation auf 16 verschiedene Pixel aus. Verschlimmert sich dadurch nicht der Verschnitt, den man schon bei normaler Quadbauweise bekommt?

Da ich erst wieder vor kurzem auf eine 8800GTX (vorher ATI) umgestiegen bin, gehe ich nach dem Bericht davon aus, Antisotrope Filterung 16x und AA 8xQ bringt mir die beste Bildqualität! Richtig??16x AF stimmt (trilinear musst Du anscheinend von Hand einstellen), allerdings sollte 16xQ noch etwas besser sein als 8xQ. Die EER für z/stencil- Werte beträgt bei beiden 8, für Farbwerte allerdings in 8xQ "nur" ebenfalls 8, in 16xQ aber 16. Ob man den Unterschied wirklich sieht, ist eine andere Frage.

Was sollte man aber zuerst senken, vorallem bei "hungrigen" Games, AF runter oder AA?? Wohl AA oder liege ich da falsch?Dem G80 sollte meist eher die Bandbreite ausgehen als die Füllrate, also AA, ja

[aths]

Wenn ich das richtig verstanden habe, führen die einzelnen Kanäle einer Vec16- ALU jeweils genau dieselbe Operation auf 16 verschiedene Pixel aus. Verschlimmert sich dadurch nicht der Verschnitt, den man schon bei normaler Quadbauweise bekommt?Nein, da andere Stellen lange vorher limitieren. Der G80 ist besser geeignet, um viele kleine Dreiecke zu rendern oder mit häufigem Renderstate-Wechsel zurechtzukommen, als der G71.

Dem G80 sollte meist eher die Bandbreite ausgehen als die Füllrate, also AA, jaDas kann man so pauschal nicht sagen.

Allgemein noch: Die 3D-Leistung des G80 ist enorm. Auch Anwendungen die mir schon mit der 7600 GT "vollkommen flüssig" vorkamen, erschienen mit dem G80 unerwarteterweise noch flüssiger.

[RLZ]

Inhaltlich sehr gut.
Stilistisch liest es sich manchmal noch etwas seltsam. (Zeitdruck?)

[The Master]

schön das es so schnell gefixt wurde ;)

@artikel...

der artikel gefällt mir sehr gut!!! *hut ab für die ganzen details*

aber selbst mir als eingefleischter 3dcenter leser und edv techniker hat der kopf auch etwas geraucht umd alles genau zu verstehen!! einfachere beispiele würden ein breiteres Puplikum auch ansprechen -> beide Welten kompinieren wäre nicht schlecht!

sonst kann ich nur sagen ganz ganz ganz großes lob an die redaktion

ps: es ist spät und ich achte gerade garnicht auf die rechtschreibung...man möge mir das bitte vergeben ;)

[Gast]

Zitat:
"dass auch bei aktiviertem AF standardmäßig trilineare Filterung geboten wird und nicht nur "brilineare""
Ich denke alle Optimierungen sind bei Default Aus auf G80? Ich habe auf "Hohe Qualität" und zusätzlich im nHancer alle Optimierungen gekillt.
Gibt es irgendwo im NV-Treiber noch ein Häkchen was ich setzen kann, daß wirklich ALLE Optimierungen aus sind?

[Corrail]

kleine Korrekturen:
bei der theoretischen ALU Leistung: 173+346 = 519 und nicht 518 ;)
Und die Einheiten in der Tabelle stimmt nicht ganz... Sollte GFlops sein, oda vertu ich mich da grad?

Wir möchten die Texturfilter-Performance heute nicht im Detail behandeln...

Ein (wiedermal) sehr guter Artikel, vielen Dank! Hat mir nette Einblicke in die Technologie der aktuellen GPU Serie gebracht.

[Rumbah]

RSQ 1/x^0,5

Es wird wirklich der Kehrwert der Wurzel berechnet oder ist das nur ein Fehler im Artikel? Weil sonst muss ja für das einfache Wurzelziehen zweimal der Kehrwert gebildet werden. Oder kommen Längen- bzw. Normierungsberechungen so oft vor, dass man auf eine einfach normale Wurzel verzichten kann?

[tombman]

Finde den Artikel recht gut, aber ich hätte mir ergänzende Grafiken gewünscht. (Pipeline Schema etc)

[Roi Danton]

32bit Texturen: Ist das derzeit sinnvoll, da doch die derzeit erhältlichen Bildschirme auf dem Massenmarkt meines Wissens nach gar nicht so eine breite Farbverteilung darstellen können? Oder wird RGBA8888 nur für interne Berechnungen genutzt und dann für die Anzeige auf 8bit runtergerechnet (also helle & dunkle Flächen - die bei einer 8bit Textur nicht in äquivalentem Detail gleichzeitig zu sehen wären - bevorzugen ... so, als würde ich eine Belichtungsreihenaufnahme in ein 8bit-Bild runterrechnen)?

Btw, falsche Einheiten in der Tabelle auf Seite 1: Laut der vorangegegangen Rechnung müssten GFlops/s anstatt MFlops/s stehen (8 x 16 x 3Flops x 1350MHz = 518400 Flops*MHz = 518GFlops/s).

[Blutmaul]

Wegen GPU Physik, ein Auszug aus einem älteren Interview mit Tim Sweeney:

Jacob- Havok recently announced the ability to accelerate physics on the GPU. Is that necessarily a bad idea?

Sweeney- That’s a good approach, they have some good technology there. Havok has a physics system that runs largely on the GPU to accelerate the computations there. It seems to be a lower precision physics than you have for the rest of the game which is problematic. You really want all the physics in the world to be drawing with a constant level of precision, so you don't have to make weird trade-offs there. I guess there is also the trade-off with that, if your GPU is doing both physics and graphics, then you are not getting the full utilization out of the system.

Interview:
http://www.nvnews.net/vbulletin/showthread.php?t=70056

[Gast]

sehr guter artikel auch wenn ich die hälfte nicht versanden habe ^^

[Gast]

Sehr guter Artikel in gewohnter Aths-Qualität. Danke dafür. :)

Noch eine Anmerkung:
dass auf jedem 1280x1024-TFT ohne Probleme 1280x960 im 4:3-Modus genutzt werden kann (selbst mit PowerStrip ist uns das nicht geglückt!)Bei meinem G70 funktioniert das einwandfrei, sofern der TFT über DVI angeschlossen ist. Ist leider oft nötig auf einem 5:4-TFT 1280x960 mit Balken zu fahren, weil es immer noch genug Spiele gibt, die nur 4:3-Auflösungen unverzerrt darstellen können. Funktioniert das etwa beim G80 nicht mehr? Kann ich mir kaum vorstellen. Im Panel einfach auf "centered output" stellen und man hat 1280x960 mit Balken. Geht aber nur bei TFTs, die über DVI angeschlossen sind.
Noch was:
dass "Digital Vibrance Control" nicht mehr mit "Digitale Schwingung" übersetzt wird;D

Gruß,
ein Gast

[MGeee]

Was im Artikel nicht genannt wurde, ist die Möglichkeit, GPUs als Distributed-Computing Werkzeuge zu nutzen.
Derzeit kann man im Folding@Home Projekt (http://folding.stanford.edu/) mit einer ATI Grafikkarte (ab X1800) crunchen.

Die reine Rechenleistung der aktuellen GPUs (also der ATI X1800/X1900 Generation) liegt bei ca. dem 40 fachen einer aktuellen CPU!

Mehr Infos hier: crunchen mit der GPU (http://folding.stanford.edu/FAQ-ATI.html)

Leider werden noch keine Nvidia-Grafikkarten unterstützt...sobald dies jedoch der Fall sein wird, werde ich mir wohl ein entsprechendes Modell zulegen :) .

[aths]

kleine Korrekturen:
bei der theoretischen ALU Leistung: 173+346 = 519 und nicht 518 ;)Die Werte sind gerundet. Rechnet man die Summe auch exakt aus und rundet dann, stimmen die 518.

Und die Einheiten in der Tabelle stimmt nicht ganz... Sollte GFlops sein, oda vertu ich mich da grad?Korrekt, da sollte GFlop/s stehen.

[aths]

Es wird wirklich der Kehrwert der Wurzel berechnet oder ist das nur ein Fehler im Artikel? Weil sonst muss ja für das einfache Wurzelziehen zweimal der Kehrwert gebildet werden. Oder kommen Längen- bzw. Normierungsberechungen so oft vor, dass man auf eine einfach normale Wurzel verzichten kann?Es wird der Kehrwert der Wurzel berechnet. Um die einfache Wurzel zu bekommen, ist also noch ein RCP nötig. Warum das so ist, weiß ich nicht. Vermutung: Man benötigt meistens X/SQR(Y), so dass man im Shader eben X * RSQ(Y) berechnet.

[aths]

Finde den Artikel recht gut, aber ich hätte mir ergänzende Grafiken gewünscht. (Pipeline Schema etc)Hier fehlen mir eine Menge Details.

32bit Texturen: Ist das derzeit sinnvoll, da doch die derzeit erhältlichen Bildschirme auf dem Massenmarkt meines Wissens nach gar nicht so eine breite Farbverteilung darstellen können? Oder wird RGBA8888 nur für interne Berechnungen genutzt und dann für die Anzeige auf 8bit runtergerechnet (also helle & dunkle Flächen - die bei einer 8bit Textur nicht in äquivalentem Detail gleichzeitig zu sehen wären - bevorzugen ... so, als würde ich eine Belichtungsreihenaufnahme in ein 8bit-Bild runterrechnen)?Ob 32-Bit-Texturen sinnvoll sind, hängt davon ab. DXT1 bietet oft ausreichende Qualität bei nur 4 Bit pro Texeln.

[aths]

Sehr guter Artikel in gewohnter Aths-Qualität. Danke dafür. :)

Noch eine Anmerkung:
Bei meinem G70 funktioniert das einwandfrei, sofern der TFT über DVI angeschlossen ist. Ist leider oft nötig auf einem 5:4-TFT 1280x960 mit Balken zu fahren, weil es immer noch genug Spiele gibt, die nur 4:3-Auflösungen unverzerrt darstellen können. Funktioniert das etwa beim G80 nicht mehr? Kann ich mir kaum vorstellen. Im Panel einfach auf "centered output" stellen und man hat 1280x960 mit Balken. Geht aber nur bei TFTs, die über DVI angeschlossen sind.Das ging auf meinen NV-Karten auch, aber nur wenn ich vorher mit PowerStrip den 1280x960-Modus hinzugefügt habe. (Das war immer problematisch, aber sofern man den zweiten Monitor deaktiviert dann doch irgendwie hinzukriegen.) Beim G80 habe ich das mit den damals verfügbaren Treibern nicht geschafft. Die Möglichkeit, benutzerdefinierte Auflösungen direkt im NV-Treiber hinzuzufügen, funktionierte bei mir ohnehin noch nie (um 1280x960 hinzuzufügen.) Beim Test mit dem G80 habe ich extra noch eine edierte Inf-Datei für den Monitor installiert, um sicherzustellen, dass der Monitor 1280x960 kennt. Es klappte trotzdem nicht. Jetzt mit der 7600 GT nutze ich natürlich in Spielen die 960-er Auflösung.

[aths]

Was im Artikel nicht genannt wurde, ist die Möglichkeit, GPUs als Distributed-Computing Werkzeuge zu nutzen.
Derzeit kann man im Folding@Home Projekt (http://folding.stanford.edu/) mit einer ATI Grafikkarte (ab X1800) crunchen.Mir ist nicht bekannt, dass das mit einer GeForce geht, deshalb beschränkte ich mich im Artikel auf die Aussage, dass die prinzipielle allgemeine Verwendbarkeit gegeben ist.


sehr guter artikel auch wenn ich die hälfte nicht versanden habe ^^Das ist schade, da sich der Artikel eigentlich an eine breite Leserschaft wenden soll. Was waren denn die schwierigsten Stellen?

[Superheld]

schöner Artikel
jetzt weis ich endlich das 8*Q richtiges 8x Multisampling ist:smile:
aber die Bezeichnungen dafür sind trotzdem für die Tonne

[MGeee]

Mir ist nicht bekannt, dass das mit einer GeForce geht, deshalb beschränkte ich mich im Artikel auf die Aussage, dass die prinzipielle allgemeine Verwendbarkeit gegeben ist.

Du hattest ja im unter "Physik" bereits geschrieben, dass man mit der passenden Schnittstelle zukünftig die GPUs als massive paralle CPU nutzen kann.
Der F@H-GPU-Client ist meines Wissens nach die erste Software, welche die hohe Leistung der GPU "zweckentfremdet".

[deekey777]

Man darf nicht auf die Idee kommen, von "eigentlich 64 TMUs" auszugehen, weil pro Takt eben nur maximal 32 gefilterte Texel erzeugt werden können. Die 32 G80-TMUs sind jedoch besser als 32 trilineare TMUs, weil auch AF beschleunigt wird. Der NV10-Chip (GeForce 256) hat mit einem ähnlichen System nur trilineare Filterung beschleunigen können. Mit Beschleunigung trilinearer Filterung wird natürlich auch trilineares AF beschleunigt – die GeForce4 Ti konnte jedoch, als Ausnahme, mit zwei vollen bilinearen TMUs pro Pixelpipe erstaunlicherweise bilineares AF nicht beschleunigen, was noch die GeForce3 bot, und die GeForceFX ebenfalls beherrscht.
Unnötig, da Nebensatz.
Wir verzichten ganz bewusst darauf, jetzt Screenshots zu bringen, die zeigen sollen, was mit Direct3D10 nun möglich würde. Erstens wären praktisch alle Szenen auch mit Direct3D9 zu rendern, nur eben in geringerer Geschwindigkeit, und zweitens spiegeln Techdemos nicht das wieder, was wir dann in Spielen erwarten dürfen. Und wieder einmal – wie oft noch? – wird uns Displacement-Mapping versprochen. Hierbei gibt es allerdings eine Reihe an prinzipiellen Problemen, die den großflächigen Einsatz in frei begehbaren Spielwelten erschweren

[aths]

Schreibfehler bitte immer mit Seitenangabe (bzw. URL) bringen.

[Gast]

sehr schöner artikel, ich finde es etwas schade dass praktisch garnicht auf die "spielerei" CSAA eingegangen wird. ich finde das feature ehrlich gesagt sehr sinnvoll, schließlich gibt es verdammt gute polygonkantenglättung bei wesentlich besserer performance. vor allem an stellen die TSAA benötigen ist natürlich ein hoher MSAA-anteil (und damit automatisch ein hoher TSAA-anteil) vorzuziehen. ansonsten bringt aber CSAA praktisch die gleiche glättung bei deutlich besserer performance, und selbst im schlimmsten fall wenn TSAA mal nicht funktioniert gibt es ja immer noch automatisch zumindest 4xMSAA, was ja bis vor kurzem auf nvidia-karten sogar das maximum darstellte ;) (hybridmodi und SSAA mal außen vor)

[Xmas]

Es wird der Kehrwert der Wurzel berechnet. Um die einfache Wurzel zu bekommen, ist also noch ein RCP nötig. Warum das so ist, weiß ich nicht.
Weil RSQ sich in Hardware effizienter implementieren lässt als sqrt (und dazu noch häufig nützlicher ist).

[Gast]

Hi

Wie soll ich das verstehen ?

Pro Takt wird damit eine Komponente von 16 Pixeln (4 Quads) berechnet.

[Gast]

Hi

Wie soll ich das verstehen ?


na so wie es dortsteht ;)

ein ALU-block arbeitet immer an 16 pixeln gleichzeitig, wobei (idealerweise) jeden takt für jeden dieser 16 pixel eine komponente fertigberechnet rauskommt.

um alle 4 kanäle zu berechnen brauchen diese 16 pixel also 4 takte, im gegensatz zum "alten" ansatz nur 4 pixel gleichzeitig zu berechnen, dafür aber alle 4 komponenten/pixel gleichzeitig.

wenn alle 4 komponenten der gleichen berechnung folgen kommt es am ende auf das selbe raus, werden aber ein paar komponenten nicht gebraucht, oder aber es kommen mehr als 2 unterschiedliche berechnungen/pixel zum einsatz (NV4x/G7x können pro pixelvektor 2 verschiedene operationen verarbeiten, sowohl in 3:1 als auch in 2:2 aufteilung, radeons können das ganze sogar nur in 3:1-aufteilung) kann der G80-ansatz in vielen fällen die hardware effizienter ausnutzen.

der ansatz und die zielsetzung ist hier völlig anders als bei NV4x/G7x. während man bei der cineFX-architektur eher darauf geachtet hat möglichst viele recheneinheiten mit möglichst geringem transistoraufwand zu verbauen (G71 kommt theoretisch immerhin auf 48MADDs/takt, gleich viel wie der R580, bei fast 100Mio. transistoren weniger), dabei aber kompromisse bei der auslastung in kauf nehmen musste, ist man beim G80 offenbar den weg gegangen, eher wenige und simple recheneinheiten zu verbauen die am ende aber durch den hohen takt und die gute auslastung trotzdem sehr viel leistung bringen.

[Hvoralek]

Ich glaube, es geht ihm einfach um den Begriff "Komponente". In diesem Zusammenhang ist ein Kanal gemeint: Ein Farbwert setzt sich aus Rot, Grün, Blau und Alpha (Transparenz) zusammen. Jede Vec16- ALU berechnet einen dieser vier Werte für 16 Pixel gleichzeitig.

[Gast]

sehr netter artikel, war sehr interessant zu lesen
und auch für einen interessierten laien größtenteils sehr gut zu verstehen

[Gast]

...allerdings sollte 16xQ noch etwas besser sein als 8xQ. Die EER für z/stencil- Werte beträgt bei beiden 8, für Farbwerte allerdings in 8xQ "nur" ebenfalls 8, in 16xQ aber 16.
wie ändert sich nur die EER ?
die anzahl der subpixel doch auch, oder hab ich da was falsch verstanden

[Hvoralek]

wie ändert sich nur die EER ?
die anzahl der subpixel doch auch, oder hab ich da was falsch verstandenDurch die Erhöhung der Subpixelanzahl ändert sich die EER. Siehe dazu auch: http://www.3dcenter.org/artikel/anti-aliasing-masken/

[Gast]

ah ok, hattest dich komisch ausgedrückt
hat sich so angehört als ob
denn wenn du schreibst höheres EER schließt das ja nicht sofort mehr subpixel mit ein, was ja der hauptvorteil ist
ein größeres EER allein bringt in diesem fall ja nicht soo viel

[LovesuckZ]

Laut Nvidia wären die "Coverage Samples" von den "color/z/stencil Samples" entkoppelt. Danach zeigen sie dieses Bild:
http://developer.nvidia.com/docs/IO/37516/sample_coverage.gif

Bedeutet das, dass die "color/z/stencil Samples" beim CSAA je nach Bedingung auf der Maske plaziert werden?

[aths]

Nvidias Erklärung zu CSAA ist nicht besonders hilfreich. Mangels besserer Quellen habe ich derzeit keine exakte Erklärung zu CSAA anzubieten. Allerdings interessiert mich CSAA auch relativ wenig – imo ist es nicht sehr sinnvoll, an räumlicher Z-Auflösung zu sparen.

[Gast]

Bedeutet das, dass die "color/z/stencil Samples" beim CSAA je nach Bedingung auf der Maske plaziert werden?

ich denke die color+z/stencil-samples werden garnicht wirklich auf der maske platziert, sondern haben garnichts direkt mit der maske zu tun.

ich stelle mir das so vor, dass die Z/Stencil und farbinformationen in einem art container gespeichert werden und die coverage-samples nichts anderes als zeiger sind die fur das jeweilige sample auf den richtigen platz im container zeigen.

[Gast]

Allerdings interessiert mich CSAA auch relativ wenig – imo ist es nicht sehr sinnvoll, an räumlicher Z-Auflösung zu sparen.

wieso nicht? wo gibt es denn noch probleme, außer den shadow-volumes?

und nicht zu vergessen dass es auch in diesen kritischen fällen immer noch 4xRGAA gibt.

[tokugawa]

wieso nicht? wo gibt es denn noch probleme, außer den shadow-volumes?

und nicht zu vergessen dass es auch in diesen kritischen fällen immer noch 4xRGAA gibt.

Shadowmapping ist bezüglich Z-Auflösung kritischer als Shadowvolumes.

Da hätte man sogar gern einen 64-bit Z-Buffer :)

Und Shadowmapping scheint sich derzeit als die aktuell meistverwendete Echtzeitschattentechnik zu etablieren.

[aths]

ich denke die color+z/stencil-samples werden garnicht wirklich auf der maske platziert, sondern haben garnichts direkt mit der maske zu tun.

ich stelle mir das so vor, dass die Z/Stencil und farbinformationen in einem art container gespeichert werden und die coverage-samples nichts anderes als zeiger sind die fur das jeweilige sample auf den richtigen platz im container zeigen.Das ist auch eine meiner Theorien – aber wenn man das zuende durchdenkt, wäre das schwierig umzusetzen. Vor allem bei den Z-Werten. Ich vermute, dass CSAA eher nachträglich rangebastelt wurde und einfacher realisiert worden ist, als man zunächst denken mag. Leider machte der G80 mein System (trotz Netzteil-Wechsel) instabil so dass ich meine AA-Tests nicht vornehmen konnte.

wieso nicht? wo gibt es denn noch probleme, außer den shadow-volumes?

und nicht zu vergessen dass es auch in diesen kritischen fällen immer noch 4xRGAA gibt.Wenn die Z-Zuordnung danebengeht, kann sich das Endergebnis verschlechtern. In diesem Falle wäre z. B. eine fixe CS-MS-Zuordnung günstiger, um tatsächlich 4x sparse-grid-Glättung bei Stencil-Schatten zu bekommen.

Wie gesagt halte ich die CSAA-Technik bislang für Spielerei. Während NV das bisher als Erweiterung von MSAA feiert, und ich mich zur Not mit Z3 anfreunden könnte, halte ich CSAA bisher für einen Modus um mit großen Zahlen protzen zu können (sechszehnfach AA!!11)

Mit 8x sparse grid Transparency MSAA (vor allem mit adaptivem Supersampling) bietet der G80 hervorragende "echte" Kantenglättung. Da lob ich mir meine relativ grobe Auflösung von ca. 83 dpi – so sah man gut den Nutzen von 8x AA =)

[Xmas]

Shadowmapping ist bezüglich Z-Auflösung kritischer als Shadowvolumes.

Da hätte man sogar gern einen 64-bit Z-Buffer :)
Es ging aths wohl eher um die Verteilung der Z-Samples, nicht um die Z-Auflösung. Und ein FP32 Z-Buffer ist in den allermeisten Fällen vollkommen ausreichend. 64 Bit wären größtenteils verschwendet wenn man nicht auch die VS-Präzision deutlich erhöht.

[deekey777]

Der G80 hat nun "skalar" genannte ALUs, aber immer für 16 Pixel zusammen. Man kann deshalb auch von einer Vec16-ALU sprechen, die für 16 Pixel jeweils eine einzelne Vektor-Komponente, sprich einen Skalar berechnet. Im Klartext: Der G80 hat keine 128 skalaren Pipelines. Ebensowenig hat der G70 24 Pixel-Pipelines – es sind sechs Quadpipes. Der G80 hat acht Vec16-Pipelines, die aber effizienter genutzt werden als die G70-Rechenwerke.
Führt die einzelne Vec16-ALU eine skalare Operation pro Kanal nicht für 32 Pixel aus (=Thread-Größe bzw. die Granularität)?

€: Hat sich erledigt. Es werden 16 Pixel pro Takt berechnet, wie konnte ich das nur anzweifeln. :D

[deekey777]

Push. :biggrin:

Rather than wonder about a discrete CB cache, I changed it to read that there definitely is one since we've since confirmed that's the case.
Confirmation that scheduler clock runs at half the shader clock (675MHz for 8800 GTX f.e.).
Confirmation that the missing MUL is serial to interp/SF and not available for general shading just now.
Confirmation that SPs are arranged '8x2' in a G80 shader cluster.
Confirmation that each cluster has its own dedicated register space rather than wondering.

Those are the big changes in presented info, the rest was mostly just correcting layout issues, grammar and spelling, etc.
http://www.beyond3d.com/forum/showpost.php?p=902451&postcount=5
Nach Jaweds Posting wollte ich den Thread irgendwie nicht lesen, somit habe ich diese Info verpasst.;(

[Spasstiger]

Guter Artikel, fands aber auch etwas schade, dass auf das Thema CSAA nicht näher eingegangen wurde. Gibt nirgendwo eine 100% schlüssige Erklärung. In manchen Reviews liest man sogar, dass bei CSAA mehr z-samples als color-samples verwendet werden, was ja definitiv nicht der Fall ist.

[deekey777]

na so wie es dortsteht ;)

ein ALU-block arbeitet immer an 16 pixeln gleichzeitig, wobei (idealerweise) jeden takt für jeden dieser 16 pixel eine komponente fertigberechnet rauskommt.
Ergänzung:
Nicht immer, sondern maximal. Es ist auch möglich, dass gleichzeitig an zwei verschiedenen Thread-Typen gearbeitet wird (PS+VS oder VS+GS), zB 8 Pixel und 8 Vertizes.

um alle 4 kanäle zu berechnen brauchen diese 16 pixel also 4 takte, im gegensatz zum "alten" ansatz nur 4 pixel gleichzeitig zu berechnen, dafür aber alle 4 komponenten/pixel gleichzeitig.

In der aktuellen PCGH steht ein Satz, der bei mir für Verwirrung sorgte (Seite 151): Der G80 kann zwar eine Operation für einen Kanal ausführen, aber nicht zwingend für andere. Das können weder der G70 noch R520, sie führen die gleiche Berechnung für alle Kanäle aus.
Wirklich tolles Design.:)

[Gast]

Die Forderung nach Oversampling aka SSAA erfreut mich sehr, insbesondere in der Form der Einstellbarkeit in 0,5er-Schritten pro Achse. Wäre eine wirkliche Verbesserung in einem Punkt, in dem G80 seinen Vorgängern (sogar nv10 :usad:) momentan unterlegen ist. Nur wundere ich mich darüber, dass du nicht auch gleichzeitig volles nichtadaptives SGSSAA einforderst (die HW kanns ja), was im Forum ja bisher stets deine Position war. Sinneswandel oder nur vergessen?

[aths]

Die Forderung nach Oversampling aka SSAA erfreut mich sehr, insbesondere in der Form der Einstellbarkeit in 0,5er-Schritten pro Achse. Wäre eine wirkliche Verbesserung in einem Punkt, in dem G80 seinen Vorgängern (sogar nv10 :usad:) momentan unterlegen ist. Nur wundere ich mich darüber, dass du nicht auch gleichzeitig volles nichtadaptives SGSSAA einforderst (die HW kanns ja), was im Forum ja bisher stets deine Position war. Sinneswandel oder nur vergessen?In so einem Einführungs-Artikel gilt es, eine sinnvolle Auswahl zu treffen. Es wäre nett, 2x, 4x und 8x sparse grid Supersampling zu haben. Allerdings ist im gesamten Artikel die AA-Thematik relativ knapp behandelt worden. Einerseits, weil der Artikel relativ kurz werden sollte und andererseits, da mir Details zum CSAA fehlten (bis heute übrigens habe ich CSAA noch nicht in allen Einzelheiten durchschaut.)

Die Liste am Ende des Artikels soll verdeutlichen, dass mir der Fortschritt auf der Software-Seite noch zu mager ist. Ansonsten war es mir wichtig, standardmäßig volle trilineare Filterung auch bei aktiviertem AF zu fordern. Um dies nicht in anderen großen Forderungen untergehen zu lassen, hielt ich mich mit der Liste relativ kurz.

Außerdem hätte ich ansonsten lang und breit begründen müssen, warum ich einerseits generelles Supersampling als allgemeine, sinnvolle BQ-Maßnahme ablehne, andererseits aber trotzdem gerne Supersampling-Modi zur Auswahl hätte. In einem möglicherweise noch erscheinendem Artikel zum G80-AA würde ich aber die eigentlich mögliche SGSSAA-Option ansprechen und bedauern, dass wir sie nicht angeboten bekommen.

[Gast]

Hallo!
Guter Artikel, schön auch mal ein paar positive Worte zu OpenGL zu lesen!
Was allerdings nicht ganz stimmt ist, dass alle Effekte auch mit der Vorgängergeneration machbar wären.
-Render to 3D-Texture
-Geometry Shader (z.B. wichtig für Displacement Mapping...)
-Cubemap Shadow Lookup
z.B. sind neu und werden sicher einige nette neue Effekte zaubern. Theoretisch könnte man mit viel CPU-Einsatz, komplexen Shadern und Lookup-Texturen Ähnliches natürlich auch mit älteren Grafikkarten realisieren, aber in der Praxis werden wir wohl durchaus "neue" Effekte zu sehen bekommen.
Viele Grüße,
Simon