Überlegungen zu "unified shader"-Architekturen

[Demirug]

Ach Zecki, es sind schon Daten im Umlauf die man so auch später in den offizielen Presseunterlagen zum Launch wieder finden wird. Das Problem dabei ist nur welcher Quelle man vertrauen darf. In wie weit die Presseunterlagen sich die Wahrheit zurecht biegen ist natürlich ein anderes Thema.

Ich habe auch ein paar Gedanken zum Thema gepflegt, und glaube zB dass es möglich ist, dass ein TBDR mit Shader 3.0-Hardware sich wesentlich leichter tut, diese Einheiten zwischen VS und PS frei verschiebbar zu machen. Wenn ImgTech das auch erkannt hat, und voll ausnutzt, dann besteht die Chance dass Series 5 jegliche IMR-Konkurrenz geradezu abfrühstückt.

Du hast also deine Meinung im Bezug auf das Thema geändert?

Bei einem TBDR geht mir das allerdings nicht weit genug. Den letzten Endes werden auch die IMRs dazu übergehen die Shadereinheiten je nach Bedarf zu nutzen.

[zeckensack]

Original geschrieben von Demirug
Ach Zecki, es sind schon Daten im Umlauf die man so auch später in den offizielen Presseunterlagen zum Launch wieder finden wird. Das Problem dabei ist nur welcher Quelle man vertrauen darf. In wie weit die Presseunterlagen sich die Wahrheit zurecht biegen ist natürlich ein anderes Thema.Darauf kann ich auch warten :)
Die meisten Teilnehmer in diesem Thread wissen IMO genauso viel wie ich, und ich weiss garnichts.


Du hast also deine Meinung im Bezug auf das Thema geändert?Habe ich das?
Ich kam auf die Idee irgendwann im Dezember. Ist Teil einer Arbeit, die ich damals angefangen, und dummerweise noch nicht zu Ende gebracht habe.
Bei einem TBDR geht mir das allerdings nicht weit genug. Den letzten Endes werden auch die IMRs dazu übergehen die Shadereinheiten je nach Bedarf zu nutzen. Ja, das wäre wünschenswert, und ich erinnere mich natürlich auch daran, dass wir über das Thema schon ein paar Mal gesprochen haben.
Bei TBDRs müsste es IMO leichter zu realisieren sein.

TBDR:
Vertex Buffer (externer Speicher) => ALU (VS) => Tilebin (externer Speicher) => Vis/Raster => ALU (PS)
IMR:
Vertex Buffer (externer Speicher) => ALU (VS) => FIFO (on chip) => Raster/Early Z => ALU (PS)

Der IMR braucht ein Minimum an Parallelität zwischen VS und PS. Der TBDR ist darauf nicht angewiesen, da er insgesamt asynchroner funktionieren kann (er kann quasi unendlich viel Zwischendaten auslagern, während der FIFO des IMR in der Kapazität begrenzt ist).

Beim IMR stellen sich auch Fragen bzgl des Layouts des Chips. Wo liegt der FIFO, wo liegen die ALUs, und wie bekomme ich die Daten am schnellsten von A nach B?
Wie teile ich den Programmcode zwischen den ALUs auf?

Beim TBDR ist die Lösung dieses Problems bereits inhärent mit dem Konzept verknüpft, denn der Vis/Raster-Block muss den externen Speicher lesen können. Ausserdem ist es hier weiterhin möglich, alle ALUs parallel mit dem identischen Programm zu befeuern.

Vereinfachtes Blockdiagramm für den TBDR

Texturen
||
|/Vertex fetch \| \/ |/prim assembly, bin\|
Speicher=>|* *|ALUs|* *|<=>Speicher
|\-Vis/Raster--/| /\ |\------ROP---------/|
||
Shader-Code
Hier sind zwei Schalter eingebaut. Schalter "oben" dient dem Vertex processing und triangle binning. Schalter "unten" erzeugt dann die Pixel. Beide Modi arbeiten parallel mit allen verfügbaren ALUs.

[Demirug]

Original geschrieben von zeckensack
Darauf kann ich auch warten :)
Die meisten Teilnehmer in diesem Thread wissen IMO genauso viel wie ich, und ich weiss garnichts.

Wie gesagt Wissen ist vorhanden nur eben zuviel davon.


Habe ich das?
Ich kam auf die Idee irgendwann im Dezember. Ist Teil einer Arbeit, die ich damals angefangen, und dummerweise noch nicht zu Ende gebracht habe.

Schau mal dort: http://ds80-237-203-42.dedicated.hosteurope.de/vbulletin/showthread.php?s=&threadid=72688 Es ging da aber ganz allgemein um die Idee für Pixel und Vertexberechungen die gleichen Einheiten zu nutzten.

Ja, das wäre wünschenswert, und ich erinnere mich natürlich auch daran, dass wir über das Thema schon ein paar Mal gesprochen haben.

<snip>

Ich meinte eigentlich was anderes. Was das verteilen von Rechenleistung beim IMR angeht so würde ich die Shader einfach als Array anordnene und die Eingangsdaten aufgrund von füllständen der Zwischenbuffer wählen. Ist zum Beispiel der Post-Vertexbuffer voll kann man alle Shader auf die Pixelverarbeitung schalten.

Was ich mit nicht weit genug gehen aber wirklich meinte ist das: http://ds80-237-203-42.dedicated.hosteurope.de/vbulletin/showthread.php?s=&threadid=75598

Oder um es mal mit DX7 Technik auszudrücken. Das T&L in zwei Teile zerlegen und nur das T vor dem Binning ausführen. Den L teil dann so Lange verzögern bis feststeht das ein Dreieck das diesen Vertex nutzt auch wirklich sichtbar ist.

[zeckensack]

Original geschrieben von Demirug
Schau mal dort: http://ds80-237-203-42.dedicated.hosteurope.de/vbulletin/showthread.php?s=&threadid=72688 Es ging da aber ganz allgemein um die Idee für Pixel und Vertexberechungen die gleichen Einheiten zu nutzten.Ja, dort findest du auch meine Bedenken in Bezug auf IMRs, die ich auch heute noch habe.
Bei TBDRs stelle ich mir das ganze eben wesentlich leichter vor, wie oben geschildert :)

