Diskussion zu: AMDs RV-FE läuft derzeit noch ohne Tile-based Rasterizer ...

[Leonidas]

Link zur News:
https://www.3dcenter.org/news/amds-radeon-vega-frontier-edition-laeuft-derzeit-noch-ohne-tile-based-rasterizer-und-damit-im-p

[lowkres]

Wie ich schon meinte, wird AMD mit großer Wahrscheinlichkeit den finalen Treiber in einem Monat auch für die Frontier Edition rausbringen. Ob das jetzt eine gute Entscheidung war die Frontier Edition mit unfertigen Treibern zu releasen muss jeder für sich entscheiden. Ich hoffe doch nur das mit dem finalen Treiber die wahre Kraft der Vega Architektur zum Vorschein kommt.

[Elite_Warrior]

Die hätten sich den release der Vega FE echt sparen sollen. Kaum verfügbare Karten und Treiber nicht fertig. Dafür allerdings Chaos und Häme in den Foren.

€: Zwar würde ich nicht darauf wetten: Aber ein Kepler to Maxwell Boost wäre allerdings fett.

[Gast]

Die hätten sich den release der Vega FE echt sparen sollen.
Gibt es dafür auch eine Begründung?
Die FE ist KEINE Gamerkarte, für den angedachten Zweck ist der Treiber fertig!

[Leonidas]

Nein. Wenn Game-Optimierungen fehlen würden - okay. Aber fehlende Architektur-Features? Das ist kein fertiger Treiber mehr.

Und die Karte hat sehr wohl Game-Aufgaben zu erfüllen. Als Karte für Spiele-Entwickler geht es zwar nicht um die letzten paar Prozent Performance, aber gerade die Features müssen natürlich alle an Bord sein.

[ottoman]

Ich dachte AMD musste die Karte noch im 2. Quartal herausbringen, da das den Aktionären angekündigt wurde und ansonsten hohe Strafen drohen?

[Dino-Fossil]

Das ist eine der bemühten Erklärungen. Müsste man nochmal einen Juristen mit dem entsprechenden Hintergrund fragen, wenn man wirklich sicher sein will.

[cat]

soll ich jetzt verschweigen, dass Raja uns Neugierige ja gewarnt hat.

Ganz ehrlich DANKE an digidi, sein Vorschlag zum Tiled-Rasterizer Test hätte auch define gemacht werden sollen, dann wär der Ofen sofort wieder aus gewesen.

BTW das ist doch nur die Ghandi-Methode stiller Wiederstand gegen Gaming-Benchmarks durch Abwesenheit von Features.

[Gast]

Ich dachte AMD musste die Karte noch im 2. Quartal herausbringen,
Haben sie doch getan...

[Cyphermaster]

Als Karte für Spiele-Entwickler geht es zwar nicht um die letzten paar Prozent Performance, aber gerade die Features müssen natürlich alle an Bord sein.Ohne TBR verliert die Karte aber doch lediglich Performance, für den Anwendungszweck macht das fehlende Feature ansonsten keinerlei Unterschied, da es weder für Content Creation, noch für Optimierungen der Spiele-Software benötigt wird (vorausgesetzt, TBR braucht dort nicht doch zusätzliche Implementierungen). Wenn DX-Level nicht unterstützt würden oder dergleichen, hättest du recht.

[Blutmaul]

Vielleicht ist der Name Frontier Edition darauf bezogen, das der Karte derzeit noch enge Grenzen gesetzt sind?

Ich fand die Demo mit dem HBCC Feature on vs off schon ganz nett und ansonsten ist AMD doch glasklar gewesen in der Aussage, das sie nicht die Gamers-Edition der neuen Architektur ist, also versteh ich jetzt die Kritik eigentlich als Kritik an einer unzutreffenden Erwartungshaltung und Ungeduld.

Noch fällt kein Himmel auf den Boden!

[Schnitzl]

soll ich jetzt verschweigen, dass Raja uns Neugierige ja gewarnt hat.
(...)
Stimmt ich erinnere mich! Er sagte "es lohnt sich definitv zu warten".
Es bleibt auf jeden Fall spannend, mit diesen neuen Infos könnte er sogar Recht haben ^^

[Gast]

Ohne TBR verliert die Karte aber doch lediglich Performance, für den Anwendungszweck macht das fehlende Feature ansonsten keinerlei Unterschied, da es weder für Content Creation, noch für Optimierungen der Spiele-Software benötigt wird (vorausgesetzt, TBR braucht dort nicht doch zusätzliche Implementierungen).

