AMD Radeon Pro Vega 20/16: Vega Mobile steckt in Apples Macbook Pro

Die 330 wurde verändert in Pre-Processing Compute Shader Stage.
Die Aufgabe übernimmt nun der Treiber.
Screenshot (439).png

Ob Vega 10 das beherrscht ist unklar. Das ganze wurde zum heutigen Tag angemeldet.

"[0034] A pre-processing compute shader stage 330 is coupled to the graphics processing pipeline 134. The pre-processing compute shader stage 330 allows computational work to be performed on primitives received from outside of the APD 116 (e.g., from the processor 102) before being processed by the graphics processing pipeline 134. The pre-processing compute shader stage 330 executes pre-processing compute shader programs received from, for example, the processor 102. These pre-processing compute shader programs accept specified inputs, such as primitives or vertices, and produce specified outputs, such as modified primitives or vertices. "
 
Zuletzt bearbeitet:
Es ist unklar, wie irgendein Vega die Technik im Detail umsetzt, entsprechend könnte man sich auch 20 Patente anschauen und keines davon muss die Implementierung der realen Hardware darstellen.
Wer sich mit Treibern im Detail auskennt, kann sich die NGG-Stücke im öffentlichen Vulkan-Treiber anschauen und eine bessere Vorstellung gewinnen.

Aktuell gibt es zwei bzw. wahrscheinlich drei Vega-Chips draußen, Vega10 (GFX900), Raven-Ridge (GFX902) und FireFly in der Subor Z China Konsole, bald erscheint Vega12 (GFX904) und offiziell auch Vega20 (GFX906).
Vega11 gibt bzw. gab es auch mal, aber dieses Projekt wird vermutlich nicht mehr auf den Markt erscheinen.

Im aktuellem Vulkan-Treiber gibt nur wenige Unterschiede zwischen AMDs Vega-GPUs.
Bei keinem ist bisher NGG aktiv oder alternative Pfade für das Geometry-Processing.
 
Es ist unklar, wie irgendein Vega die Technik im Detail umsetzt, entsprechend könnte man sich auch 20 Patente anschauen und keines davon muss die Implementierung der realen Hardware darstellen.
Wer sich mit Treibern im Detail auskennt, kann sich die NGG-Stücke im öffentlichen Vulkan-Treiber anschauen und eine bessere Vorstellung gewinnen.

Aktuell gibt es zwei bzw. wahrscheinlich drei Vega-Chips draußen, Vega10 (GFX900), Raven-Ridge (GFX902) und FireFly in der Subor Z China Konsole, bald erscheint Vega12 (GFX904) und offiziell auch Vega20 (GFX906).
Vega11 gibt bzw. gab es auch mal, aber dieses Projekt wird vermutlich nicht mehr auf den Markt erscheinen.

Im aktuellem Vulkan-Treiber gibt nur wenige Unterschiede zwischen AMDs Vega-GPUs.
Bei keinem ist bisher NGG aktiv oder alternative Pfade für das Geometry-Processing.

Das will ich nicht bestreiten, dennoch auf Basis deiner Analyse hast du folgende Probleme genannt:
Das Problem ist das der Output von den Primitive Assembler groß ausfällt und die Crossbar von jeder World-Space-Pipeline die Geometrie zu den entsprechenden Screen-Space-Pipelines weiterreichen kann, dass bedeutet es gibt viele Verbindungen für den Transport.
Aktuell sind es 4x4-Verbindungen, die weitere Skalierung davon erscheint entsprechend kostspielig und ungünstig, da der Aufwand quadratisch zunimmt, wenn man nach wie vor einen gleichmäßigen Austausch gewährleisten möchte.

