AMD RX VEGA Laberthread

Die entscheidende Änderung ist in meinen Augen das der Treiber nun die primitives generieren kann und zwar ausdrücklich automatisch und mit jedem Input.
 
Die entscheidende Änderung ist in meinen Augen das der Treiber nun die primitives generieren kann und zwar ausdrücklich automatisch und mit jedem Input.

Ne^^ Leider nicht. Der Treiber kann jetzt Primitive Culling machen. Stell's dir so vor, du hast eine Szene mit mehreren Objekten. Die Karte bricht die Objekte in Primitives runter um zumindest grob die Pixel zu finden an denen Objekte voneinander verdeckt werden um genau die dann zu verwerfen. Das spart Arbeit weil die Pixel dann nicht gerendert werden müssen.
Culling ist ja im Endeffekt nur ein Feature das erlaubt nicht sichtbare Bereiche nicht mit zu Rendern. Es gibt Beispielsweise Backface Culling. Da werden alle Vertices auf der Rückseite deines Objekts verworfen nachdem man die eh nicht Rendern muss. Der Vorteil am Primitive Culling ist, dass das sehr früh passiert und dass Verdeckungsberechnungen mit Primitives vergleichsweise einfach sind. (Deswegen sind Collider oft aus Primitives gebaut). Sprich es wird einfach schon viel vorne weg genommen.

Und das Primitive Culling wurde im Endeffekt im Vulkan Treiber jetzt aktiviert.

Der Primitive Shader erlaubt es Teile der Primitive Pipeline parallel zu nutzen weil damit verschiedene Operationen zusammengefasst werden. Dadurch würde der Durchsatz drastisch erhöht und die Pipeline besser ausgelastet. Die Primitive Pipeline macht nämlich noch etwas mehr als eben nur das Primitive Culling. Aber das Zusammenfassen funktioniert eben nicht aus irgend einem Grund.
 
Ich Tippe mal die Führungsriege hat von Raja ein: "in der Theorie läufts" bekommen und daraufhin Resourcen umgemodelt . .

Ich tippe auch mal..
Ryzen war als Umsatzträger wichtiger. Ob der Indianer was gedacht hat oder nur seine unteren Kasten beaufsichtigt , who knows.
Als richtiger Nerd hätte der Indianer die wichtigsten Teile höchstselbig programmiert. Er ist nach m.E. vollkommen überbewertet.
Gut , das jetzt ne mehrköpfige Truppe mit erfahrenen Leuten bei Radeon dran ist. Mit dem besseren finanziellen Stand sollte wieder mehr gehen, was dann halt Zeit in der Entwicklung braucht.
Reicht mir persönlich wenn 2020/21 zusammen mit DDR5+XGMI was fürs obere Highend kommt.(für meinen nächsten Fertig-PC)
 
Er ist nach m.E. vollkommen überbewertet.

Ich glaube tatsächlich das Raja Koduri richtig was auf dem Kasten hat, aber einfach nicht die Resourcen hatte. Es gibt schon nen Grund warum Intel ihn "abgeworben" hat. Ich könnte mir vorstellen, dass er aufgrund von aus seiner Sicht fragwürdigen Entscheidungen zur Projektpriorität gegangen ist. Ich denke nämlich nicht, dass er "gegangen wurde", anders als der AMD Marketing-Chef xD Wir stecken nicht drinnen, sprich das von außen zu beurteilen ist immer schwierig. Ich hab aber auch das Gefühl, dass AMD nach Rajas Abgang den Knall gehört haben. Die haben das Optimierungsteam, das Treiberteam und die Projektleitung aufgestockt. Das klingt für mich vielversprechend.
 
Das mit dem größeren Team und speziellen Leadern in den einzelnen Bereichen wird sicherlich/hoffentlich auch die schnellere Produktreife bringen. Das Tic Tac Tac für 590 ist OK.
btw.
Es gibt andere Entwickler, die erst den Compiler schreiben, und dann die Hardware bauen.
(Einer der nach 2 Jahren überrascht ist kann ja wohl net der Überflieger sein; bei Intel darf Jeder mal)
 
Das mit dem größeren Team und speziellen Leadern in den einzelnen Bereichen wird sicherlich/hoffentlich auch die schnellere Produktreife bringen. Das Tic Tac Tac für 590 ist OK.
btw.
Es gibt andere Entwickler, die erst den Compiler schreiben, und dann die Hardware bauen.
(Einer der nach 2 Jahren überrascht ist kann ja wohl net der Überflieger sein; bei Intel darf Jeder mal)

