R500 Blockdiagram bei Techreport

[Demirug]

Das Diagramm kommt direkt von ATI. Aber schaut es euch selbst an:

http://www.techreport.com/etc/2005q2/xbox360-gpu/index.x?pg=1

[RLZ]

So schnell hätte ich nicht erwartet, dass ein grosser IHV die Idee mit dem Hardware-Multithreading im GPU übernimmt.
Sieht mal interessant aus...
Aber mal abwarten wie effizient es am Schluss wirklich ist.

[Demirug]

Massiv Mutlithreaded sind GPUs ja eigentlich schon immer. Neu ist hier wohl lediglich der Sequencer welcher die Reihenfolge der Threads verändern kann.

Die Effizienz könnte ein gutes Stück unterhalb der einer GPU mit bekannten Quad Pipe Design liegen. Das 16 fache SIMD hört sich verdammt nach 4*4 Pixel Tiles an was natürlich den Verschnitt erhöht.

Die Hautfrage wird allerdings nicht beantwortet. Es wird keinWort darüber verloren wie die Textureinheiten mit dem Shaderarray zusammenarbeiten.

[Ailuros]

Dumme Fragen:

1. Steht "vertex grouper" fuer eine Einheit die vielleicht "vertices in spatial order" zusammenfasst?

2. Der Sequencer ersetzt einen "driver shader optimizer"?

3. Wozu dienen die zwei Shader-Interpreter?

4. Was ist das "Pipe-Comm" - Ding nach den SIMD Einheiten? Eine Einheit die die Kommunikation zwischen den SIMD Einheiten uebernimmt?

5. Beige ist programmierbar, blau fixed function?

Die Hautfrage wird allerdings nicht beantwortet. Es wird keinWort darüber verloren wie die Textureinheiten mit dem Shaderarray zusammenarbeiten.

Warum sieht es mir eher nach einem TMU-array aus? 4-way array, wobei jeder Anteil bis zu 4 bilineare Texturen bearbeiten kann?

[Demirug]

1. Da es 16 faches SIMD ist müssen ja auch immer 16 verticen zu einer Gruppe zusammen gefasst werden.

2. Eher nicht. Der Shadercode wird immer noch durch einen Compiler optimiert. Da es sich aber um einen Consolenchip handelt wird man das in der Regel offline beim Entwickeln machen.

3. Ich denke mal einer für das aktuelle Vertex programm und einer für das Pixelprogramm

4. Das dürfte ein Crossbar sein die entscheidet wohin die Daten nach dem rechnen gehen sollen.

5. Ja so in etwa.

Natürlich sieht das wie ein TMU Array aus. Da ja immer 16 Pixel als Block den gleichen Befehl ausführen macht es auch sinn die ganzen TMUs zusammenzufassen.

[robbitop]

Ein sehr interessantes und innovatives Design. Nun wissen wir, was ATI seit 2002 getan hat. Besonders das virtualized momory system und ein paar andere Finessen faszinieren mich.

Ich nehme ATI aber nicht ab, dass R500 kein VLIW Design ist. Vieleicht ist mehr Kontrolllogik für die Shader da als bei einer NV3x/4x, aber sind nicht alle GPUs eine VLIW Architektur?

[Demirug]

Ein sehr interessantes und innovatives Design. Nun wissen wir, was ATI seit 2002 getan hat. Besonders das virtualized momory system und ein paar andere Finessen faszinieren mich.

So innovativ ist das eigentlich nicht. Man hat um einen SIMD FP Signalprozessor die zusätzlichen Fixedfunktion einer GPU gebaut. In Sachen kontrollogik ist es sogar ein Rückschrit weil man jetzt nur noch einen Steuerprozess hat.

Ich nehme ATI aber nicht ab, dass R500 kein VLIW Design ist. Vieleicht ist mehr Kontrolllogik für die Shader da als bei einer NV3x/4x, aber sind nicht alle GPUs eine VLIW Architektur?

Spätestens auf dem untersten Level ist es ein VLIW weil für alle Einheiten der Pipe irgendwo ein gemeinsames Befehlswort erzeugt werden muss. Das gilt streggenomen allerdings auch für viele moderne CPUs. Der Befehlssatz selbst welcher im Speicher liegt bzw übertragen wird muss aber nicht zwingend ein VLIW sein. Angeblich benutzt der NV40 keinen VLIW Befehlssatz mehr sondern einen vereinfachten welcher von der GPU selbst zu den internen VLIW Anweisungen kompiniert wird. Der Grund dafür ist das Branching und Looping. Es ist also durchaus denkbar das ATI beim R500 ein ähnliches Verfahren nutzt.

[Quasar]

Wenn es schon geile Compiler von M$ gibt, und die Speichereinheit/ROPs quasi getrennt von der Hauptkernlogik ist, wieso sollte ATi dann nicht genau dieses Design noch mit "herkömmlichen" ROPs verbinden und dann auf den PC-Markt loslassen in Form des R520?