Doch, es hat nämlich nicht ohne Grund so lange gedauert bis wir überhaupt paralleles Rasterizing und jetzt schließlich den TBR-Ansatz von Nvidia gesehen haben.
Es handelt sich hier nämlich im Prinzip um eine Art OOE für den Rasterizing-Teil in der Renderpipeline.
Die heutigen APIs schreiben hier aber einen streng linearen Ablauf vor. Wenn die Hardware in der Realität was anderes macht muss sie dafür sorgen, dass es für die Software immer noch so aussieht als wäre alles in der richtigen Reihenfolge gerendert. Gleich wie es bei OOE in der CPU für die Software immer so aussehen muss als wäre das Programm in der vorgeschriebenen Reihenfolge abgelaufen. Damit ist es natürlich ein potentiell fehleranfälliges Feature, und es wäre gerade für AMD gut, wenn es schon drinnen wäre um aufgrund der Rückmeldungen von Entwicklern potentielle Bugs auszubessern. Es ist sicher besser wenn diese Bugs von einer Handvoll Entwickler erkannt werden, anstatt erst bei tausenden anderen Kunden.

Und damit kommen wir auch schon zum Punkt, dass alle Interpretationen hier falsch sind.
Das genannte Programm kann nicht zeigen, dass kein TBR aktiv ist, es kann lediglich zeigen dass es aktiv ist.

Wir wissen nicht wie der TBR, oder genauer gesagt das Triangle binning von AMD funktioniert.

Im Grunde genommen ist Nvidias Treiber fehlerhaft, da er eben in diesem Spezialfall nicht das korrekte Bild zeigt.
Viele der Effizienzfeatures können nicht immer aktiv sein. Z.B. darf Early-Z nicht aktiv sein wenn ein Pixelshader eingesetzt wird der den Z-Buffer verändert. Auch in diesem speziellen Beispiel (wenn Pixel im Shader verworfen werden) darf kein Early-Z aktiv sein, da es ansonsten je nach Renderreihenfolge vorkommen würde, dass wir immer nur das oberste (also dem Bildschirm nächste) Dreieck sehen würden.

Es kann genauso gut der Fall sein, dass AMDs Treiber eben diesen Spezialfall erkennt und TBR deaktiviert, da es wie bei Nvidia zu sehen ja das falsche Endergebnis liefert.


Es kann natürlich gut sein, dass das Triangle Binning tatsächlich noch nicht aktiviert ist, aber ausschließen kann man das aufgrund dieses Tools nicht.
Auch könnte es sich bei AMD um einen TBDR handeln. In dem Fall würden wir auch nicht das Maxwell-Muster sehen, dieses kommt ja nur zustande weil es sich um einen TBIR handelt.

[G3cko]

War doch von von Anfang an klar...

[Gastarbeiter]

Das erinnert mich an die gute alte Kyro2. Die hatte deutlich weniger Rohleistung als die Geforce2, konnte aber durch TBR trotzdem recht gut mithalten.
Das läßt für Vega hoffen.

[DinosaurusRex]

Verbraucht Vega mit diesem Rasterizer dann mehr Strom oder weniger oder macht das überhaupt keinen Unterschied?

[bbott]

Verbraucht Vega mit diesem Rasterizer dann mehr Strom oder weniger oder macht das überhaupt keinen Unterschied?

???

Wenn man weniger berechnen muss und die Einheiten und RAM entlastet brauch ich erst mal weniger Strom, wenn ich aber keinen Framelimiter einsetze werden eben mehr fps erzeugt. Die Auslastung bleibt (in etwa) gleich.

Wenn nicht irgendwo ein (anderer) Flaschenhals auftritt werden, einfach nur andere Sinnvollere Berechnungen durchgeführt, bei gleichem Stromverbrauch.

Damit steigt die Effizienz.

[pixeljetstream]

Die heutigen APIs schreiben hier aber einen streng linearen Ablauf vor. Wenn die Hardware in der Realität was anderes macht muss sie dafür sorgen, dass es für die Software immer noch so aussieht als wäre alles in der richtigen Reihenfolge gerendert.
...
Im Grunde genommen ist Nvidias Treiber fehlerhaft, da er eben in diesem Spezialfall nicht das korrekte Bild zeigt.