Ich meinte eigentlich was anderes. Was das verteilen von Rechenleistung beim IMR angeht so würde ich die Shader einfach als Array anordnene und die Eingangsdaten aufgrund von füllständen der Zwischenbuffer wählen. Ist zum Beispiel der Post-Vertexbuffer voll kann man alle Shader auf die Pixelverarbeitung schalten.

Was ich mit nicht weit genug gehen aber wirklich meinte ist das: http://ds80-237-203-42.dedicated.hosteurope.de/vbulletin/showthread.php?s=&threadid=75598

Oder um es mal mit DX7 Technik auszudrücken. Das T&L in zwei Teile zerlegen und nur das T vor dem Binning ausführen. Den L teil dann so Lange verzögern bis feststeht das ein Dreieck das diesen Vertex nutzt auch wirklich sichtbar ist. Das könnte man natürlich auch machen. Dadurch wird das ganze leider wieder komplexer (wie du auch selbst geschrieben hast). Ich bin mir nicht sicher, ob sich das im ganzen betrachtet lohnen würde.
Wofür verbrauchen "typische" Vertex Shader Rechenleistung? Ich tippe hier eher auf Animation (und mit VS3.0 displacement), und nur untergeordnet Farb-Berechnung. Texturkoordinaten muss man für reine Animationszwecke auch nicht verändern, das braucht man nur zum "Anblasen" von diversen per pixel lighting-Geschichten. Auch hierfür muss natürlich zuerst eine Position errechnet werden.

Insgesamt sehe ich nur geringe Vorteile für "typische" Anwendungsfälle, und auf der anderen Seite die erhöhte Komplexität.

Noch eins: wenn die Lichtberechnung im VS erfolgt, ist das Ergebnis nur noch eine oder zwei Farbe(n), die uU kompakter gespeichert werden kann als die Attribute, aus denen sie errechnet wurde. Ein TBDR könnte hier nochmals (pro tatsächlich geschriebenem Vertex) externe Bandbreite sparen, im Austausch gegen potentiell überflüssige Berechnungen.

edit:
Diese ganze Geschichte lohnt sich auf TBDRs IMO nicht*.
Der Gewinn wäre eingesparte Rechenleistung im Vertex-Bereich. Wenn ich nun richtig liege, und die VS und PS "unified" sind, dann ist die im Vertex-Bereich verfügbare Leistung ohnehin sehr hoch (genauso hoch wie die Pixel-ALU-Leistung). Im Vergleich zu traditionellen Architekturen also "zu hoch" (im Sinne von "nicht ausbalanciert"). Dadurch werden solche Einsparungen noch weniger wichtig.

*universell sinnvoller Sonderfall: man macht T=>Cull=>L statt T&L=>Cull; das kann man uf TBDRs und auf IMRs machen, und es ist in beide Designs ohne grossartige Eingriffe integrierbar

[zeckensack]

Original geschrieben von zeckensack

Texturen
||
|/Vertex fetch \| \/ |/prim assembly, bin\|
Speicher=>|* *|ALUs|* *|<=>Speicher
|\-Vis/Raster--/| /\ |\------ROP---------/|
||
Shader-Code
Hier sind zwei Schalter eingebaut. Schalter "oben" dient dem Vertex processing und triangle binning. Schalter "unten" erzeugt dann die Pixel. Beide Modi arbeiten parallel mit allen verfügbaren ALUs. Als Kontrast mal der "traditionelle" TBDR, mit separatem VS.

VS-Code
\/
Speicher => Vertex fetch => ALUs => prim assembly, bin <=> Speicher ...

PS-Code
\/
... Speicher => Vis/Raster => ALUs => ROP => Speicher
/\
Texturen

Diese beiden Blöcke können parallel arbeiten und sind durch den externen Tile-Bin aneinander gekoppelt. Dieser wirkt wie ein extrem grosser FIFO, bzw post transform vertex cache.

Auch hier kann es passieren, dass einer der beiden ALU-Blöcke leerläuft, weil der andere mit seiner Arbeit nicht schnell genug fertig wird. Das ist die Motivation für verschiebbare ALUs.

"Meine" Idee sieht nun vor, dass jeweils entweder der VS oder der PS läuft. Ist eine dieser beiden Stufen viel schneller als die andere, entsteht kein weiterer Verlust. Die Bandbreitenkosten für den externen Tile-Bin muss ein TBDR ohnehin tragen.

__________________________
Nehmen wir mal dir R300-ALU-Ausstattung als Basis: 4xVS + 8xPS macht 12 ALUs.

"Böser" Beispielfall:
Die vier VS-ALUs brauchen 60 Takte, um ein Dreieck mit 8 Pixeln Inhalt zu erzeugen. Die acht PS-ALUs brauchen zwei Takte, um diese Pixel zu füllen.

Traditionell:
Der Durchsatz ist auf 8 Pixel pro 60 Takte begrenzt. Die Effizienz im PS-Bereich liegt bei 1,6%

"Meins":
Ich fasse die zwölf ALUs zu einem Block zusammen. Der VS braucht nun nur noch 20 Takte pro Dreieck (er hat dreimal soviel ALU-Leistung zur Verfügung).
Der PS braucht wiederum zwei Takte pro Pixelblock (aufgerundet von 8*2/12=1,333...). Hier muss ich allerdings addieren, denn es ist ausgeschlossen, dass PS und VS parallel arbeiten können. Insgesamt bekomme ich meine acht Pixel in 22 Takten. Mit der gleichen Menge an ALU-Rechenleistung wie auf einem "traditionellen" TBDR, wohlgemerkt. Die Effizienz im PS-Bereich liegt bei 66%.

