Diskussion zu: AMD streicht den eigenen Treiberpfad f. d. "Primitive Shaders" v. Vega

[Leonidas]

Link zur News:
https://www.3dcenter.org/news/amd-streicht-den-eigenen-treiberpfad-fuer-die-primitive-shaders-von-vega

[cat]

1. Bitte nie jemand fremden deine Probleme zu lösen.
2. Löse nie in Fremdsoftware war du selbst in Hardware lösen kannst.

** GCN leidet bei mehr als ca. 3072 Cores [48CU] an einem krassen Ungleichgewicht zwischen
Geometrie und Shader/Texturleistung **


AMD kann sich mit GCN nicht zu "mehr als 4 Geo-Engines" entscheiden, die Architektur verbietet es.

[MrSpadge]

Sieht nach dem üblichen ATI/AMD-Problem aus: man baut was nettes ein und hofft dann, dass die Entwickler es nutzen werden. Eine Hand voll netter Demonstratoren gibt es dann, meist ohne durchschlagenden Erfolg. Und das war's dann auch.

Da wäre ein einmaliges Aktivieren beim Start der Anwendung viel besser gewesen - aber wenn sie es selbst schon nicht hinbekommen, wird das wohl sehr schwierig sein bzw. auf eine Lösung pro Spiel / Engine hinauslaufen müssen.

@Cat: es klingt erstmal nicht so abwegig, die Architektur zu erweitern um mehr dieser Einheiten zu erlauben. Ein neuer Chip ist ja eh ne neue GCN-Generation.

MrS

[Bucklew]

Wenn Primitive Shaders zukünftig über eine proprietäre API angesteuert werden - sollte dieses Feature dann bei Benchmarks nicht deaktiviert sein, wie se z.B. bei GameWorks häufig gemacht wurde in der Vergangenheit?

[Gast Ritis]

AMD kann sich mit GCN nicht zu "mehr als 4 Geo-Engines" entscheiden, die Architektur verbietet es.
Was noch zu beweisen wäre. Geometrie Engines und ROPs sind nunmal Einheiten, die in einem generischen Compute Chip völlig unnötig sind. Vielleicht ist es auch nur der bislang feste Wille GCN nicht in diese Richtung zu entwickeln, weil man gehofft hat das anders in den Griff zu bekommen.

Diese aktuelle seltsame Diskussion über Primitive Shader geht auch arg in die Hose, irgend wie.

Das war doch klar, dass dieses über die Öffnung des strikten Renderpfades die Shader bzw. CU-Units für die Geometrieberechnungen ermöglichen soll. Wenn Vega dort flexibler geworden ist wird man das für künftige Architekturen kaum wieder zurücknehmen. (Dan Baker hat in nem Interveiw sogar schon über Rendering allein mit Shader nachgedacht, ganz ohne ROPs und Geometry Engines, ist IMHO kein Zufall gewesen)

Dass dann in bestehendem Code das wegen der Auslastung mit anderen Shader-Programmen und den ACE Scheduling hackelig wird und doch wohl nur gezielt eingesetzt werden kann war doch sicherlich immer die erste Annahme. Ein Versprechen, dass das alles völlig automatisch geht ging doch sicher nie von AMD aus über die offiziellen Kanäle. Das ist doch Wunschdenken von Gamern und zugehörigen "Journalisten" selbst, oder etwa nicht?

Aus dem Vega Whitepaper geht eigentlich relativ klar hervor, dass es hier um neuen Möglichkeiten für Coder geht:

"Primitive shaders have many potential uses beyond
high-performance geometry culling. Shadow-map
rendering is another ubiquitous process in modern engines
that could benefit greatly from the reduced processing
overhead of primitive shaders. We can envision even more
uses for this technology in the future, including deferred
vertex attribute computation, multi-view/multi-resolution
rendering, depth pre-passes, particle systems, and
full-scene graph processing and traversal on the GPU.
Primitive shaders will coexist with the standard hardware
geometry pipeline rather than replacing it. In keeping with
“Vega’s” new cache hierarchy, the geometry engine can now
use the on-chip L2 cache to store vertex parameter data."