Ein anderes Problem ist das man effektiv die API-Regeln befolgen muss, dass heißt das erste Dreieck was reinkommt, muss auch als erstes raus, wobei man zwischenzeitlich Out-of-Order arbeiten kann, aber allgemein kann folgendes auftreten; mehrere Dreiecke überlappen mehrere Screen-Tiles und müssen von mehreren Screen-Space-Pipelines berechnet werden.
Nun kommt es vor das die Arbeitslast nicht identisch zwischen den Screen-Space-Pipelines ausfällt.
Wird eine Screen-Space-Pipeline stärker belastet bzw. müssen dort mehr Daten in den Buffer geschrieben werden, kann der zuerst volllaufen.
Ist der Buffer voll, kann die Screen-Space-Pipeline keine weitere Arbeit mehr entgegen nehmen und wenn ein Dreieck von mehreren Screen-Space-Pipelines bearbeitet werden muss, dann muss jede andere Screen-Space-Pipeline auf die warten die gerade voll ist.

Problem 1: Die World-Space-Pipeline fällt komplett weg, das übernimmt nun die pre-processing compute shader stage. Nach vorheriger Verarbeitung(Culling, offenbar Treiber mit Berechnung der CPU) wird weitergeleitet.
Problem 2: Entfällt nun wahrscheinlich, siehe folgendes
" [0035] One use for the pre-processing compute shader stage 330 is to perform culling. Culling involves removing elements that will not significantly impact the final rendered scene. Elements outside of the view frustum (i.e., the 3D portion of space that can be viewed by the view camera for which rendering is being performed) are removed in a process referred to as frustum culling. Elements that are invisible to the camera because the "back" face of such elements face the camera are removed in a process referred to as "back-face culling." Elements that are blocked or "occluded" by other elements and are therefore not visible in the rendered scene are removed in a process referred to as occlusion culling. Elements that are too small to be visible in the rendered scene (e.g., primitives that are so small that the primitives do not "cover" any pixel sample) are removed in a process referred to as small primitive culling. Other types of culling operations are known in the art as well. The preprocessing computer shader stage 330 operates in an "asynchronous" manner

with respect to the rest of the graphics processing pipeline 134, in that the graphics processing pipeline 134 can process data (e.g., culled primitives) as soon as such processed data has been processed by the compute shader stage 330. "


Die API bestimmt also nicht mehr die Regeln, da das Culling bereits vorher bestimmt was in die Pipeline kommt.Der Rest wird auf zwei Ebenen vorgehalten.Belastet aber nicht mehr aktiv Pipeline.
Ein schönes Beispiel hierzu wäre FFXV, das sinnlose Sachen berechnet in seinem Benchmark.
 
Ugh, Patente lesen macht mir keinen Spaß, kostet viel Zeit, ist unübersichtlich, definiert jedes mal Krimskrams und wiederholt sich gerne.
Die Zielsetzung und teilweise die Umsetzung ist ähnlich zu dem Patent Primitive Shader.
Hier erzeugt der Treiber auf Basis vom Vertex-Shader unterschiedliche Ausführungsprogramme, welche die Compute-Units berechnen und unnötige Geometrie rausfiltern, die Ergebnisse werden in einen Buffer geschrieben, aus dem die Grafikpipeline liest und somit keine unnötigen Berechnungen ausführt.

Bei den Primitive Shadern muss natürlich auch der Treiber das entsprechende Programm erzeugen, hier culled die Grafikpipeline am Anfang die Geometrie und verarbeitet auch nicht weiter unnötige Geometrie.
Dort wird aber noch mehr in Bezug auf die High-Level-Umsetzung beschrieben und wie der Rest der GPU aufgebaut ist.

An die API-Regeln muss man sich aber immer halten, bis zudem Punkt, ab welchem man noch API-Konform ist und keine Bildfehler auftauchen.
Auch aktuell culled AMDs/Nvidias Hardware über Fixed-Function-Einheiten unnötige Geometrie und der Rasterization-Vorgang geschieht später auch nicht strikt In-Order, sondern kann zwischenzeitlich Out-of-Order ausgeführt werden, aber der Output muss sich an die Reihenfolge halten, wie der Input sie eingeschoben hat.
 
Da kommt nix mehr mit PS für die alten Vegas. Das Treiberteam dürfte längst mit der Arbeit für die 7nm Chips ausgelastet sein.