Reduziere ich die ALU-Anzahl auf insgesamt acht, erhalte ich immerhin noch 8 Pixel in effektiv 30+2=32 Takten. Das ist immer noch fast doppelt so schnell wie die traditionelle Architektur, jedoch bei geringerer Komplexität. Die Effizienz im PS-Bereich liegt bei sagenhaften 100%. Dies ist als Zufall zu werten.

Generell kann die Effizienz eines Rechenblocks (PS oder VS) nicht mehr unter 1/(Anzahl der ALUs) fallen. Falls darüber hinaus überschüssige Leistung vorhanden ist, kann sie vollständig für die andere "Rechenart" genutzt werden. Die entstehenden Verluste erklären sich ausschliesslich durch Granularitäts-Verschnitt (wie eben zB bei 12 ALUs für 8 Pixel).

Guten Tag :)

Noch'n edit:
Dazu kommen in jedem Fall noch Latenzverluste durch das Umschalten in den jeweils anderen Modus. Insbesondere der Vis/Raster-Block braucht sicher einige Takte, um gefüllt zu werden. Ich gehe hier ganz nonchalant davon aus, dass diese Latenz dank sehr langer "batches" versteckt werden kann. Wenn das nicht reicht, kann man diesen Block auch mit der Arbeit beginnen lassen, kurz bevor der Betriebsmodus gewechselt wird (halte ich allerdings für unnötig kompliziert).

[Demirug]

Ich habe mir mal aus Spellforce einen VS genommen:


dcl_position0 v0
dcl_normal0 v1
dcl_color0 v2
dcl_texcoord0 v3
dcl_texcoord1 v4
m4x4 oPos , v0 , c3
add r3 , c2 , -v0
dp3 r6.w , r3 , r3
rsq r6.w , r6.wwww
mul r3 , r3 , r6.wwww
mov r2.w , c13
dp3 r6.w , v1 , c16
max r6.x , r6.wwww , c0
min r6.y , r6.wwww , c0
mov r0 , c12
mad r0.xyz , c14 , r6.xxxx , r0
mad r0.xyz , c15 , -r6.yyyy , r0
add r4.xyz , c20 , -v0
dp3 r6.w , r4 , r4
rsq r4.w , r6.wwww
mul r4.xyz , r4 , r4.wwww
add r5.xyz , r4 , r3
dp3 r5.w , r5 , r5
rsq r5.w , r5.wwww
mul r5.xyz , r5 , r5.wwww
ndst r6 , r6.wwww , r4.wwww
dp3 r6.w , r6 , c19
max r6.w , r6.wwww , c0
min r6.w , r6.wwww , c1
dp3 r2.x , r4 , v1
dp3 r2.y , r5 , v1
lit r2 , r2
mul r2.yz , r2 , r6.wwww
mad r0.xyz , c17 , r2.yyyy , r0
mad oD0 , r0 , v2 , c11
mul oD1 , c18 , r2.zzzz
mov oT0.xy , v3


Für das Cullen, Tilen, usw bräuchte man nur die erste Zeile auszuführen. Der ganze Rest wird erst gebraucht wenn Pixel des Dreiecks auch wirklich sichtbar sind. Ich sehe da also durchaus bei einem TBDR ein grosses Einsparpotenzial. Das ganze macht natürlich nur Sinn wenn man die Shadereinheiten variable einsetzten kann.

Bei deinem Ansatz (komplettes Umschalten) sehe ich zwei kleinere Probleme:

1. Die HSR Engine muss für stärkere Stossbelastungen ausgelegt werden da ja das ganze immer im Schwall kommt.

2. Wenn die Shadereinheiten alle im Vertexmodus sind verliert man bei jedem Tackt Füllrate (wenn man nicht gerade ein Vertexprogramm mit texturzugriff hat).

[zeckensack]

Original geschrieben von Demirug
Ich habe mir mal aus Spellforce einen VS genommen:
<...>Oh weh, wer hat denn diesen "Code" geschrieben? :o
Okay, nettes Beispiel, wenn auch ein wenig pathologisch *eg*

Das kann man bestimmt noch optimieren ...

Edit: Hast du dazu auch die Konstanten?

Für das Cullen, Tilen, usw bräuchte man nur die erste Zeile auszuführen. Der ganze Rest wird erst gebraucht wenn Pixel des Dreiecks auch wirklich sichtbar sind. Ich sehe da also durchaus bei einem TBDR ein grosses Einsparpotenzial. Das ganze macht natürlich nur Sinn wenn man die Shadereinheiten variable einsetzten kann.Gegenvorschlag: drei Phasen statt zwei. Ha!
Bei deinem Ansatz (komplettes Umschalten) sehe ich zwei kleinere Probleme:

1. Die HSR Engine muss für stärkere Stossbelastungen ausgelegt werden da ja das ganze immer im Schwall kommt.

2. Wenn die Shadereinheiten alle im Vertexmodus sind verliert man bei jedem Tackt Füllrate (wenn man nicht gerade ein Vertexprogramm mit texturzugriff hat). 1. Die HSR-Einheit sollte in jedem Fall dafür ausgelegt sein, gerade so schnell Pixel rastern zu können, dass man die theoretische Füllrate der Pixel-Einheiten auch ausnutzen kann.
Das hat mit "meinem" Konzept nur bedingt zu tun, nämlich dann wenn sich die Pixel-Leistung erhöht. Wer 12 ALUs füttern will, kann mehr HSR-Leistung gebrauchen als für 8 ALUs, klar.

2. Man verliert natürlich die Parallelität. Wenn in VS und PS exakt gleich viel Arbeit zu verrichten ist, hat man natürlich nichts gewonnen, und ja, die Textursampler sind dann "verschwendet".
Ziel der Übung ist es, die Einheiten gleichmässig auszulasten. Besonders interessant ist es ja auch deshalb, weil VS3.0 Texturzugriffe erlaubt. Wenn man dafür optimieren möchte, dann sind die Sampler in der VS-Phase auch nicht mehr nutzlos.
Auch für eine PS2.0-Optimierung, wo ja bekanntermassen die Arithmetik wichtiger ist als die pure Textur-Leistung, ist dieser Weg IMO so schlecht nicht. Der Verlust an Texel-Leistung ist zwar noch da, wird aber (hoffentlich) durch die Arithmetik-Ops verdeckt.