Im GPU-Bereich ist das nicht so einfach. Außerdem bringt dir der Compiler in dem Falle nichts wenn die Pipeline fehlerhaft ist. Vielleicht ist der Compiler fertig, die Pipeline kann damit aber nicht viel anfangen weil sie hängen bleibt. Wie gesagt. Ich würde mir kein eindeutiges Urteil erlauben. Ich war nicht dabei, ich kann nur Annahmen treffen.

Auf bessere Release-Produktreife hoffe ich auch. Fine-Wine war ein netter Gag. Langsam isses aber gut.
 
Ich tendiere mittlerweile zu Vega 56 und habe mich auf die Nitro eingeschossen. Vorhin habe ich aber gelesen, dass die "normale" Nitro gar keine Vapor Chamber hat sondern nur die limited edition. Die Tests im Netz beziehen sich wohl auf die Version mit Vapor Chamber. Ist die Karte ohne Vapor Chamber auch noch gut oder zu teuer für die (Kühl)Leistung? Ich suche ein Customdesign mit sehr geringer Lautstärke und relativ geringem Verbrauch. Leichte Performanceverluste nehme ich dafür in Kauf, also sind mir die letzten FPS nicht so wichtig. Sind die Red Devil oder Red Dragon dafür geeignet? Was ist mit der Pulse? Oder vielleicht doch Asus? Vega 64 ist schwerer zu bändigen oder?
 
Ich tendiere mittlerweile zu Vega 56 und habe mich auf die Nitro eingeschossen. Vorhin habe ich aber gelesen, dass die "normale" Nitro gar keine Vapor Chamber hat sondern nur die limited edition. Die Tests im Netz beziehen sich wohl auf die Version mit Vapor Chamber. Ist die Karte ohne Vapor Chamber auch noch gut oder zu teuer für die (Kühl)Leistung? Ich suche ein Customdesign mit sehr geringer Lautstärke und relativ geringem Verbrauch. Leichte Performanceverluste nehme ich dafür in Kauf, also sind mir die letzten FPS nicht so wichtig. Sind die Red Devil oder Red Dragon dafür geeignet? Was ist mit der Pulse? Oder vielleicht doch Asus? Vega 64 ist schwerer zu bändigen oder?

Ne Vega 64 bekommst du genauso gebändigt. Ne Red Devil oder Nitro+ ist ne solide Karte und auch nicht so laut/heiß. Zieht halt gut Strom das Ding. (Mein Bruder hat ne Vega 64 Nitro+.) Geringer Verbrauch und Vega ist so eine Sache. Mit Undervolten geht einiges, aber ob man das dann als "sparsam" sieht muss man selbst wissen^^ An der Stelle mit dem Undervolting verweiße ich dich an unseren weisen Gurdi, der kennt sich da aus. Grundsätzlich sind bei den 56 finde ich die Red Devil, Red Dragon und Nitro alle sehr gut wobei die Nitro genau wie bei der Vega 64 einfach die beste Vega ist (nach meiner Meinung).

Dann sieht man eher den Zusammenhang. Kann etwas dauern, hänge im Kreissaal rum und darf mich aktuell anfauchen lasse.:)

Glückwunsch, ich hoffe alles verläuft gut und planmäßig ;)
 
Zuletzt bearbeitet von einem Moderator:
Ne Vega 64 bekommst du genauso gebändigt. Ne Red Devil oder Nitro+ ist ne solide Karte und auch nicht so laut/heiß. Zieht halt gut Strom das Ding. (Mein Bruder hat ne Vega 64 Nitro+.) Geringer Verbrauch und Vega ist so eine Sache. Mit Undervolten geht einiges, aber ob man das dann als "sparsam" sieht muss man selbst wissen^^ An der Stelle mit dem Undervolting verweiße ich dich an unseren weisen Gurdi, der kennt sich da aus. Grundsätzlich sind bei den 56 finde ich die Red Devil, Red Dragon und Nitro alle sehr gut wobei die Nitro genau wie bei der Vega 64 einfach die beste Vega ist (nach meiner Meinung).
Ich meinte natürlich geringen Verbrauch für Vega-Karten. :) Da dachte ich an 200 bis 220 Watt. An Nvidia kommt AMD momentan leider nicht ran, was den Verbrauch angeht. Da mache ich mir keine Illusionen. :D

Glückwunsch Gurdi! :)
 
Ich meinte natürlich geringen Verbrauch für Vega-Karten. :) Da dachte ich an 200 bis 220 Watt. An Nvidia kommt AMD momentan leider nicht ran, was den Verbrauch angeht. Da mache ich mir keine Illusionen. :D

Glückwunsch Gurdi! :)