Das ist doch klar kein HW-feature mit on/off Schalter. Das Culling muss ja noch berücksichtigt werden. Wie soll da ein generischer Treiber entwickelt werden, das geht höchstens über angepasste "Patches" für bestehende Software, auch wenn die dann im Treiber daherkommen.

Ganz im Gegenteil spricht aber auch nichts dagegen, dass über die GPUopen Initiative für Primitive Shader offener Code entwickelt wird, den Engine- und div. Game-Entwickler wiederverwenden können. Das ist doch der Sinn von GPUopen. (Leider ist da für meinen Geschmack noch etwas zu wenig los.)

Meine Vermutung ist, da wurde von irgend jemand ein Versprecher und Missverständnis in einen großen Eintopf geworfen, umgerührt und mit 'ner Priese Wunschdenken wiedergegeben um es heute dann revidieren zu dürfen.


----- für all die Abwerter:
Vega ist IMHO eine super Architektur, nur Front und Backend der Render-Pipeline sind für herkömmlichen Gaming-Code zu eng. Die Problemlösungen für die Gaming-Community haben wohl nicht so gezündet wie AMD sich das vorgestellt hat. Mal sehen wie AMD darauf reagiert...
Vega war der erste Schritt mit Infinity Fabric, vielleicht reduziert man künftig die CUs um ein Drittel je Cluster und macht dafür MCMs mit insgesamt ausgewogeneren Chips, für Compute wäre auch denkbar auf Front und Backend ganz zu verzichten, wenn man das nur irgendwie entkoppeln könnte, z.B. wenn der Connect kaum langsamer ist als der Chip selbst, wäre gar eine Modularisierung denkbar. Wer weiss schon wohin die Strategen bei AMD hin wollen, Interconnect und Skalierung für Computecluster sind aber die großen Ziele in der Entwicklung, das sollte man nicht vergessen....

[Screemer]