Richtige Verluste wären nur bei kurzen Shadern zu verzeichnen, <=PS1.4 meinetwegen. Damit das nicht negativ auffällt, muss nur die Rohleistung ausreichend hoch sein.

Je länger die Shader werden, und je mehr AA im Spiel ist, desto weniger wichtig wird die Textur-Sampler-Leistung. Nach wie vor kritisch bleibt das AF. Single-Cycle-Tri als Basiseinheit wäre hier wohl angebracht, um die Verluste zu minimieren.

[micki]

das mit dem füllrate-verlust wird kompensiert, weil man doch die vertexdaten ließt und schreibt, zudem kommt ab vs 3.0 dass man dort auch massig texturen lesen wird, weil man die geometrie sehr detailiert speichern kann und nicht die grossen vertexzahlen haben muss (werden dann ja hoffentlich zur laufzeit generiert).
aber ich denke, dass dann die dynamisch generierten daten auch zu einer bombe werden könnten, wenn man aus nem quad ein paar hundert tausend tris generiert um sein terrain anzuzeigen, und die daten erst transformiert und abgelegt werden, damit sie später dann gezeichnet werden können, würde das zecki-konzept ein speichermanagement disaster hervorrufen, oder?

MfG
micki

ps.
da der thread so mitten drinn anfängt, weiß ich nicht ob ich das alles richtig verstand
zeckis vorschlag:
-erst alle rechen-resourcen fürs transform&culling
-dann fürs pixelshading
dafür die gpu immer umswitchen und die transformierten vertexdaten im graka-ram zwischencachen?

[zeckensack]

Original geschrieben von micki
das mit dem füllrate-verlust wird kompensiert, weil man doch die vertexdaten ließt und schreibt, zudem kommt ab vs 3.0 dass man dort auch massig texturen lesen wird, weil man die geometrie sehr detailiert speichern kann und nicht die grossen vertexzahlen haben muss (werden dann ja hoffentlich zur laufzeit generiert).
aber ich denke, dass dann die dynamisch generierten daten auch zu einer bombe werden könnten, wenn man aus nem quad ein paar hundert tausend tris generiert um sein terrain anzuzeigen, und die daten erst transformiert und abgelegt werden, damit sie später dann gezeichnet werden können, würde das zecki-konzept ein speichermanagement disaster hervorrufen, oder?

MfG
micki

ps.
da der thread so mitten drinn anfängt, weiß ich nicht ob ich das alles richtig verstand
zeckis vorschlag:
-erst alle rechen-resourcen fürs transform&culling
-dann fürs pixelshading
dafür die gpu immer umswitchen und die transformierten vertexdaten im graka-ram zwischencachen? Dieser Thread hier ist ein Split aus einem Thread im Speku-Forum. Meine Idee bezog sich auf Shader 3.0-fähige TBDRs ala PowerVR.

Hier wird sowieso externer Speicher für's Geometrie-Binning genutzt, deswegen sind diese Kosten nicht mehr vermeidbar. Ganz unabhängig davon, ob der externe Speicher für's Binning ein Problem ist, oder nicht (diverse PowerVR-Mitarbeiter dementieren das), es wird sowieso gemacht. Mein Vorschlag verschlimmert das IMO nicht.

[bendel]

Original geschrieben von Demirug
Ich habe mir mal aus Spellforce einen VS genommen:
[...]


Eine Optimierung bei diesem Shader bringt gar nichts, denn er wird sowieso nie ausgeführt in Spellforce. (und ja, Teile der skalaren Lichtberechnung könnten sinnvoller Weise zusammengefaßt und optimiert werden)

[micki]

na dann...


gibt es beim TBDR überhaupt ne andere möglichkeit als vorher alles durchzutransformieren und dann im rasterizer zu zeichnen? die scene muss doch schon komplett im fertig sein bevor die tiles abgearbeitet werden können. in der zeit würde die vertex transformation still stehen... bin gespannt auf der powerVR paper dazu.

MfG
micki

[Ailuros]

Danke fuer den split...nur muss ich wohl jetzt jeden Post duzente Male durchlesen, um wenigstens zu verstehen dass Zuege auf Gleisen laufen :D

Dumme Frage: hat jemand schon das Meta.pdf durchgelesen? (ja ich weiss dass es irrelevant klingt):

http://www.metagence.com/Products/Meta/index.asp

zecki,

Ich weiss dass es sich im alten Interview nur um eine generelle Frage bzw. Antwort handelte aber:

The more complex shaders get, the more essential it becomes to avoid doing useless work. This advantage is further amplified when using full floating point render targets, writing out a 128 bit value (or larger, when using DX9's Multiple Render Targets) to memory only to overwrite it at a later stage with another value is a huge bandwidth waste. Another advantage TBDR has is that vertex and pixel processing is completely decoupled, the vertex and pixel shaders work on completely different scenes meaning that there is a significant reduction of the chance that the vertex shader will stall the pixel shader (complex vertex shader with simple pixel shader) or the other way around (simple vertex shader with very complex pixel shader). Reducing the idle time of pipeline components is yet another way to be more efficient.

http://www.pvrgenerations.co.uk/cgi-bin/viewarticle.cgi?page=/articles/2002/kristof1102&printer=0&pagenum=3

Und ja es ist keine Aussage die direkt auf moegliche Implementationen deuten koennte, aber irgendwie bleibt mir ein Fragezeichen bei Deiner Idee ueber "unified units".

[Ailuros]

Original geschrieben von micki
na dann...


gibt es beim TBDR überhaupt ne andere möglichkeit als vorher alles durchzutransformieren und dann im rasterizer zu zeichnen? die scene muss doch schon komplett im fertig sein bevor die tiles abgearbeitet werden können. in der zeit würde die vertex transformation still stehen... bin gespannt auf der powerVR paper dazu.

MfG
micki

AFAIK ist es der Idealfall fuer einen TBDR, aber keine Vorraussetzung. Da ich gerade beim alten Interview war:

The ideal operating environment for a tile based renderer is where all the scene data is available for the HSR in one go - this maximizes the benefits of deferred texturing. However PowerVR does not require that this is the case and incorporates sophisticated parameter management and compression hardware which allows the parameter data buffer size to be fixed and automatically manages intermediate renders if required while retaining full compatibility. Our research teams are constantly working on improved versions of the already impressive technology advantage we have in this domain.

http://www.pvrgenerations.co.uk/cgi-bin/viewarticle.cgi?page=/articles/2002/kristof1102&printer=0&pagenum=2

[zeckensack]

Original geschrieben von Ailuros
Danke fuer den split...nur muss ich wohl jetzt jeden Post duzente Male durchlesen, um wenigstens zu verstehen dass Zuege auf Gleisen laufen :D

Dumme Frage: hat jemand schon das Meta.pdf durchgelesen? (ja ich weiss dass es irrelevant klingt):

http://www.metagence.com/Products/Meta/index.aspDu meinst AMA/Multithreading, oder?
Ich bin mir nicht sicher, ob das auf schnelle Grafikchips übertragbar ist. Metagence produziert pro Takt höchstens ein 32Bit-Ergebnis und läuft wie schnell, 20MHz? (ich habe wirklich keine Ahnung)
Pixel Shader ALUs ala R300 produzieren pro Takt bis zu 768 Bit Daten, und der Takt ist auch viel höher. Man muss die Daten erstmal aus den ALUs herausbekommen, bevor man den "Thread" wechseln kann.
zecki,

Ich weiss dass es sich im alten Interview nur um eine generelle Frage bzw. Antwort handelte aber:



http://www.pvrgenerations.co.uk/cgi-bin/viewarticle.cgi?page=/articles/2002/kristof1102&printer=0&pagenum=3

Und ja es ist keine Aussage die direkt auf moegliche Implementationen deuten koennte, aber irgendwie bleibt mir ein Fragezeichen bei Deiner Idee ueber "unified units". Ich weiss nicht was sie vorhaben. Ich wollte nur aufzeigen, dass es bei einem TBDR relativ einfach sein könnte. Und IMO ist es auch nützlich.

Kristof spricht davon, dass sich ungleichmässige Lasten über eine Szene verteilt wieder ausgleichen können, und das ist sicherlich auch richtig (ein IMR bräuchte dafür einen riesigen FIFO). Aber was ist mit Szenen, bei denen die Lastverteilung immer ungleich ist, ala 3DM03 GT2? Da hast du die ganze Zeit über enorme VS-Last und wenig PS-Last. Hier Leistung "on demand" umschichten zu können, bringt sicher einen Vorteil.

[Ailuros]

Du meinst AMA/Multithreading, oder?
Ich bin mir nicht sicher, ob das auf schnelle Grafikchips übertragbar ist. Metagence produziert pro Takt höchstens ein 32Bit-Ergebnis und läuft wie schnell, 20MHz? (ich habe wirklich keine Ahnung)
Pixel Shader ALUs ala R300 produzieren pro Takt bis zu 768 Bit Daten, und der Takt ist auch viel höher. Man muss die Daten erstmal aus den ALUs herausbekommen, bevor man den "Thread" wechseln kann.

Metagence und der META Prozessor sind sozusagen eine Art "Abschlag"/Weiterentwicklung von aelterem PowerVR IP. Natuerlich wird META (wie man auf der Seite sehen kann) in ganz anderen Maerkten nutzvoll eingesetzt und deshalb auch die Gruendung einer neuen Subdivision.

META laeuft auf 180nm bis zu 150MHz (lese doch mal das pdf durch, steht drin ;) ).

Ich hab ernsthafte Zweifel dass META IP (genauso wie Ensigma/UCC IP) auf die eine oder andere Weise nicht benutzt wurde.

Ich weiss nicht was sie vorhaben. Ich wollte nur aufzeigen, dass es bei einem TBDR relativ einfach sein könnte. Und IMO ist es auch nützlich.

Kristof spricht davon, dass sich ungleichmässige Lasten über eine Szene verteilt wieder ausgleichen können, und das ist sicherlich auch richtig (ein IMR bräuchte dafür einen riesigen FIFO). Aber was ist mit Szenen, bei denen die Lastverteilung immer ungleich ist, ala 3DM03 GT2? Da hast du die ganze Zeit über enorme VS-Last und wenig PS-Last. Hier Leistung "on demand" umschichten zu können, bringt sicher einen Vorteil.

Nun dass hab ich auf ersten Schub verstanden :D

Interessant.

[Xmas]

zeckensack, mir ist ehrlich gesagt nicht ganz klar warum diese dynamische Anpassung bei einem IMR komplizierter sein soll.

[zeckensack]

Original geschrieben von Xmas
zeckensack, mir ist ehrlich gesagt nicht ganz klar warum diese dynamische Anpassung bei einem IMR komplizierter sein soll. Weil ein IMR ein IMR ist :)

Du kannst bei einem IMR nicht so leicht einen der beiden Blöcke (VS oder PS) komplett abschalten, weil die beiden über einen on-chip FIFO kommunizieren, und der ist irgendwann leer (gerade das will man ja vermeiden).
Du musst jederzeit VS und PS aktiv haben, damit kontinuierlich Arbeit verrichtet werden kann, bzw du musst sehr schnell die Betriebsmodi wechseln können.
Und wenn du das können willst, musst du dir noch über das physikalische Layout im Chip den Kopf zerbrechen. Traditionell kannst du die Einheiten entsprechend der Pipeline-Abfolge "einmal um den Speichercontroller herum" bauen. Beim Wechsel der Aufgaben verschiebt sich die Pipeline, alles wird viel komplizierter.

Bei jedweder teilweisen Aufgaben-Verschiebung von ALUs geht dann auch die SIMD-Struktur flöten. Du brauchst zumindest mal mehrere instruction pointer, und noch schlimmeres.