Genauso könnte man drauf warten, dass AC nochmal anständig auf Pascal läuft, obwohl das Problem inzwischen mit Turing gefixt wurde.

Was Treiberunterstützung älterer Karten angeht ist AMD aber doch ein anderes Kaliber als Nvidia.
 
Das hat nichts mit Schlechtreden zu tun.
Die einzige GPU welche Ende 2018 erscheinen soll und das eig. nur für Enterprise-Kunden ist Vega20, welcher unter 7nm hergestellt wird, bis zu vier HBM2-Stacks bietet und laut Leaks weiterhin nur 4096 ALUs.

Wenn AMD V20 für Konsumenten bringen würde, haben sie was davon einen 7nm Chip mit HBM2-Speicher für 399€ zu verkaufen?
Sicherlich keine guten Finanzen.
 
Das hat nichts mit Schlechtreden zu tun.
Die einzige GPU welche Ende 2018 erscheinen soll und das eig. nur für Enterprise-Kunden ist Vega20, welcher unter 7nm hergestellt wird, bis zu vier HBM2-Stacks bietet und laut Leaks weiterhin nur 4096 ALUs.

Wenn AMD V20 für Konsumenten bringen würde, haben sie was davon einen 7nm Chip mit HBM2-Speicher für 399€ zu verkaufen?
Sicherlich keine guten Finanzen.

Er bezieht die Preise auf V56/64, nicht auf V20!
Naja betreiben wir kein unnötiges Schattenboxen hier, kommt Zeit kommt Rat.
 
Er bezieht die Preise auf V56/64, nicht auf V20!
Naja betreiben wir kein unnötiges Schattenboxen hier, kommt Zeit kommt Rat.
Er sprach von 2070/2080-Leistung (-5-10%) für 399/499€ und hat auf das Event verwiesen, wo AMD ausführlich über 7nm Produkte sprechen möchte.
Eine V64 ist im CB-Index 25-27% langsamer, als eine 2080FE und eine V56 18% langsamer, als eine 2070 Turbo.
Nvidia GeForce RTX 2070 im Test (Seite 3) - ComputerBase

Eine V56 kostet bei Mindfactory >399€, eine V64 >470€.
Die einzige Möglichkeit für V10, um den Wunsch zu erfüllen, wäre spekulativ ein 12nm Refreshe von V10, damit der Abstand ungefähr dort liegt, wo man es möchte.
 
Achja stimmt...
Bin schon sehr auf das Horizon-Event gespannt, die Katze aus dem Sack, Primitive Shader, 399€ und so weiter...
 
Ist doch konservativ. Sagen wir 10% durch die Primitiveshader und 20% Takt und man ist an der 2080er locker flockig vorbei.
 
Die 7nm Karten sicherlich, aber dies dauert noch gute 8 Monate!
Dafür muss Vega 56 / 64 herhalten und zum guten Preis echt eine Alternative, zudem die NV Karten derzeit andere Probleme bereiten!
20% schneller und man ist knapp drann,- bei Neuen Games wohl fast Gleichstand.
 
"After generating the automatically generated shader programs, the software module transmits the automatically generated shader programs to the graphics processing pipeline for execution. These shader programs process primitives received from the host CPU for processing by the graphics processing pipeline and thus act as a sort of “front end filter” for the graphics pipeline. After culling primitives, the automatically generated shader programs output culled primitives to the remainder of the graphics processing pipeline. The graphics processing pipeline thus avoids processing primitives that are culled by the shader programs, reducing the amount of work to be performed by the graphics processing pipeline and improving performance of the graphics processing pipeline."
 
Hier gehts um den DSBR, welcher bisher per default deaktiviert war und APP spezifisch aktiviert werden musste. Denn er konnte die Performance auch negativ beeinflussen,
Nun hat sich wohl gezeigt, dass inzwischen die meisten/populärsten Vulkan Titel unter Linux vom primitive binning profitieren, so dass es ab sofort per default aktiv ist im Treiber.
 
Zurück