Was anderes:
Die Organisation in 3 "Pipelines" bedingt ja auch eine gewisse Unflexibilität in Sachen Load-Balancing (deswegen sprach man IMO auch nicht durchgehend von Unified Shadern). Man kann höchstens zwei Drittel der nominellen Leistung für Pixel-Shading nutzen, falls das VP nicht komplett von der CPU übernommen wird.
Anders herum könnte da ein durchaus monströser Workstation-Chip draus werden... wenn man sich das Fragment-Shading im aktuellen Einsatz schenken kann wie bsw. bei Drahtgittern usw.

[Demirug]

Wenn es schon geile Compiler von M$ gibt, und die Speichereinheit/ROPs quasi getrennt von der Hauptkernlogik ist, wieso sollte ATi dann nicht genau dieses Design noch mit "herkömmlichen" ROPs verbinden und dann auf den PC-Markt loslassen in Form des R520?

Zu langsam für den PC.

Was anderes:
Die Organisation in 3 "Pipelines" bedingt ja auch eine gewisse Unflexibilität in Sachen Load-Balancing (deswegen sprach man IMO auch nicht durchgehend von Unified Shadern). Man kann höchstens zwei Drittel der nominellen Leistung für Pixel-Shading nutzen, falls das VP nicht komplett von der CPU übernommen wird.
Anders herum könnte da ein durchaus monströser Workstation-Chip draus werden... wenn man sich das Fragment-Shading im aktuellen Einsatz schenken kann wie bsw. bei Drahtgittern usw.

Das ist doch nur eine Pipeline mit 3 Rechenwerke in Reihe. Skaliert wird über die Threads. Es können daher nur Pixelthreads laufen solange der Vertexcache noch genügend Verticen für die nächsten Dreiecke enthält. Postfilter sind da ein gutes Beispiel. Am Anfang ein "Thread" mit 4 Verticen und dann nur noch Pixelthreads.

[Quasar]

Ach so!
edit:
Öh. Habe wohl die Pfeilrichtung etwas mißachtet... hatte irgendwie vertikale Pfeile gesehen...

Aber "zu langsam" - wer weiß.

edit:
Unter diesen Umständen wird es dann wohl wirklich etwas knapp werden, es sei denn, sie kriegen wirkliche hohe Taktfrequenzen da rein.

[Demirug]

Ach so!
edit:
Öh. Habe wohl die Pfeilrichtung etwas mißachtet... hatte irgendwie vertikale Pfeile gesehen...

Ja die 4 TMUs oben können da etwas verwirren.

Aber "zu langsam" - wer weiß.

edit:
Unter diesen Umständen wird es dann wohl wirklich etwas knapp werden, es sei denn, sie kriegen wirkliche hohe Taktfrequenzen da rein.

Das meinte ich mit "zu langsam". Die eine Pipe muss ja Vertex und Pixelaufgaben übernehmen. Zudem müssen ja erst auch noch die ROPs rein was den DIE ja erst mal noch größer macht. ATI wird schon gründe gehabt haben dieses Design schon seit dem R400 für nicht PC tauglich zu halten.

[Ailuros]

Das ist doch nur eine Pipeline mit 3 Rechenwerke in Reihe. Skaliert wird über die Threads. Es können daher nur Pixelthreads laufen solange der Vertexcache noch genügend Verticen für die nächsten Dreiecke enthält. Postfilter sind da ein gutes Beispiel. Am Anfang ein "Thread" mit 4 Verticen und dann nur noch Pixelthreads.

Bis jetzt hatte ich den Eindruck dass Microsoft ATI fuer Xenon hauptsaechlich wegen der Leistung gewaehlt hat (aus dem Pool von diversen Konkurrenten mit denen verhandelt wurde). So langsam habe ich aber das Gefuehl dass dieses wohl nicht unbedingt der Fall ist.

Es gibt selbstverstaendlich ziemlich logische Gruende einen grossen IHV zu waehlen fuer solch einen Fall (zweifellos), aber Leistung scheint nicht darunter zu sein.

[Coda]

Naja Leistung/Transistor&Abwärme dürfte recht gut sein, was für eine Konsole nicht unwichtig ist.

[Ailuros]

Naja Leistung/Transistor&Abwärme dürfte recht gut sein, was für eine Konsole nicht unwichtig ist.

Ich wuerde auf niedrigere Raten denken in allen drei Abteilungen fuer das was ich meinte.

[Tyler_Durden]

Das meinte ich mit "zu langsam". Die eine Pipe muss ja Vertex und Pixelaufgaben übernehmen. Zudem müssen ja erst auch noch die ROPs rein was den DIE ja erst mal noch größer macht. ATI wird schon gründe gehabt haben dieses Design schon seit dem R400 für nicht PC tauglich zu halten.

Also war die heise Aussage garnicht so falsch, das sich der R500 Chip in etwa auf nem Level mit ner X700 bewegt?
Das wäre nun wirklich ein Armutszeugnis für MS, wenn man sich die Demos der PS3 mit dem RSX ansieht!

[Quasar]