Nach "meiner" Idee kann der TBDR diese Probleme umgehen, indem explizit immer nur ein Programm läuft. Er kann sich wie gesagt den kurzzeitigen Totalausfall jeweils eines Funktionsblocks gut leisten, weil
a)der "Pixel-FIFO" vergleichsweise unendlich gross ist
b)der TBDR davon lebt, Dinge erst "später" zu Ende zu bringen

[Xmas]

Original geschrieben von zeckensack
Du kannst bei einem IMR nicht so leicht einen der beiden Blöcke (VS oder PS) komplett abschalten, weil die beiden über einen on-chip FIFO kommunizieren, und der ist irgendwann leer (gerade das will man ja vermeiden).
Wenn man bevorzugt Vertices verarbeitet, sollten die ALUs eigentlich immer gefüttert sein, sofern denn auch Arbeit ansteht. Die einzige Stall-Situation liegt doch dann vor, wenn der FIFO voll ist, sprich das Triangle Setup die transformierten Vertices gar nicht so schnell abgreifen kann wie der VS nachschiebt, gleichzeitig aber wegen Clipping und Z-Optimierungen keine Quads dabei herauskommen. Sprich: große, verdeckte Polygone.

Du musst jederzeit VS und PS aktiv haben, damit kontinuierlich Arbeit verrichtet werden kann, bzw du musst sehr schnell die Betriebsmodi wechseln können.
Sicher muss man sehr schnell wechseln können. Aber was spricht dagegen? PS und VS sind ja eben nicht mehr so grundsätzlich verschieden, dass der Wechsel so kompliziert wäre.

Und wenn du das können willst, musst du dir noch über das physikalische Layout im Chip den Kopf zerbrechen. Traditionell kannst du die Einheiten entsprechend der Pipeline-Abfolge "einmal um den Speichercontroller herum" bauen. Beim Wechsel der Aufgaben verschiebt sich die Pipeline, alles wird viel komplizierter.
Mit dem physikalischen Layout kenne ich mich ehrlich gesagt nicht genügend aus. Aber liegt der Speichercontroller nicht traditionell außen?

Bei jedweder teilweisen Aufgaben-Verschiebung von ALUs geht dann auch die SIMD-Struktur flöten. Du brauchst zumindest mal mehrere instruction pointer, und noch schlimmeres.
Den IP musst du wegen dynamischem Branching sowieso pro Verarbeitungseinheit (Quad bzw. Pixel, Vertex bzw. Vertexgruppe) mitführen. Wieso geht die SIMD-Struktur flöten?

Vielleicht haben wir auch nur ganz andere Vorstellungen, wie man das bei einem IMR realisieren könnte. Ich male mal ein Bild...

[HOT@Work]

Der NV40 ist aber noch ein klassischer Chip (also nicht unified), oder?

Serie5:
Das ist nur frei erfunden von mir :)

- 8 Unified Pipes mit je 2 TMUs,
- einem schnellen Speicherinterface mit möglichst geringen Latenzen
- 350MHz Takt mit 120Mio Transistoren

Das ist nur frei erfunden von mir :)

Eher unspektakulär aber bei praktischer Anwendung oho :D

[zeckensack]

Original geschrieben von Xmas
Wenn man bevorzugt Vertices verarbeitet, sollten die ALUs eigentlich immer gefüttert sein, sofern denn auch Arbeit ansteht. Die einzige Stall-Situation liegt doch dann vor, wenn der FIFO voll ist, sprich das Triangle Setup die transformierten Vertices gar nicht so schnell abgreifen kann wie der VS nachschiebt, gleichzeitig aber wegen Clipping und Z-Optimierungen keine Quads dabei herauskommen. Sprich: große, verdeckte Polygone.Das ist eine Möglichkeit, aber nicht die einzige. Ganz banale Füllratenlimitierung zB ist auch schon eine Unterauslastung der Einheiten.

Wirklich gleichmässige Auslastung aller Recheneinheiten erreicht man in der Praxis sowieso nie. Da spielen zu viele Faktoren mit hinein, nicht nur die Shader-Komplexität und der Polycount, sondern auch Auflösung und "Entfernung" einzelner Objekte. Über ein Frame verteilt und gemittelt mag die Performance ausreichend sein, aber es gibt quasi ständig punktuelle Unterauslastung. Wenn man diese Unterauslastung in jeweils mehr Vertex-Leistung oder mehr Füllrate umwandeln könnte, wäre das sicher gut. Ins blaue hinein würde ich ca 20~30% Mehrleistung schätzen, wenn so ein Verfahren ohne zusätzliche Reibungsverluste implementiert werden kann.

Sicher muss man sehr schnell wechseln können. Aber was spricht dagegen? PS und VS sind ja eben nicht mehr so grundsätzlich verschieden, dass der Wechsel so kompliziert wäre.Pipelining. Der Eingang der Einheit an einen anderen Chipteil angeschlossen werden. Die "alte" Aufgabe muss die Einheit verlassen. Der Ausgang der Einheit muss wiederum anders angeschlossen werden.
Das Extremszenario wäre, dass eine ALU vertices transformiert, dann umschaltet, und dann die soeben selbst erzeugte Geometrie mit Pixeln füllen muss. Sie kann logischerweise nicht beides gleichzeitig tun, denn die zweite Aufgabe ist von der Vollendung der ersten Aufgabe abhängig.

Mit dem physikalischen Layout kenne ich mich ehrlich gesagt nicht genügend aus. Aber liegt der Speichercontroller nicht traditionell außen?AFAIK ja. Ich meinte mit "drumherum" auch eher die logische Sicht. Vom Speichercontroller, durch die Verarbeitungsstufen, zum Speichercontroller zurück.
Beim physikalischen Layout wird dieser Ablauf dann quasi "gefaltet", sodass die Kommunikation mit der Aussenwelt möglichst nahe am Rand des Chips passiert. Allerdings ist es weiterhin sinnvoll, aufeinanderfolgende Pipeline-Stufen nahe aneinander zu positionieren, damit der chip-interne Datentransport möglichst schnell funktioniert (Stichwort: Takt).
Die offensichtlichste Lösung ist ein Layout, in dem man die Pipeline-Stufen der Reihe nach mit einer Linie verbinden kann, ohne eine Stufe zweimal zu "besuchen".