Hallo Gast, diese Aussagen sind so nicht ganz richtig. Das einzige was die APIs an Ordering vorgeben ist in ROP (Raster Output): an der Stelle x,y muss der berechnete pixel eines Primitives, nach dem vorherigen Primitive durch ROP abgearbeitet werden. Aufgeteilt in CROP = color rop, ZROP = zbuffer rop, welches wiederum auch nicht am Ende kommen muss, wie du erwähnst, gibts diverse earlyZ Optimierungen. Auch bei den Z Optimerungen gibt's Spielraum: der shader kann durchaus den z-wert verändern (eben nur "nach hinten" bei standard depth-test), dann kann man das Dreieck dennoch verwerfen, wenn es "hinter" dem hierarchischen zbuffer liegt. In dem Fall muss man ja gar nicht durch ZROP (man modifiziert ja keine z werte), ergo ist für den Schritt die Reihenfolge auch egal, denn ein anderes Dreick kann den depth-buffer ja nur "nach vorne" verändern, selbst wenn das Dreieck nun von der Reihenfolge eigentlich vorher dran war.
Das gilt aber eben nur je Pixel koordinate, und nur für ROP. Wie die Pipeline davor (oder zwischen ZROP/CROP) ausgeführt wird, ist dem Hersteller überlassen. Man kann also ohne Probleme Reihenfolgen über den ganzen Bildschirm, bzw. mehrere Dreiecke betrachtet verändern.

In einem GTC Talk gehen ein Kollege und ich auf den Parallelismus im System ein: http://on-demand.gputechconf.com/gtc/2016/presentation/s6138-christoph-kubisch-pierre-boudier-gpu-driven-rendering.pdf
http://on-demand.gputechconf.com/gtc/2016/video/S6138.html

Die Art und Weise wie der Test programmiert ist, ist legitim und kein "NVIDIA bug". Der shader benutzt einen atomic counter um pixel zu verwerfen. Dieser counter muss nicht das primitive ordering beachten, und deswegen kann man dadurch schön sehen in welcher Reihenfolge die pixel/fragment shader in etwa aufgerufen werden. "In etwa" weil in der Hardware immer diverse "queues" am Werke sind, der rasterizer also schon längst an den nächsten pixeln arbeitet, bis im fragment shader der atomic counter den wert zurückgegeben hat. Ausserdem wird durch die SIMT Architektur ja an mehreren Pixeln parallel als Gruppe in lock-step gearbeitet, das heißt die Serialisierung innerhalb des "Warps/Wavefronts", welcher der counter suggeriert, findet so nicht statt.

Du hast aber Recht, dass das Testprogramm nicht belegt ob der Treiber/Hardware grundsätzlich das Feature nicht kann. Denn der Treiber kann ja so programmiert sein, das Feature nach Heuristik oder white-listing zu aktiveren. Denn das TBR Verfahren garantiert ja nicht immer einen Performancegewinn, und es ist ja nicht "ein Verfahren" sondern eine Verfahrensgruppe, wie es im Detail umgesetzt ist, welche trade-offs etc., ist ja nicht öffentlich.

[Der_Korken]

Verbraucht Vega mit diesem Rasterizer dann mehr Strom oder weniger oder macht das überhaupt keinen Unterschied?

Der Verbrauch wird gleich sein, da er durch Powertargets und max. Temperaturen begrenzt ist. Es kann aber sein, dass der durchschnittliche Takt sinkt, wenn die interne Auslastung der Karte steigt, d.h. wenn die Karte pro Takt mehr schafft. Die Effizienz sollte sich aber insgesamt verbessern, allein deswegen weil viele Speicherzugriffe durch Cache-Zugriffe ersetzt werden.

[Gipsel]

Es kann aber sein, dass der durchschnittliche Takt sinkt, wenn die interne Auslastung der Karte steigt, d.h. wenn die Karte pro Takt mehr schafft.Das ist stark von der Situation abhängig. Wenn das hidden surface removal greift (was nicht immer der Fall sein kann), sinkt die Arbeit für die Shader und die effektive Auslastung kann sogar ebenfalls sinken (trotz gestiegener Performance). Falls das nicht greift, gilt das, was Du geschrieben hast: Die Shader werden hoffentlich besser ausgelastet, man spart aber bei Datentransfers, weil mehr im Cache liegt.

[Gast]

TBDR wurde damals durch 3dfx von Gigapixel zugekauft. Das TBR Subset hat nicht nur Vorteile, denn die meisten Spiele oder (vllt. sogar alle) sind auf IMR (Immediate Mode Rendering) optimiert. Maxwell- und die Pascal-Architektur können NVidias TBR nur ausführen, weil eine spezielle und interne Treiberanpassung im dx-Code greift (Triangle_rasterization). Andere Bereiche der Grafik-Pipeline wie Tessellation, Geometry, Shader etc. bleiben dabei unangetastet.

Natürlich muss AMD eine dergleichen Anpassung mittels Treiber genauso vornehmen und das macht erst Sinn wenn die Vega RX erscheint. Im Übrigen ist dieser TBR Leistungszuwachs Maxwell zu Pascal a 35% gleich geblieben. NVidia hat dahingehend diese Performance bei Pascal nicht gesteigert. Da AMD mit HBC, Caching und DSBR wahrscheinlich massiv weniger Speicher braucht und mit mehr Takt kommt, kann man bei Vega klar eine höhere Performance als Fiji IP erwarten, wenn der Treiber hinsichtlich des Codes optimiert wurde. Dannn passt auch deren Leistungsaufnahme ins Bild.