propritäre api? das ist teil von dx12 und vulkan (https://vulkan.lunarg.com/doc/view/1.0.26.0/linux/vkspec.chunked/ch19s02.html). :facepalm:

[Nightspider]

Dürfte eindeutig daran liegen das AMDs Büros unterbesetzt sind.
Zum Glück dürfen sie jetzt auch wieder massiv einstellen dank steigender Gewinne.

Ärgerlich das man extra ein Feature plant und einbaut und es dann nicht mal genutzt werden kann auf Grund mangelnder Ressourcen.

[Dino-Fossil]

Naja, ursprünglich wurde es ja genau so von AMD angekündigt - hatte mir damals auch nicht viel Hoffnung gemacht, dass man bald viel davon sehen würde, da sich die Entwickler selten wie die hungrigen Wölfe auf solche Features stürzen.

[cat]

@MrSpadge

GCN ist unumstößlich auf 4 Geo-Engines beschränkt, und das ist nicht wegzudiskutieren.

@Thread
Primitive-Shader-Stage muss in vorhandene API integriert werden.

Evtl. war dieser "Optionale-Treiber-Weg" sowas wie die Shader-Instrincts wo die API einen Hardware-Direktzugriff erlaubt, quasi wie einen Bypass an den üblichen Stages vorbei.

Nun ist Vega auf die Gnade der APIs angewiesen, aber immerhin kann der optionale Treiber weg, das spart evtl. Manpower bei AMD, kostet aber Zeit bis zur Verfügung des Features in den APIs.

[pixeljetstream]

propritäre api? das ist teil von dx12 und vulkan (https://vulkan.lunarg.com/doc/view/1.0.26.0/linux/vkspec.chunked/ch19s02.html). :facepalm:
das was AMD bewarb ist ungleich der klassischen pipeline welche du verlinkt hast.

[Screemer]

Sieht so aus bei nochmaligem lesen. Hast du trotzdem nen Link zu mehr Infos? Ließe sich das bei Vulkan über Extensions nachrüsten?

[Hübie]

Guck dir das Vega Whitepaper an. Primitive Shader fasst die Attribut Setups für vertices zusammen statt VS/DS/GS zu instanzieren. Wie genau das geht / abläuft wissen wir mangels praktischen Einsatz ja nicht. Mein laienhaftes Verständnis reicht dafür eh nicht. ;D

[...]full support for primitive shaders will require explicit inclusion in future versions of APIs like Direct3D 12 and Vulkan. Unlike some Vega features, AMD says that "primitive shader support isn't something we can just turn on overnight and it happens," noting instead that it'll need to work with the development community to bring this feature to future API versions.

Quelle (https://techreport.com/news/33153/radeon-rx-vega-primitive-shaders-will-need-api-support)

[pixeljetstream]

Ja extension wäre kein Problem in Vulkan, in DX halt immer gehacke über vendor backdoor apis, weil das ja nativ keinen extension Mechanismus hat.

[cat]

@ Gast Ritis

ich schreibe das mal genauer:
GCN ist beschränkt auf 4 Shader-Arrays und maximal 16CU pro Array,
das ist tiefer Bestandteil der Architektur.

GCN Launch November 2011 HD7970 (2 Arrays)
Hawaii Launch Oktober 2013 290X (4 Arrays)

AMD hat die tolle Skalierbarkeit von GCN in allen Bereichen 2011 noch hoch gepriesen.
2 Jahre später war schon Schluss mit der Geometrie-Skalierbarkeit, abseits von später noch erreichtem Mehrtakt.

AMD steht jetzt seit 4 Jahren vor dieser GCN-Geo-Wall.
Navi ist auchnoch GCN.

AMD kann ohne einen neuen Ansatz im Gaming ohne Primitive-Shader in Zukunft immer weniger reißen.

Mit neuen Game-Engines wird die Menge an Geo deutlich zulegen.

[Gast]

Jene erscheint aus unserer Sicht immer mehr als der Feature-Fix zur Vega-Generation – Navi muß schon kaum eigene Feature mitbringen, sondern sollte zuerst einmal alle Vega-Feature aktiviert an Bord haben. Eventuell ist dies von AMD sogar exakt so geplant, denn üblicherweise schiebt AMD nach einer Grafikchip-Generation mit größeren Änderungen erst einmal ein paar Generationen mit eher kleineren Änderungen ein.

Welche Grafikarchitektur nach GCN hat denn jemals größere Änderungen mitgebracht?

Es sieht mir eher danach aus, dass AMD nach einer Architektur mit großen Änderungen sehr viele weitere Architekturen mit nur jeweils sehr kleinen Änderungen bringt.

[Dino-Fossil]

Ein Versprechen, dass das alles völlig automatisch geht ging doch sicher nie von AMD aus über die offiziellen Kanäle. Das ist doch Wunschdenken von Gamern und zugehörigen "Journalisten" selbst, oder etwa nicht?

Es kam von Rys Sommefeldt ("Game Engineering @ AMD RTG") über Twitter.
Also - wie offiziell man den guten Mann einschätzen will, kann ich dir nicht sagen.
Aber er ist nunmal ein AMD/RTG-Mitarbeiter, der dort im Gaming-Bereich arbeitet, so auf Twitter firmiert und diese Info so rausgehauen hat.
Da gab es zunächst mal keinen Grund, daran zu zweifeln.

[Gast Ritis]

Es kam von Rys Sommefeldt ("Game Engineering @ AMD RTG") über Twitter.
Also - wie offiziell man den guten Mann einschätzen will, kann ich dir nicht sagen...
Vielen Dank für den Hinweis. Von Twitter habe ich noch nie etwas gehalten, spätestens seit Trump sollte klar sein, dass dort kaum ernsthaftes verbreitet wird... und sich frei nach Adenauer kein ***** mehr für das dumme Geschwätz von Gestern interessiert.
Habe mal nachgesehen und das hier gefunden:
https://twitter.com/ryszu/status/896304786307469313
Das war also in der August-Woche nach dem Release eine Unterhaltung mit nem Developer auf seinem privaten Channel der wenige Monate zuvor noch für Imagination Technologies gearbeitet hat....
Nun denn, das White-Paper hat es anders beschrieben und die anderen Devs, die wissen wollten wie es zu nutzen wäre, haben die logischen Fragen gestellt. Der Thread endet auch irgendwie "offen".

So sind sie also, die Quellen des Post Faktischen Zeitalters.

Und heute ist man also "schlauer", dass das Whitepaper nicht falsch lag. Dort haben wahrscheinlich wenigstens zwei Seniors drüber gelesen. Irgendwie Facepalm, Twitter und Co., nicht meine Welt.

[cat]

Für alle die nicht hören wollen was ich schreibe:

https://developer.amd.com/wordpress/media/2017/08/Vega_Shader_ISA_28July2017.pdf
VEGA ISA Whitepaper
This document describes the environment, organization and program state of AMD GCN "VEGA" Generation devices.

APU13 Präsentation
https://image.slidesharecdn.com/gs-4106mah-finalfullversion-140131075645-phpapp01/95/gs4106-the-amd-gcn-architecture-a-crash-course-by-layla-mah-52-638.jpg?cb=1391155201

[Gast Ritis]

Für alle die nicht hören wollen was ich schreibe:

https://developer.amd.com/wordpress/media/2017/08/Vega_Shader_ISA_28July2017.pdf
...

APU13 Präsentation
...[/URL]
Oh man oh man. Die Dokumente und Folien sind doch bekannt. Schön ist an den alten APU Folien, dass die GCN-Arch wie eine Steintafel gemeisselt da steht. Kann schon sein dass nur zwei Bit für Shader Engine Adressierung und 4 Bit für darin enthaltene CUs übrig sind. Bedeutet aber nicht, dass man nicht anders skalieren kann. Einen Weg habe ich genannt. Andererseits, wer weiss denn schon ob die Geometrie Units nicht doch noch weiter aufgebohrt werden könnten auch wenn es am Ende nur logische 4 bleiben. Das weiss nur AMD allein. Dazu muss man aber sicherlich nicht GCN komplett aufgeben, das wäre schon zu merkwürdig...

Die GCN und "Vega" ISA Dokumentationen handeln übrigens nur die Compute Instruktionen ab. Front- und Backend der klassischen Render-Pipeline sind dort nicht dokumentiert. Game-Programmierer sollen ja gegen die APIs programmieren...

Zitat aus der Einleitung:
"It details the instruction set and the microcode formats native to this family of processors that are accessible to programmers and compilers."

Also alles andere ist closed source....und wird nur indirekt via API offen gelegt und vielleicht noch in der OpenSource Treiberentwicklung.

Wenn das anders wäre hätten wir ja schon seit der ersten ISA-Doku perfekte Linux-Treiber gehabt, oder etwa nicht ;)

[yummy_candy]

Darüber gibts zwar nichts offizielles, allerdings sind 4 nicht unbedingt das absolute Limit für GCN.

On a brief aside, the number of compute engines has been an unexpectedly interesting point of discussion over the years. Back in 2013 we learned that the then-current iteration of GCN had a maximum compute engine count of 4, which AMD has stuck to ever since, including the new Vega 10. Which in turn has fostered discussions about scalability in AMD’s designs, and compute/texture-to-ROP ratios.

Talking to AMD’s engineers about the matter, they haven’t taken any steps with Vega to change this. They have made it clear that 4 compute engines is not a fundamental limitation – they know how to build a design with more engines – however to do so would require additional work. In other words, the usual engineering trade-offs apply, with AMD’s engineers focusing on addressing things like HBCC and rasterization as opposed to doing the replumbing necessary for additional compute engines in Vega 10.
https://www.anandtech.com/show/11717/the-amd-radeon-rx-vega-64-and-56-review/2

[Dino-Fossil]

Und heute ist man also "schlauer", dass das Whitepaper nicht falsch lag. Dort haben wahrscheinlich wenigstens zwei Seniors drüber gelesen. Irgendwie Facepalm, Twitter und Co., nicht meine Welt.

Tja, weiß nicht so recht, ob da nur ein Irrtum dahinter steckt:

AMDs letzte Aussage war, der alternative Treiber-Pfad für Primitive Shaders wurde verworfen, stattdessen halt direkt per API via Entwickler ... was wohl noch keiner (in einem bereits veröffentlichtem Spiel) gemacht hat.

Um etwas zu verwerfen, muss man eigentlich erstmal etwas haben (sei es Code oder zumindest eine Idee).
Wie ich bereits irgendwo hier geschrieben habe - ich denke AMD hatte post-Release zeitweise den Plan, das irgendwie per Treiber zu automatisieren, was aber nicht richtig geklappt hat. Deswegen ist man wieder zum ursprünglich angekündigten Vorgehen zurück.

[MrSpadge]

Das trifft es doch sehr gut, yummy: die aktuelle GCN-Architektur sieht maximal 4 Geo-Engines vor. Das zu ändern ist etwas aufwendiger als wenn sie es von vorn herein vorgesehen hätten und deshalb scheuen sie bisher den Aufwand bzw. schätzen den Nutzen als zu gering ein. Aber zu sagen, das ginge gar nicht, ist IMO zu kurz gedacht. Ist dann halt ne neue Version der GCN-Architektur.

MrS

[cat]

AMD hat intern im wesentlichen 2 Stömungen:
Die welche sich seit kurz nach Hawaii bis heute durchsetzt ist dieselbe die aktuell sehr zufrieden ist und wie mir gesagt wurde bei kleinster Kritik sofort mit "Der Rubel rollt, was soll die Frage ?" kontert.
Seit dem Mining-Boom 2015 ist AMD mit dem Weg sehr zufrieden.

Die andere Fraktion sind die Gamer-Focused, diese müssen mit der Situation umgehen und schaffen das mit der Konsolen-Software und deren APIs auch sehr gut.

Raja Koduri hatte "einen Stein im Brett" beim Management weil die Konsolen-Grafik und die Verkäufe diesbezüglich im Semi-Custom so gut laufen.

Deshalb hatte er "ziemlich freie Bahn bei Vega, sofern er den Computing-Part nicht vernachlässigt.

Wo packt Vega an:
Takt, hauptsächlich um die Fixed-Funktion zu beschleunigen, also Geo, Raster, ROP (Fokus Gaming)

** Ihm wurde "verboten" die Shader-Cores langsamer als den Rest des Chips zu takten. ** (AMD Management Fokus-Compute)

Pixel-Engine an L2 (Fokus Gaming)

Primitive-Shader (Fokus Gaming)

DrawStreamBinningRasterizer (Fokus Gaming)

Mehr konnte er unter dem Compute-Fokus von AMD nicht erreichen.
Er hat auch die Aussage nach der ganzen Kritik an der Frontier Edition getroffen, dass Vega nur ein Anfang sei und Navi erst große wirklich stolz machende Änderungen bringe.

Diese Entwicklungseinschränkung und seine eher beiläufig getätigte Aussage Vega vs Navi, die sogar verkaufschädigend für Vega hätte enden können, haben für mich den Weggang von Raja völlig logisch gemacht.

AMD sagt: Raja hätte das nie durchblicken lassen und wäre bis zuletzt positiv gegenüber AMD eingestellt gewesen.

[teetasse]

Was du hier alles raushaust, scheint arg spekulativ zu sein.

Belege?