Den IP musst du wegen dynamischem Branching sowieso pro Verarbeitungseinheit (Quad bzw. Pixel, Vertex bzw. Vertexgruppe) mitführen. Wieso geht die SIMD-Struktur flöten?Weil du mehrere IPs brauchst. In gewissen Grenzen kann man auch nur mit einem einzigen IP arbeiten, und zB (wie beim RV350-Pixelprozessor) 4 ALUs a 4xSIMD parallel anfahren (effektiv 16xSIMD).
Vielleicht haben wir auch nur ganz andere Vorstellungen, wie man das bei einem IMR realisieren könnte. Ich male mal ein Bild... Ja, bitte :)

[Ailuros]

@HOT,

:lolaway:

@zeckensack,

Pipelining. Der Eingang der Einheit an einen anderen Chipteil angeschlossen werden. Die "alte" Aufgabe muss die Einheit verlassen. Der Ausgang der Einheit muss wiederum anders angeschlossen werden.
Das Extremszenario wäre, dass eine ALU vertices transformiert, dann umschaltet, und dann die soeben selbst erzeugte Geometrie mit Pixeln füllen muss. Sie kann logischerweise nicht beides gleichzeitig tun, denn die zweite Aufgabe ist von der Vollendung der ersten Aufgabe abhängig.

Egal jetzt ob TBDR oder IMR, eine Sache die ich bis jetzt nicht verstanden habe oder verstehen kann, ist wie das ganze im Zusammenhang mit den TMUs laeuft. Wuerde jemand VS3.0 spezifische TMUs einbauen? Wenn nicht, wie laeuft dass dann ab mit einer komplizierten PS/VS3.0 Masche als Beispiel?

[zeckensack]

Original geschrieben von Ailuros
@zeckensack,
Egal jetzt ob TBDR oder IMR, eine Sache die ich bis jetzt nicht verstanden habe oder verstehen kann, ist wie das ganze im Zusammenhang mit den TMUs laeuft. Wuerde jemand VS3.0 spezifische TMUs einbauen? Wenn nicht, wie laeuft dass dann ab mit einer komplizierten PS/VS3.0 Masche als Beispiel? Keine Ahnung :)
Es kommt darauf an :)
Bei "meiner" Lösung hätte man dieses Problem jedenfalls nicht.
Traditionell, also nicht "unified" könnte es IMO Sinn machen, dedizierte Textur-Sampler für die VS zu bauen. Macht man das nicht, sinkt die nutzbare (Texel-)Füllrate beim Einsatz von Texturen im VS, und diese "TMUs" müssten dann auch wieder zwischen VS und PS verschiebbar sein.

Man hätte dann quasi "unified" Textur-Sampler, aber keine "unified" ALUs.

Vielleicht wäre es auch eine gute Idee, den Textur-Cache aufzutrennen, damit sich Textursamples für den VS und den PS nicht gegenseitig rausschmeissen.

Komplett "unified" ist dann IMO eher einfacher. Auch wenn die Textur-Sampler nicht mehr so eng mit den ALUs verknüpft sind wie früher, es gibt immer noch schnelle Daten-Highways zwischen diesen Einheiten. Wenn man die Blöcke (ALU+Textur-Sampler) im ganzen zwischen VS und PS verschieben könnte, hätte man ein Problem weniger.

[Demirug]

Zum Thema Textursampler und VS eine kleine Randnotiz. Es scheint so das mindestens ein IHV plant für die VS eigene Textursampler zum Einsatz zu bringen. DX9 sieht für die VS und PS getrennte Filtercaps vor. Um genau zu sein gibt es in den VS zum Beispiel kein AF zu Auswahl. Wenn man die Latenz für ein AF-Sample berücksichtigt macht das irgendwo auch Sinn.

[Xmas]

Original geschrieben von zeckensack
Das ist eine Möglichkeit, aber nicht die einzige. Ganz banale Füllratenlimitierung zB ist auch schon eine Unterauslastung der Einheiten.
Sicher, aber dies kommt ja auch bei einem TBDR vor und ist nicht IMR-spezifisch. Zumindest sollte die Shader-Pipeline im Rahmen der Granularität voll ausgelastet sein, mit oben genannter Ausnahme.

Wirklich gleichmässige Auslastung aller Recheneinheiten erreicht man in der Praxis sowieso nie. Da spielen zu viele Faktoren mit hinein, nicht nur die Shader-Komplexität und der Polycount, sondern auch Auflösung und "Entfernung" einzelner Objekte. Über ein Frame verteilt und gemittelt mag die Performance ausreichend sein, aber es gibt quasi ständig punktuelle Unterauslastung. Wenn man diese Unterauslastung in jeweils mehr Vertex-Leistung oder mehr Füllrate umwandeln könnte, wäre das sicher gut. Ins blaue hinein würde ich ca 20~30% Mehrleistung schätzen, wenn so ein Verfahren ohne zusätzliche Reibungsverluste implementiert werden kann.
Kommt natürlich auf die Anzahl der Einheiten an. Wenn man statt 8 PS- und 4 VS-Pipelines (ähnlich fähig) 12 Pipes hat, die für beides geeignet sind, ist diese Schätzung wohl möglich.

Pipelining. Der Eingang der Einheit an einen anderen Chipteil angeschlossen werden. Die "alte" Aufgabe muss die Einheit verlassen. Der Ausgang der Einheit muss wiederum anders angeschlossen werden.
Das Extremszenario wäre, dass eine ALU vertices transformiert, dann umschaltet, und dann die soeben selbst erzeugte Geometrie mit Pixeln füllen muss. Sie kann logischerweise nicht beides gleichzeitig tun, denn die zweite Aufgabe ist von der Vollendung der ersten Aufgabe abhängig.
Mal abgesehen davon dass zwischendrin noch der Rasterizer werkeln muss. Deswegen müssen die Caches/FIFOs natürlich ausreichend dimensioniert sein.