Also war die heise Aussage garnicht so falsch, das sich der R500 Chip in etwa auf nem Level mit ner X700 bewegt?
Das wäre nun wirklich ein Armutszeugnis für MS, wenn man sich die Demos der PS3 mit dem RSX ansieht!
Doch, sie ist falsch. Das einzige, was auf X700-Niveau liegt, sind die 8 Pixel/Takt maximalen Outputs. Der Rest von Xenon scheint aber so designd zu sein, daß diese 8 Pixel auch möglichst oft inklusive AA und allen möglichen Shadern zu Stande kommen.

[Tyler_Durden]

Naja, dafür das das R500 Design als revolutionär angekündigt war ist bis jetzt nicht viel ürbig geblieben. Bis jetzt hat mich auch keine von MS gezeigten Demos vom Hocker gerissen wenn ich ehrlich bin.
Interessieren würde mich mal so nen Blockdiagramm vom RSX, der scheint mir deutlich potenter zu sein. Aber das is nur Speku. ;)

[Demirug]

Das Design des R500 ist schon anders als alles was man bisher im GPU bereich gesehen hat. Deswegen ist es ja auch so schwer zu vergleichen.

Mein "zu langsam" bezog sich darauf das man mit diesem Chip im PC Bereich keinen Blumentopf gewinnen könnte weil lediglich in etwa auf dem Level der aktuellen Highend PC Chips liegt. Pro Pipe steht zwar mehr rechneleistung zur Verfügung aber im Gegenzug muss davon auch wieder etwas an das Vertexprocessing abgegeben werden. Ich gehe davon aus das umgerechnet man 2 bis 3 der 16 Kanäle an das Vertexprocessing verliert. Das jetzt aber bitte nicht so verstehen das die ALUs Pipeweise auf PS und VS verteilt werden.

Das Blockdigramm eines RSX dürfte dem eines NV40 sehr ähnlich sein.

[Tyler_Durden]

Ah, jetzt wird einiges klarer.

Das das Blockbild des RSX dem NV40 ähneln wird ist auch logisch, wenn denn der RSX im Kern ein G70 ist, welcher ja selbst nur ein um 2 Quads erweiterter NV40 sein soll.

[Riptor]

Naja, dafür das das R500 Design als revolutionär angekündigt war ist bis jetzt nicht viel ürbig geblieben. Bis jetzt hat mich auch keine von MS gezeigten Demos vom Hocker gerissen wenn ich ehrlich bin.

Mal sehen, was am Ende dabei herauskommen wird. ;)
Insgesamt verbindet der R500 doch genau das, was man von einer Konsolen-GPU erwartet: Viele Effekte (nebenher) und ein Design, das voll auf eine Konsole zugeschnitten ist. Unter PC-Gesichtspunkten ist die GPU aber sicherlich keine Offenbarung.

[Demirug]

Das scheint die passenden Patentschrift (http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=6,897,871.WKU.&OS=PN/6,897,871&RS=PN/6,897,871) dazu zu sein.

[zeckensack]

Das Diagramm kommt direkt von ATI. Aber schaut es euch selbst an:

http://www.techreport.com/etc/2005q2/xbox360-gpu/index.x?pg=1Da fehlen IMO Pfeile vom Ausgang des Vertex Groupers zu den Recheneinheiten, und vom Ausgang der Shader zurück zum primitive assembly.

Bzw, da die direkte Verbindung zwischen VG und PA wegfällt, könnte man das Diagramm gleich richtig umstrukturieren.

So kann das eigentlich nicht funktionieren :|

[Demirug]

Da fehlen IMO Pfeile vom Ausgang des Vertex Groupers zu den Recheneinheiten, und vom Ausgang der Shader zurück zum primitive assembly.

Bzw, da die direkte Verbindung zwischen VG und PA wegfällt, könnte man das Diagramm gleich richtig umstrukturieren.

So kann das eigentlich nicht funktionieren :|

Laut Dave Baumann ist das Ding sowieso nicht richtig. Scheint eher für marketingzwege den zum erklären von technischen Hintergründen gedacht zu sein.

[Coda]

Ich hab in nem anderen Thread schonmal gefragt, aber hat jemand ne Ahnung wie Early-Z-Out mit dem eDRAM funktioniert?

[robbitop]

Ich hab in nem anderen Thread schonmal gefragt, aber hat jemand ne Ahnung wie Early-Z-Out mit dem eDRAM funktioniert?
Warum sollte das anders funktionieren als mit herkömmlichen GPUs?
Im Trisetup werden die Tiefenkoordinaten bei der Rasterisierung an die ROPs geschickt. Diese machen einen Speicherzugriff und schauen, ob der Tiefenwert größer ist als das was bisher an dieser Adresse steht. Falls ja, fliegt der Pixelquad raus und wird gar nicht erst gerendert, falls nein kommt er in die Pipeline. Warum sollte das hier anders sein?

[Coda]

Ja ok, ich war mir nie ganz sicher ob die ROPs auch für das Rasterizing verantwortlich sind, weil sie in der Pipeline immer hinter den Pixelpipelines sind.

Das ist dann ja so nicht ganz richtig.