Na die Vega 56 mit Stromsparbios, RadeonChill, undervolting+OC kommt schon an Nvidia 1070ti / 1080 ran. 10 bis 20 Watt mehrverbrauch ist dabei eigentlich wurscht. Das brauchen die NV Karten dann ja auch mehr, wenn man sie "optimiert". Die Vega sind schon echt flexible Karten wenn man das so betrachtet.

Generell gefällt mir die Red Dragon am Besten was Lautstärke, Stromverbrauch und Bastelmöglichkeiten betrifft.
 
Nun, wo ist der Böse ATI_R290
[...]
Zitat:
aktuell gibt es keinen Termin, aber der Treiber wäre theoretisch soweit fertig. Der PS wie er ursprünglich angekündigt war ist leider begraben und vergessen, dafür gibt es aber etwas andereres für was sich die PS und die Vega Rohleistung nutzen läßt.
nur gibt es leider aktuell noch keine Anpassungen an die Spiele. Allerdings sollen dieses Jahr noch 2 Patches rauskommen. Erste Spiele wird Wolfenstein colossus ( 11-22% + je nach Auflösung ) und shadow of the tomb raider ( je nach Config bis zu 46% )

@edit

Dies gerade bei Guru3D auch gefunden:

**We will have A.I. managed - Draw Stream Binning Rasterizer in December Driver Big update >18.12.1<
I think it will uplift Vega uArch performance by additional 20-30% (conservative prognosis)
Genau da ist der böse ATI_R290 wieder, mit puren Blödsinn aus der Hölle.

DSBR ist das AMD- Pendant zu TBR von NV. ( mehrere Quadranten vs. TileBaseRendering über den kompletten Bildschirm)
edit: Falls DSBR für Linux erst jetzt freigegeben wurde, hängt man da ganz schön hinterher. (bringt lt. lnk 1..2%)
Das DSBR soll vor allem Speicher sparen und mehr im Cache erledigen. Würde nur bei HBM-Bottleneck fps bringen.
Wird deswegen von Game zu Game entschieden ob im Treiber aktiv.
(im Anhang die theoretische Einsparung)

DSBR ist theoretisch seit Vega-Launch für die meisten Games aktiv. (ob dann 18/12 mehr geht, who knows)
Der schlechte Wert in RoTR spricht Bände, wieviel noch brach liegt. (ob bei GW jemals Alles funzt bezweifele ich)
RADV ist ein offener Vulkan-Treiber für Radeon-GPUs, mit dem AMD selber aber nichts am Hut hat, denn er wird von AMD unabhängigen Entwicklern geschrieben, welche auch gar nicht im Auftrag von AMD stehen.
Anders als beim offenen RadeonSI-Treiber, wo AMD abhängige und unabhängige Mitarbeiter arbeiten.
Bei Vulkan hat AMD ihren eigenen offenen und geschlossenen AMDVLK (Pro)-Treiber, woran die AMD-Mitarbeiter arbeiten.
Dort weiß ich aber nicht, ob AMD den DSBR schon verwendet, RadeonSI (offener OGL-Treiber) verwendet den DSBR für Raven-Ridge, bei Vega10 wurde er später deaktiviert, ich habe nicht nachverfolgt, ob sie das wieder aktiviert haben.


Der DSBR ist aber teil der neuen Primitive Pipeline. Der verwirft ja Primitives. Das ist ja der Witz, jetzt mal sehr stark vereinfacht und damit nur semikorrekt: In der Primitive Pipeline werden die Sachen auf Primitives runtergebrochen. Wenn er ein Primitive findet kann er einen Teil der Pixel verwerfen nachdem die eh nicht sichtbar sind. Das spart Renderarbeit. Mit der Art von Culling an so einem frühen Punkt spart man sich einige Berechnungen.

Mal für dich aus dem Vega Whitepaper:

"Standard immediate-mode rendering works by rasterizing
each polygon as it is submitted until the whole scene is
complete, whereas tiled rendering works by dividing the
screen into a grid of tiles and then rendering each tile
independently.
The DSBR works by first dividing the image to be rendered
into a grid of bins or tiles in screen space and then
collecting a batch of primitives to be rasterized in the scan
converter. The bin and batch sizes can be adjusted
dynamically to optimize for the content being rendered.
The DSBR then traverses the batched primitives one bin at
a time, determining which ones are fully or partially
covered by the bin. Geometry is processed once, requiring
one clock cycle per primitive in the pipeline. There are no
restrictions on when binning can be enabled, and it is fully
compatible with tessellation and geometry shading. (“Vega”
10 has four front-ends in all, each with its own rasterizer.)"

Quelle: https://radeon.com/_downloads/vega-whitepaper-11.6.17.pdf