Eingänge und Ausgänge anhand eines Flags bei den Verarbeitungseinheiten* zu multiplexen, sollte wohl ein geringes Problem sein.

AFAIK ja. Ich meinte mit "drumherum" auch eher die logische Sicht. Vom Speichercontroller, durch die Verarbeitungsstufen, zum Speichercontroller zurück.
Beim physikalischen Layout wird dieser Ablauf dann quasi "gefaltet", sodass die Kommunikation mit der Aussenwelt möglichst nahe am Rand des Chips passiert. Allerdings ist es weiterhin sinnvoll, aufeinanderfolgende Pipeline-Stufen nahe aneinander zu positionieren, damit der chip-interne Datentransport möglichst schnell funktioniert (Stichwort: Takt).
Die offensichtlichste Lösung ist ein Layout, in dem man die Pipeline-Stufen der Reihe nach mit einer Linie verbinden kann, ohne eine Stufe zweimal zu "besuchen".
Ich hab mal ein Bild angehängt. Da fehlen zwar einige Verbindungen und es ist natürlich stark vereinfacht, aber die Speicherzugreifenden Einheiten an den Rand zu packen sollte eigentlich kein Problem sein.

Weil du mehrere IPs brauchst. In gewissen Grenzen kann man auch nur mit einem einzigen IP arbeiten, und zB (wie beim RV350-Pixelprozessor) 4 ALUs a 4xSIMD parallel anfahren (effektiv 16xSIMD).
Davon gehe ich eigentlich aus. Wobei ich auch hier keinen Unterschied zwischen TBDR und IMR sehe.
*Auch wenn es nicht unbedingt x4 sein muss. Als Verarbeitungseinheit nenne ich hier mal ein Quad, auch wenn es neben Pixeln auch Vertices sein können, und es auch nicht vier sondern evtl. auch 2 sein dürfen, bei Branching auch noch wegmaskiert.

[Ailuros]

Original geschrieben von Demirug
Zum Thema Textursampler und VS eine kleine Randnotiz. Es scheint so das mindestens ein IHV plant für die VS eigene Textursampler zum Einsatz zu bringen. DX9 sieht für die VS und PS getrennte Filtercaps vor. Um genau zu sein gibt es in den VS zum Beispiel kein AF zu Auswahl. Wenn man die Latenz für ein AF-Sample berücksichtigt macht das irgendwo auch Sinn.

Ich hab ernsthafte Zweifel was die VS3.0 t-sampler betrifft, kann mir aber natuerlich nicht sicher sein. Angenommen die TMUs liegen sowieso im "Ueberfluss", ist es dann nicht sowieso egal?

zecki,

Traditionell, also nicht "unified" könnte es IMO Sinn machen, dedizierte Textur-Sampler für die VS zu bauen. Macht man das nicht, sinkt die nutzbare (Texel-)Füllrate beim Einsatz von Texturen im VS, und diese "TMUs" müssten dann auch wieder zwischen VS und PS verschiebbar sein.

So hab ich mir das auch vorgestellt.

Vielleicht wäre es auch eine gute Idee, den Textur-Cache aufzutrennen, damit sich Textursamples für den VS und den PS nicht gegenseitig rausschmeissen.

Klingt mir irgendwie zu gefaehrlich....koennte dass nicht leicht mehr Probleme entwickeln als loesen?

Danke uebrigens fuer jegliche Antwort :)

[Blutgrätsche]

Getrennte T-Sampler macht wenig Sinn. Wenn man unbedingt aniso verhindern will, dann kann das auch der Treiber erzwingen. 32 statt nur 16 Universal-Sampler macht evtl. Sinn.

Getrennte T-Caches oder Filterung halte ich auch nicht für sinnvoll. Mann muss eh die TMUs zwischen VS und PS relativ oft umschalten, weil man sonst zu viel Zwischenspeicher überall im Chip braucht. Mit einem VS-Buffer und einem PS-Buffer nach dem T-FIFO sollte die ganze Sache erledigt sein. Wenn man unbedingt auf der sicheren Seite liegen will, kann man natürlich auch verhindern, dass VS-Samples von PS-Samples aus dem Cache geschmissen werden. Sollte problemlos machbar sein und kann ebenso problemlos auch programmierbar gestaltet werden, aber nötig sollte es nicht sein.

Getrennte Filter-Einheiten ist ja nun genau das Gegenteil von einem unified Konzept. Die TMUs sollten eher über- als unterdimensioniert sein (von aniso abgesehen). Welche Shader in neueren Spielen brauchen schon Texture/Ops pro Takt? Wer will, kann natürlich aufrüsten, aber bitte nicht getrennt.

Zecke: Die Platzierung der TMUs sollte von den Weglängen relativ unkritisch sein, da durch ein FIFO vom Rest abgetrennt.

Xmas: Wozu gibt es in deinem Bild ein Post-TL-Cache, wenn er keine direkte Verbindung zur ALU hat?

Platziert man das IO-Interface nicht in die Mitte des Chips - da eine zentrale Station - und baut die anderen Einheiten drumherum, um die Leitungen zur Verteilung kurz zu halten?

[Xmas]

Original geschrieben von Blutgrätsche
Xmas: Wozu gibt es in deinem Bild ein Post-TL-Cache, wenn er keine direkte Verbindung zur ALU hat?
Wieso sollte man bereits transformierte Vertices wieder durch die ALU schicken? Nochmal transformieren?

Den Cache braucht es da, weil transformierte Eckpunkte zumeist zu mehreren Dreiecken gehören, also auch mehrfach verwendet werden, und um Vertex Shading und Rasterizer zu entkoppeln.
Natürlich braucht man eine Logik, die "weiß" welche Eckpunkte im Post-T&L-Cache liegen und diese dann gar nicht erst wieder vorne in die Pipeline reinlässt. Aber diese Information kann ebenso am Anfang der Pipeline gespeichert werden.