FE liefert ähnliche Leistung wie Fiji- und Polaris IP, da derzeit reines IMR auf der Hardware läuft. Ob der professionelle Treiber (Dev) schon auf DSBR optimiert ist, hat von euch keiner abgeprüft!

[Gipsel]

Das hat mit Gigapixel, TBDR und Spieloptimierungen recht wenig zu tun, weil nVidias Lösung des Tiled/binning Rasterizers (und dann hoffentlich bald auch AMDs) im Prinzip immer noch einen IMR darstellt (halt nur einen optimierten).

[Gast]

Verbraucht Vega mit diesem Rasterizer dann mehr Strom oder weniger oder macht das überhaupt keinen Unterschied?

Bei gleicher Performance würde er massiv weniger Strom brauchen.

Irgendwo hat Nvidia mal gesagt, dass der Hauptgrund für den Rasterizer seit Maxwell die deutlich bessere Energieeffizienz ist, nicht unbedingt die Performancesteigerungen. Wobei letztere sich natürlich dadurch ergeben dass man bei gleichem Powertarget höhere Taktraten fahren kann und damit die Performance natürlich wieder steigt, man muss also im Endeffekt Performance und Verbrauch immer zusammen betrachten.

Die Einsparungen vom Verbrauch kommen dabei hauptsächlich vom Einsparen der benötigten externen Bandbreite, wobei Vega hier natürlich durch die Verwendung von HBM etwas weniger potential hat, wie eine GPU die GDDR verwendet, da der Stromverbrauch pro übertragenem Bit bei GDDR größer ist.

Wie es sich im Realbetrieb verhält hängt dabei heutzutage natürlich von der Steuerung der ganzen Turbo/Boost etc. ab.

Eine mögliche Variante wäre, dass Vega ohne TBR Powertarget limitiert ist und damit niedrigere Taktraten fahren muss. Mit TBR spielt dann das Powertarget keine Rolle mehr --> die Taktraten liegen immer am Maximum und die Performance steigt entsprechend, bei niedrigerem Verbrauch.

Die andere Variante wäre natürlich dass Vega immer vom Powertarget limitiert wird, dann würde der aktive TBR natürlich die effektiv anliegenden Taktraten und damit auch die Performance erhöhen, der Verbrauch aber weitestgehend gleich bleiben.

Die meisten Tests die wir bisher gesehen haben liefen ja mit hochgeschraubtem Power-Target um die Tatkraten stabil am Maximum zu halten. In dem Fall würde das Aktivieren vom TBR den Verbrauch senken, da das Limit ja die eingestellte Taktrate und nicht der Verbrauch ist.

Wieviel ein aktiver TBR an Performance bringen kann ist auch stark davon Abhängig wie er umgesetzt wurde.

Nvidias Variante macht beispielsweise soweit ich weiß kein zusätzliches HSR im Rasterizer. Die Dreiecke werden immer noch in der vorgegebenen Reihenfolge pro Tile gerendert. Es gibt natürlich die Jahrzehntelangen Maßnahmen wie Early-Z um Overdraw so früh wie möglich zu verhindern, aber es gibt kein weiteres Sortieren der Dreiecke im Rasterizer.
Die Mehrperformance die Nvidia daraus bekommt, kommt ausschließlich von der eingesparten Speicherbandbreite.
Diese Mehrperformance teilt sich wieder auf in den eingesparten Stromverbrauch und die damit möglichen höheren Taktraten bei gegebenem Powerlimit und die möglicherweise ausgelastete Speicherbandbreite.

Falls AMDs Lösung ähnlich arbeitet lässt sich einigermaßen abschätzen wie viel Performance noch drinnen ist.

Dazu müsste man mal herausfinden wie sehr Vega überhaupt an der Speicherbandbreite hängt, was mit Benchmarks mit übertaktetem Speichertakt relativ einfach möglich sein sollte.

Falls Vega aufgrund der hohen Speicherbandbreite kaum vom Speichertakt abhängt, sollte durch den TBR auch kaum Mehrperformance gegenüber den jetzigen Benchmarks mit festgesetztem Chiptakt auf 1600MHz drinnen sein, das allerdings bei deutlich freundlicheren Verbrauchswerten.
Wenn die Speicherbandbreite jetzt schon am Limit ist, ist natürlich deutlich mehr Performance drinnen.

[Gast]

Die grundlegende Technologie basiert auf Gigapixels Ansatz, nicht STM, nV oder AMD. Die geben dem Kind nur andere Namen.