Also der hat schon was mit der Primitive Pipeline zu tun.
Zusammenhängend mit den anderen Beiträgen, der DSBR selber verwirft keine Geometrie.
Anstatt das ganze Bild zu rastern und immer über den VRAM zu gehen wird beim DSBR das Bild in kleinere Kacheln (Tiles) aufgeteilt und per Kachel gerastert, dass ist energieeffizienter und spart externe Bandbreite, da der Vorgang on Chip im L2$ erfolgt, ebenso kann der DSBR Pixel verwerfen und damit Pixel-Shading sparen, für Pixel die bei der finalen Szene sowieso nicht sichtbar sind.
Bezüglich der Geometrieverarbeitung und Culling kümmern sich nach wie vor die klassischen fixed-function Geometry-Engines, wo Primitive-Shader deren Aufgabe stattdessen übernehmen hätten können.
 
Zuletzt bearbeitet:
...der DSBR selber verwirft keine Geometrie.
Anstatt das ganze Bild zu rastern und immer über den VRAM zu gehen wird beim DSBR das Bild in kleinere Kacheln (Teiles) aufgeteilt und per Kachel gerastert, dass ist energieeffizienter und spart externe Bandbreite, da der Vorgang on Chip im L2$ erfolgt, ebenso kann der DSBR Pixel verwerfen und Pixel-Shading sparen, für Pixel die bei der finalen Szene sowieso nicht sichtbar sind.
Bezüglich der Geometrieverarbeitung und Culling kümmern sich nach wie vor die klassischen fixed-function Geometry-Engines, wo Primitive-Shader deren Aufgabe stattdessen übernehmen hätten können.

Ah ok, ich hatte das schon so verstanden, dass in dem Schritt das Primitives-Verwerfen passiert, aber danke für die Klarstellung. Allerdings steht ja drinnen, dass der sich Primitives sucht. (...The DSBR works by first dividing the image to be rendered into a grid of bins or tiles in screen space and then collecting a batch of primitives...The DSBR then traverses the batched primitives one bin at a time, determining which ones are fully or partially covered by the bin)

Dementsprechend hatte ich das mit dem Culling schon so verstanden und bin auch davon ausgegangen, dass das in dem Schritt mitläuft. (Lass mich aber natürlich gerne belehren). Primitive Culling ist ja eigentlich auch der Schritt der nach dem Primitive Shader passieren würde. Wobei ich dachte, dass das immernoch zur NGG gehört. Oder ist der DSBR dann erst in nem Schritt danach (also nach dem Primitive Binning) oder etwa schon davor?

Der Primitive Shader kann doch nur die Reihenfolge asynchron machen so wie ich das verstanden hab? Also so dass die verschiedenen Unterschritte teils out of order passieren können indem er Aufrufe zusammenfasst?

Viele Fragen, ich weiß aber ich dachte eigentlich das ich das konzeptionell richtig aufgenommen hatte...^^

Hab hier mal 2 Teile aus 2 Diagrammen aus dem Vega Paper:
Shadingpcgh.png
Links ist aus dem NGG Teil aus dem Dokument mit in sich links der klassischen Geometrieverarbeitung und rechts der neuen mit Primitive Shaders und rechts einem Auszug aus dem Architekturdiagramm. Ich hatte die Unterteilung immer so verstanden. Gehört der Tesselator dann auch in die Geometry-Engine?
 
Zuletzt bearbeitet von einem Moderator:
Zusammenhängend mit den anderen Beiträgen, der DSBR selber verwirft keine Geometrie.
Anstatt das ganze Bild zu rastern und immer über den VRAM zu gehen wird beim DSBR das Bild in kleinere Kacheln (Tiles) aufgeteilt und per Kachel gerastert, dass ist energieeffizienter und spart externe Bandbreite, da der Vorgang on Chip im L2$ erfolgt, ebenso kann der DSBR Pixel verwerfen und damit Pixel-Shading sparen, für Pixel die bei der finalen Szene sowieso nicht sichtbar sind.
Bezüglich der Geometrieverarbeitung und Culling kümmern sich nach wie vor die klassischen fixed-function Geometry-Engines, wo Primitive-Shader deren Aufgabe stattdessen übernehmen hätten können.


Das liest sich im White paper aber anders
Even larger performance improvements are possible when
developers submit geometry in a way that maintains screen
space locality or in cases where many large overlapping
polygons need to be rendered. For example, performance
more than doubles in one professional graphics workload, the
energy01 test in SPECviewperf ®
12, thanks to the DSBR.

Man spart ja gerade Bandbreite weil nicht jedes Polygon im Rasterizer verwendet wird.
 
Zurück