Archiv verlassen und diese Seite im Standarddesign anzeigen : Pixelshader, Pipelines, ALUs etc … nun mal Butter bei die Fische
dr.denton
2006-02-16, 11:27:13
Moin zusammen,
ich bin hier wohl der aktuellste Neuzugang aus dem P3Dnow! Forum und möchte euch GPU Profis gleich mal mit einigen Fragen löchern (und nein, diese Fragen konnte mir bisher keine Publikation, ob online oder auf Papier, beantworten - auch die SuFu hat mir nicht weitergeholfen ;) ).
Bisher war ich, aufgrund eines Artikels auf 3dcenter, der Meinung, dass man bei einer modernen GPU - ab DX8 - nicht mehr von "Pixelpipelines" sprechen kann, da sich das Verhältnis von Rastereinheiten, Pixeleinheiten und TMUs aufgelöst habe - so weit einzusehen, da ja immerhin der GPU mit den Shadern wirkliche "Rechenarbeit" zufällt und nicht mehr nur stures "Durchschleusen" von Pixeln ...
Nun wird aber z.B. im Zusammenhang mit dem R530 bzw. R580 ständig davon gesprochen, diese hätten zwar "nur" 4 bzw. 16 "Pipelines", jedoch 12 bzw. 48 Pixelshader; wie darf man das verstehen ?
Aus dem offiziellen Diagramm von Ati zum R580 geht hervor, dass jeder Pixelshader 4 ALUs beherbergt - beim R420 (und 520 ?) waren es ja, so weit ich das verstanden habe, eine MADD fähige Shader-ALU + eine "mini ALU" für Texturadressierung etc. pro Shadereinheit.
Wie viele der ALUs beim R580 sind denn hier reine "Shader-ALUs" ?
Bei nVidia stehen ja bereits seit dem NV40 2 Shader-ALUs/PS zur Verfügung, im Fall des G70 mit doppelter MADD Leistung (so viel konnte ich mit meinem Halbwissen aus Artikeln von 3dcenter und aus der c't extrahieren :tongue: ) und zusätzlichen 2 "Hilfs-ALUs" wie beim R420 ... sehe ich das richtig ?
Wie sehen also die RV530/R580 aus ? Haben diese GPU wirklich 12 bzw. 48 vollwertige Shadereinheiten, oder wird hier nur die Zahl der ALUs/PS aufaddiert ?
Hätte nVidia dann nicht schon seit dem NV40 von "32 Pixelshadern" sprechen können ?
Es wäre sehr nett, wenn mir jemand darauf eine Antwort geben könnte - ich verspreche, dass ich danach auch keine blöden Fragen mehr stellen werde ;)
mfG
denton
Hätte nVidia dann nicht schon seit dem NV40 von "32 Pixelshadern" sprechen können ?Seit G70 hätten sie wohl von 48 "Pixelshadern" sprechen können.
Zu R580: Vergiss mal dieses ATI-Diagramm, das ist nicht sonderlich toll, wenn man was verstehen will.
Ein R580/RV530-Quad besteht im Prinzip aus 4 ROPs, 4 TMUs und 12 ALUs. Pro Pipeline sind drei ALUs vorhanden.
dr.denton
2006-02-16, 11:51:44
hab vielen Dank, Gast - das hilft mir schon mal sehr viel weiter :)
irgendwie kam mir dieses Marketingblabla von wegen "48PS" immer schon komisch vor :|
mfG
denton
tokugawa
2006-02-16, 11:54:27
Du hast eh recht wenn du sagst dass man nicht mehr von "klassischen" Pipelines sprechen kann.
Aber wenn man eine Pixel Pipeline definiert als eben genau jenen Weg den ein Fragment (Pixel in der Verarbeitung) durch die GPU "nimmt", dann kann man nur von so vielen "vollwertigen" Pipelines sprechen wie es dem Minimum der Einheitenzahlen der Abschnitte entspricht (etwa bei 4 ROPs, 12 Shader Units, 4 Texture Units ist das Minimum der Einheitenzahl "4").
Eine Pixel Pipeline ist halt (metaphorisch gesprochen) eine Art "Schlauch" wo die Pixel durchgejagt werden, und da die Pixel (bzw. deren Verarbeitung) eine bestimmte Struktur haben, macht es Sinn an bestimmten Stellen den Schlauch "breiter" zu machen, um diese Stellen nicht zu Flaschenhälsen verkommen zu lassen.
Hallo dr.denton,
einleitend würde ich darum bitten, vor Satzzeichen kein Leerzeichen zu setzen.
Der Begriff "ALU" ist sehr schwammig. Man kann sich darauf verständigen, nur MAD4-fähige ALUs zu zählen, also Rechenwerke die pro Takt für vier Komponenten (RGBA oder XYZW) eine Multiplikation und Addition in einem Takt ausführen können. Der R520 hat 4 Quad-TMUs und nach der eben getroffenen Definition auch 4 Quad-ALUs. Der R580 hat weiterhin 4 Quad-TMUs, aber 12 Quad-ALUs.
12 Quad-ALUs können 12 Quads berechnen, ein Quad ist ein Block aus 2x2 Pixeln. Das wären dann 12x4 = 48 "Shader-Einheiten". Pro Shader-Einheit werden nun Vektoren mit bis zu 4 Komponenten verarbeitet, und MAD besteht aus zwei Operationen (MUL und ADD) – das sind also insgesamt 384 Gleitkomma-Operationen pro Takt. Nicht übel, was? Solche Leistung ist aber auch nötig, um lange Shader in Echtzeitgeschwindigkeit verarbeiten zu können. Man kann in Zukunft weiterhin damit rechnen, dass die arithmetische Leistung schneller steigen wird, als die Textursampling-Leistung.
Der G70 hat 6 Quad-Pipelines, in denen TMUs und ALUs "auf einer Strecke" liegen, also nicht entkoppelt sind. Eine G70-ALU kann aber sogar 2x MAD4 pro Takt ausführen. Aufgrund bestimmter Beschränkungen wird man diese Leistung tatsächlich aber nur bei Verwendung von halber Genauigkeit (also FP16) erzielen können.
Sowohl die Radeon-ALU als auch die G70-ALU kann im gleichen Takt neben MAD noch einige andere Operationen "kostenlos" mit ausführen. Das würde aber ziemlich ins Detail gehen.
Spasstiger
2006-02-16, 14:59:38
Und beim NV40 ist es afaik so, dass keine der beiden ALUs für sich MAD4-fähig ist, sondern nur in Kombination, so dass man eben nur von einer Shadereinheit pro Pipe sprechen kann.
Beim G70 ist es schon etwas kniffliger, wie Aths bereits ausgeführt hat.
Und beim NV40 ist es afaik so, dass keine der beiden ALUs für sich MAD4-fähig ist, sondern nur in Kombination, so dass man eben nur von einer Shadereinheit pro Pipe sprechen kann.Der NV40 hat eine MUL- und eine MAD-ALU, wobei beide ALUs noch weitere spezielle Funktionen bieten. Zwischen beiden ALUs liegt die TMU. Beim G70 wurde die MUL-ALU mit ADD auf MAD erweitert.
Der G70 hat 6 Quad-Pipelines, in denen TMUs und ALUs "auf einer Strecke" liegen, also nicht entkoppelt sind. Eine G70-ALU kann aber sogar 2x MAD4 pro Takt ausführen. Aufgrund bestimmter Beschränkungen wird man diese Leistung tatsächlich aber nur bei Verwendung von halber Genauigkeit (also FP16) erzielen können.
Heißt das, dass man bei einem G70 unter FP16 die doppelte Leistung erzielen könnte, sofern die Texelleistung nicht limitiert? Interessant. Da bei mir in diesen Gefilden ziemliches Dunkel herrscht: Ließe sich nicht (teilweise) FP16 per Treiber forcieren, "wo es nicht auffällt"? Als kleiner Boost zwischendurch, eine "Optimierung" eben ... ;)
MfG,
Raff
Heißt das, dass man bei einem G70 unter FP16 die doppelte Leistung erzielen könnte, sofern die Texelleistung nicht limitiert? Interessant.Wieso "könnte"? Das ist oft genug sogar der Fall. Auch ohne FP16 wenn man nicht ins Registerfile-Limit stößt.
Da bei mir in diesen Gefilden ziemliches Dunkel herrscht: Ließe sich nicht (teilweise) FP16 per Treiber forcieren, "wo es nicht auffällt"? Als kleiner Boost zwischendurch, eine "Optimierung" eben ... Man sieht es bei nicht angepassten Shadern leider recht schnell wenn man alles auf FP16 setzt. Aber was glaubst du was nVIDIA bei seinenen Shaderreplacements macht ;)
Heißt das, dass man bei einem G70 unter FP16 die doppelte Leistung erzielen könnte, sofern die Texelleistung nicht limitiert? Interessant. Da bei mir in diesen Gefilden ziemliches Dunkel herrscht: Ließe sich nicht (teilweise) FP16 per Treiber forcieren, "wo es nicht auffällt"? Als kleiner Boost zwischendurch, eine "Optimierung" eben ... ;)Schwierige Problematik. Abgesehen von handoptimierten Shadern, wo der komplette Shader ersetzt wird, ist mir nicht bekannt dass NV in PP rechnen lässt, wenn das Flag im Shader nicht gesetzt wurde. Eine Treiber-Option, alle Farbberechnungen auf _PP zu zwingen wäre nicht schlecht, ist aber nicht vorhanden. Es könnte dann ja auch zu Darstellungsfehlern kommen.
Die CineFX-Architektur war schon immer darauf ausgelegt, dass der Entwickler immer dann, wenn ohne Qualitätsverlust möglich, Shader-Teile in PP rechnen lässt. Offenbar hat Nvidias Lobbyarbeit, äh, Developer-Support aber nur bedingt geholfen.
robbitop
2006-02-16, 19:45:31
Das ist doch aber nur bedingt durch das etwas kleine Temp register, oder?
mapel110
2006-02-16, 19:46:08
_PP lässt sich aber mit dem 3DAnalyzer forcen und wenn ich einige Benchmarkergebnisse vom 3DMark05 aus dem Benchmarkforum richtig in Errinnerung habe, bringt es dort zumindest nicht sonderlich viel, aber das muss ja nichts heißen.
(gibts dort unter files, für die, die ihn nicht kennen)
http://www.tommti-systems.de/start.html
Das ist doch aber nur bedingt durch das etwas kleine Temp register, oder?Nicht nur, aber hauptsächlich.
robbitop
2006-02-16, 20:47:04
Aths, wenn es dir nichts ausmacht, führe das bitte ein wenig genauer aus.
Na es gibt auch Rechenwerke, die nur _PP-Präzision können (NV40, G70: NRM_PP) oder bei PP nur einen Takt statt zwei brauchen (wahrscheinlich RSQ, beim NV30 und NV35 auf jeden Fall.) Beim NV35 kann man in der FPU z. B. in FP32 ein ADD oder MUL, in FP16 ein MAD ausführen – offenbar ein Problem der internen Bandbreite, da ADD und MUL ja jeweils als FP32-ALU vorliegen müssen. Beim NV40 und G70 wäre es möglich, dass es bei bestimmten Strecken einen ähnlichen Flaschenhals geben könnte, der verhindert dass es bei FP32 volle Leistung gibt.
Da FP16 für die meisten Farboperationen eigentlich gut genug ist, sehe ich darin keinen Designfehler – aber NV hätte hier auch Tools anbieten sollen, die Vorschläge machen wo man im Shader _PP setzen kann.
Das ist mit Tools nicht entscheidbar aths, weil man die Inputs bei einem Pixelshader nicht kennt.
Banshee18
2006-02-17, 00:11:44
Hm, verbietet DX nicht das setzen von _PP-Flags durch den Treiber?
Nicht wenn es der Entwickler explizit anfordert. Von selber macht es der Treiber natürlich nicht, außer es ist Shaderreplacement im Spiel.
Banshee18
2006-02-17, 00:32:20
Nicht wenn es der Entwickler explizit anfordert. Von selber macht es der Treiber natürlich nicht, außer es ist Shaderreplacement im Spiel.
Versteh´ich nicht. Heißt das, dass pp nicht geht, wenn der Treiber nicht die Anweisung dazu hat, der Entwickler es aber fordert?
Muss der Entwickler sagen: "Der und der Shader darf mit pp berechnet werden?" Denn sonst wäre Shaderreplacement ja verboten. Für mich war Shaderreplacement immer eine Treibersache, womit _pp_Flags ausgeschlossen wären.
Wäre schön, wenn das noch jemand näher erläutern könnte. =)
Man kann pro Befehl angeben ob mit PP gerechnet werden darf oder nicht.
Ob Shaderreplacement verboten ist oder nicht ist in diesem Kontext wirklich schwer zu diskutieren. Ich denke das sollten wir mal beiseite lassen.
Banshee18
2006-02-17, 01:17:20
Man kann pro Befehl angeben ob mit PP gerechnet werden darf oder nicht.
Das ist mir klar.
Mir geht es nicht darum, ob Shaderreplacement verboten ist, oder nicht, sondern um partial precision.
Es mangelt, glaube ich, an meiner Definition von Shaderreplacement.
Ist Shaderreplacement nicht das Ersetzen eines Shaders durch einen anderen Shader durch den Treiber (der mathematisch das gleiche Ergebnis liefert), der jedoch vom Entwickler in dieser Form nicht vorliegt? Das setzen von _PP-Flags fällt dann imo nicht unter die Definition von Shaderreplacement.
Oder kann man es auch Shaderreplacement nennen, wenn Befehle laut Entwickler mit pp berechnet werden dürfen und der Treiber dann genau dies veranlässt? Wenn der Entwickler das nicht angibt, der Treiber es aber trotzdem macht, wäre es ja verboten.
Wenn letzteres zutrifft, sind alle meine Fragen beseitigt, wenn nicht sehe ich mich genötigt, einen Thread darüber zu eröffnen.
Ich möchte nicht unhöflich wirken, aber "diskutiert" bitte mit einem t.
MfG,
Banshee
Ich versteh grad dein Problem nicht. Der Treiber benützt PP wenn es der Entwickler für diesen Befehl vorgesehen hat - sonst nicht. Außer es gibt ein spezielles Shaderreplacement für dieses Spiel um Benchmarks zu gewinnen, da sind dann alle Tricks recht.
Ich möchte nicht unhöflich wirken, aber "diskutiert" bitte mit einem t.Im Gegenteil. Ich bitte meine Legasthenie zu entschuldigen X-D
OBrian
2006-02-17, 01:37:03
DirectX9 hat ja nur die Mindestforderung an die Hardware für z.B. FP32, aber FP16 ist ja deswegen nicht verboten, bestenfalls unerwünscht. Will der Entwickler es aber trotzdem nutzen, um nVidia zu helfen (da er von nVidia bezahlt wurde^^), dann schreibt er es dabei und die nVidia-Karte macht das genauso, das ist dann kein Shaderreplacement (es wird ja eben nichts ersetzt).
Aber schreibt der Entwickler nichts dazu (da er von Ati bezahlt wurde^^), dann hilft sich nVidia selbst und ersetzt den originalen Code durch selbstgeschriebenen, das ist dann Shaderreplacement.
(da er von nVidia bezahlt wurde^^)Klar, es gibt natürlich nicht auch noch den Grund dass es auf möglichst breiter Basis möglichst gut läuft. Oh Schmerz.
dann hilft sich nVidia selbst und ersetzt den originalen Code durch selbstgeschriebenen, das ist dann Shaderreplacement.Da werden wenn dann schon noch ganz andere Dinge geändert als nur ein PP-Flag. ATI macht das genauso.
Btw. ist seit NV4x auch FP32 sehr schnell unterwegs.
FP 32 ist ja fortschrittlicher, FP 16 kann unter umständen eine schlechtere Bildqualität bewirken (richitg) ?
warum schreibt dann xbitlabs :
The 3DMark06 engine is its modification with an addition of such features as full support of Shader Model 3.0 and textures and blending in FP16 format. The latter means nothing else but High Dynamic Range – HDR.
als wäre FP 16 der für HDR erforderliche Standart ??
Das eine hat mit dem anderen nichts zu tun. Hier wird von der Shaderpräzision geredet (FP16/FP32). Das hat mit HDR-Rendering nichts zu tun.
ok, also FP16 oder FP32 kann zum einen die Shaderpräzision beschreiben.
laut obig genanntem Zitat hat FP16/32 aber auch was mit HDR zu tun. Was ?
Da beschreibt es quasi die Farbtiefe. FP16 bedeutet 16 bit pro Farbkanal im Floating-Point-Format, also insgesamt 64 bit (16-16-16-16 für RGBA). "Normales" 32bit Rendering ist 8-8-8-8 RGBA im Fixpoint-Format. Was das ganze bringt? Mehr Dynamik.
Dieser Artikel von aths beschreibt es ganz gut: http://www.3dcenter.org/artikel/2006/01-01_a.php
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.