VEGA (Vega10, Vega11, Vega12, Vega20) - 2017

[basix]

die bandbreiteneffizienz einer grafikkarte ist genaugenommen egal, solange leistung, effizienz und preis passen.

Jein. =)

Ich stimme dir grundsätzlich zu. Aber wenn die Bandbreiteneffizienz steigt, bleibt dementsprechend mehr übrig für andere Sachen. Zum Beispiel mehr Power Budget = höhere Taktraten. Oder geringere Bandbreite nötig = 1 HBM Stack weniger = kosteneffizienter. Natürlich kann man das mit deinem Argument erschlagen, die Metriken "passen" ja. Weniger Ressourcen für mehr ist aber definitv immer vorteilhaft. Vor allem würde eine bessere Bandbreiteneffizienz auch günstigere GDDR5(X) Karten mit nicht allzu breiten Bussen und ohne Banbreitenlimitierung zulassen. Die RX480 ist zum Teil schon stark bandbreitenlimitiert und das trotz 8 Gbit Speicher. Das macht Pascal schon besser und ist mit ein Grund, wieso Pascal so effizient ist. Datenmovement zum VRAM und auf dem Chip selber benötigen zigfach mehr Energie als die eigentlichen Berechnungen. Das ist auch der Grund, weshalb alle namhaften Hersteller in diese Richtung forschen (Stichworte Memorywall, Datenlokalität und PIM oder Processing In Memory). HBM ist ja schon der erste Schritt dazu im Vergleich zu GDDR.

[Korvaun]

VEGA sollte doch wohl alle(?) Neuerungen haben die auch mit der PS4Pro eingeführt wurden. Also z.b. FP16 und der ganze In-Hardware-Scaling-Kram?

[Dorn]

Also so wie ihr dies seht sollte Vega dann in 2 unterschiedlichen Versionen und Preisgefügen kommen:
1x Vega für GTX 1080 als Konkurrent
1x Vega nochmals über einer Titan X (Pascal)
Vega klein mit 8 GB HBM-2 und der Große Vega gar mit 16GB HBM-2

Jener wird sich mit Titan X Pascal und der GTX 1080 TI messen müssen...
Ich gehe mittlerweile davon aus, das sich Vega gegen Pascal refresh behaupten muss.

[dargo]

Was für ein Pascal Refresh? Die GTX1080TI ist noch gar nicht released worden. Ganz einfach weil NV damit auf Vega wartet.

[robbitop]

Und wie kommst du darauf? Die Titan X kommt ohne HBM auf 480GB/s. Da sind die ~7% mehr von Vega quasi nichts.

Für den Fall, dass Vega deutlich langsamer ist als Titan XP (also eher 1080 Niveau +/-10%), wäre es schon signifikant. Bis dato kommt NVs mArch mit deutlich weniger Bandbreite aus (bessere ddc und defered rasterizing) - hier sollte AMD unbedingt aufschließen. HBM scheint noch teuer und begrenzt lieferfähig zu sein. Ob GDDR5(X) nicht in dieser Hinsicht die bessere Wahl gewesen wäre? Man kann nur hoffen, dass Sich das bei HBM schnwll ändert.

[Nakai]

@ Nakai
in dem Patent steht nichts drin was AMD aktuell schon in Polaris nutzt.
Derweil kann aber der neue Work-Distributor der PS4 Pro schon Richtung Teile des Patents weisen.
Genauso wie die FP16-Double-Speed-Fähigkeit der PS4 Pro
beides wurde von AMD als Vega bzw. "neuer als Polaris" bezeichnet.

Wenn das ein oder andere Beispiel in der Patentschrift nicht überspitzt darstellt, sondern eher Normalfälle erklärt was die vormals verschwendete Energie angeht.

genannte Beispiele:

8-Thread-Wavefront statt 64er auf Vec-4-ALU statt Vec-16-ALU
shows how an eight thread wide wavefront can be executed over two cycles on a four thread wide GPU microarchitecture

Generell kleinere Wavefronts
16-Thread auf Vec-4-ALU statt 64-Thread mit Datenleichen, kleine Wavefronts mit Skalar-Power-Boosten

If a wavefront has 64 threads (but only 16 active threads), instead of scheduling the wavefront to a 16 thread wide SIMD unit, the wavefront may be scheduled to a four thread wide SIMD unit

nochmal Skalar-Boost

Energie-Effizienz
This approach also works well with branch divergence in a wavefront. Because of branch divergence, some threads follow a control flow path, and other threads will not follow the control flow path, which means that many threads are predicated off. When it is determined that the active threads can be run in a smaller width SIMD unit, then the threads will be moved to the smaller width SIMD unit, and any unused SIMD units will not be powered up.

nochmal sehr deutlich, eine Wavefront wird immer mit 4-Taktzyklen angegeben, mit Ausnahmen bei den Skalar-Einheiten, es kann also bisher auf einer zu großen SIMD passieren das Takt1+2 brauchbar und Takt3+4 unbrauchbar Energie benötigen.

nochmal Vec-4 Einheit und Clock-Boost

Kombination kleiner SIMD zu einer großen Vec-16 SIMD

HIER das beste Bild ohne Bild
statt (4x Vec-16-SIMD)= 64 + 1x Skalar
(3x Vec-16 + 4x Vec-4)= 64 + 4x Skalar

For instance, if the number of active threads in a wavefront is very small (for example, one or two), the threads may be dispatched to the high-performance scalar unit, where the instruction will complete in only a couple of cycles.

Vec-4 mit 16-Taktzyklen statt Vec-16 mit 4-Taktzyklen wenn Memorybackpressure

Totalumbau der CU und der Front-Ends
Current GPUs (for example, as shown in FIG. 3) are designed with a 16 thread wide SIMD unit, and there may be multiple front-ends (multiple issue units) sharing multiple back-end units. The design may be modified to include N issue units that share M SIMD units, and those SIMD units may be of different thread widths.

Und dann folgen massig bestätigungen der brutal erhöhten Hardware-Autonomie
ähnlich nVidia etwas wie Betriebssystem-Agnostic und Hardware-Auto-Ballancing über etwas das der Nachfolger der HWS Hardware-Scheduler von Polaris sein könnte.

DAS wäre die Grundlage GCN durch den Namen NCU zu ersetzen,
das die Instinct-Karten mit Fiji-Treiber laufen kann dann zusätzlich die evtl. volle Software-Kompatiblität bestätigen, evtl. NOCH mit weniger HW-Autonomie und höherer Treiberlast, mit neuem Treiber wird dann der Geist aus der Flasche gelassen.

@Cat:
Ich bin da ganz bei dir. Ich hab das Patent schon vor Monaten/Jahren gelesen. Ich finde es auch gut, dass es auch mal jemand anderes als ich hier anspricht. :)

"Großmeister" Gipsel hat jedoch schon ein paar Probleme angesprochen, diesbezüglich. Ich zitiere es aus dem Patent:

[0032] If a wavefront has 64 threads (but only 16 active threads), instead of scheduling the wavefront to a 16 thread wide SIMD unit, the wavefront may be scheduled to a four thread wide SIMD unit. Based on demand (a need basis), the scheduler determines whether to schedule the wavefront to all four thread wide SIMD units or just to a subset of the SIMD units. The threads migrating between these functional units can have their context (register values) migrated with the help of software (using "spill" and "fill" instructions) or with dedicated hardware that helps the migration. Alternately, only the data needed for the upcoming instruction or instructions can be forwarded along with the work through a register-functional unit crossbar or other interconnection. This determination provides a finer granularity control over how the threads are executed. By dispatching work to a narrower vector unit compared to the baseline wide vector unit, it is possible to execute only as many threads as will actually produce results, thereby saving power.

Es ist manchmal nicht ersichtlich, ab wann es Sinn macht eine Wavefront auf eine bestimmte SIMD-Einheit zu schedulen. Oftmal kann es passieren, dass während die Wavefront läuft, immer mehr Work-Items ausmaskiert werden, ergo es Sinn macht, diese Wavefront auf eine andere SIMD-Einheit zu schubsen. Das Problem ist der Overhead diesbezüglich. Daten von einer Registerfile in eine andere zu schieben, ist aufwendig. Das kann GCN derzeit auch schon, aber nur im kleinen Umfeld. Besser wäre eine globale Registerfile (*hust*), dann würde dieses Problem entfallen. Die zugrundeliegende Verdrahtungslogik schaut dafür natürlich nicht sehr nett aus.

Ich sehe das Patent nur als Wegweiser. Hierzu ein netter Einfall. Was wäre wenn AMD richtigen FP16-Support bringen würde? Ergo wirklichen Faktor 2? Ergo eine FP32-SIMD8 verhält sich wie eine richtige FP16-SIMD16?

[tm0975]

wieviel ist denn titan xp - (1080 +10%)? 10, 12%? sofern das zusammenbasteln auf dem interposer mir geringem aufwand und hoher zuverlässigkeit erfolgt, sehe ich rosige zeiten für HBM. dann wird es hbm in 2 jahren auch im mainstrean geben. der preis ist nur solange ein problem, wie die stückzahlen gering sind.

[robbitop]

TXP liegt out of the box 25-30% vor einer FE 1080. Txp hat halt sehr niedrige out of the box Taktraten. Aber jeder weiß, dass die auf 2 GHz geht. Also +30%. Und er verhungert auch da nicht an der Bandbreite. Hoffentlich hat Vega auch halbwegs entsprechende Reserven.

[dargo]

Für den Fall, dass Vega deutlich langsamer ist als Titan XP (also eher 1080 Niveau +/-10%), wäre es schon signifikant.
Mit 12 TFLOPs gehe ich nicht davon aus.

btw.
Deine +/-10% auf GTX1080 finde ich schon etwa putzig. :tongue: Wenn Vega 10% über der GTX1080 liegt fehlen nur noch 11% auf Titan X.

Edit:
Kleine Rechenaufgabe...

Referenz P10 vs. Referenz GP106 trennen 15% Rohleistung. Du kannst mir gerne erklären warum AMD bei Vega plötzlich 33% mehr TFLOPs gegenüber Pascal braucht wo P10 eher ein kleiner Schritt nach vorne war. In dem Fall wäre die IPC bei Vega wesentlich schlechter gegenüber Polaris. :tongue: Die 33% beziehen sich natürlich nur auf den Fall wenn die 1,5Ghz gehalten werden. Ansonsten etwas weniger.

TXP liegt out of the box 25-30% vor einer FE 1080.
Wie soll das denn gehen? Es sind 11 TFLOPs vs. 9 TFLOPs. Also max. 22%. Wenn es irgendwo im Spiel XY etwas mehr ist dann verhungert GP104 entweder an der Bandbreite oder die Boosttaktraten variieren etwas.

[robbitop]

Du vergisst, dass TXP noch locker 30% Taktreserve hat. Eine Reserve, die jeder TXP Käufer kennt und nutzt.

GP106 ist in etwa 5% schneller im Performance Rating bei CB. P10 hat 5.8 TFL, GP106 hat 4,7. Sind 23% mehr Rohleistung. Addiere ich den Performancevorsprung, braucht Polaris 30% mehr Rohleistung für ein gleiches Ergebnis.

Titan XP - ein Krüppelchechip mit angezogener Handbremse - hat 11 TFLOPs. Zum gleichziehen bräuchte es bei Polaris folglich 14,3 TFLOPs. Hoffentlich ist Vega hier besser.
NV hat noch die Option mehr SPs freizuschalten und die Taktraten zu erhöhen. Eine TXP Black hätte potenziell noch die Möglichkeit, gute 30% draufzupacken.

@TXP Ergebnisse
habe die Ergebnisse vom PCGH Test.
TXP hat 11 tflops, 1080 hat 8,87. Sind 24%.

[Dorn]

Was für ein Pascal Refresh? Die GTX1080TI ist noch gar nicht released worden. Ganz einfach weil NV damit auf Vega wartet. wenn man das schlechteste annimmt erscheint Vega im Sommer. Da wird Pascal refresh schon längst in den Start Löchern stehen.

[dargo]

Du vergisst, dass TXP noch locker 30% Taktreserve hat. Eine Reserve, die jeder TXP Käufer kennt und nutzt.

OC interessiert hier nicht, es geht um Referenz vs. Referenz. Bei max. OC wird GP104 immer den kürzeren ziehen. Ganz einfach weil der Boost bei Titan X out of the Box niedriger ist und er bei nur ~22% mehr Rohleistung 50% mehr Bandbreite hat.


GP106 ist in etwa 5% schneller im Performance Rating bei CB. P10 hat 5.8 TFL, GP106 hat 4,7. Sind 23% mehr Rohleistung. Addiere ich den Performancevorsprung, braucht Polaris 30% mehr Rohleistung für ein gleiches Ergebnis.

Du hast da einen kleinen Fehler in deiner Rechnung. ;) P10 hat keine 5,8 TFLOPs bei CB. Zudem ist der Test schon langsam veraltet. Mittlerweile gibt es afaik Gleichstand. Lass noch paar mehr DX12/Vulkan Titel dazu kommen und P10 liegt leicht vorne.

[robbitop]

Blödsinn. Zeige mir einen Käufer einer Grafikkarte dieses Preises, den OC nicht interessiert. Im Gegenteil- OC interessiert die meisten dieser Käuferschicht. Vermutlich sogar schon die Käuferschicht darunter (gp104).
Außerdem zeigt es, dass NV als Konter ein Produkt mit gut 30% mehr Leistung bringen könnten wenn sie wollten. 20% mehr Takt und Rest über vollen Chip.

[dargo]

Blödsinn. Zeige mir einen Käufer einer Grafikkarte dieses Preises, den OC nicht interessiert.
Du kennst schon die OC-Fähigkeiten von Vega? :rolleyes: Bisher stehen 12 TFLOPs im Raum, selbstverständlich ohne OC.

[robbitop]

Habe ich nicht gesagt. Ich sagte, hoffentlich hat Vega diese Reserven. Bitte Posts auch lesen.
Zuletzt waren die Radeons leider immer sehr nahe am Limit. Da gingen oftmals gerade mal +100 MHz im Durchschnitt- wenn überhaupt.

Gerade die Titans liefen immer mit extrem angezogener Handbremse und hatten locker im Schnitt 20-30% Taktreserve. Darum gehts.

[tm0975]

Blödsinn. Zeige mir einen Käufer einer Grafikkarte dieses Preises, den OC nicht interessiert.

4 meiner arbeitskollegen haben eine 480 bzs eine 390 und keiner davon hat auch nur ein bisschen interesse daran, OC zu betreiben. wenn man eine grafikkarte mit einem ausgezeichneten preis-leistungsverhältnis gekauft hat, braucht man sowas nicht. :cool:
bei 250 € für eine 8 GB 480 und oben drauf noch civ 6 ist man doch prima dabei.

[dargo]

Ich frage mich was du immer mit deinem OC bei der Karte willst die so schon komplett am Limit (Temperatur) läuft?
https://www.techpowerup.com/reviews/NVIDIA/Titan_X_Pascal/27.html

Schon arm so einen Kühler zu verbauen bei dem Preis. Und nein... Kühler demontieren und gegen was anderes oder gar auf Wakü umbauen ist nicht für jeden was.

Edit:
Ich sehe gerade, dass die 11 TFLOPs der Titan X auch nicht stimmen weil die Karte wie alle Pascals in der Praxis höher boosten.
http://www.tomshardware.de/nvidia-titan-x-2016-12gb-pascal,testberichte-242164-8.html

Es sind eher ~11,8 TFLOPs (1647Mhz avg. Takt).

[robbitop]

4 meiner arbeitskollegen haben eine 480 bzs eine 390 und keiner davon hat auch nur ein bisschen interesse daran, OC zu betreiben. wenn man eine grafikkarte mit einem ausgezeichneten preis-leistungsverhältnis gekauft hat, braucht man sowas nicht. :cool:

Es ging jetzt aber um eine Karte, die massiv teurer ist und 3-4x so hohe Taktreserven hat wie dir von dir angesprochenen Radeons.

@dargo
Anderer Kühler ist bei der TXM und TXP Pflicht. Ja das ist wirklich kritisierenswert. Macht aber praktisch jeder Titan XP Käufer. Insofern bleibt es relevant. Wenn NV ordentlich Druck bekäme, würden sie daran was ändern - wie gesagt eine TXP Black mit gut +30% wären kein Problem.

[dargo]

@dargo
Anderer Kühler ist bei der TXM und TXP Pflicht. Ja das ist wirklich kritisierenswert. Macht aber praktisch jeder Titan XP Käufer. Insofern bleibt es relevant.
Das muss aber nicht im gleichen Maße für den Vega Käufer gelten. Ich würde bsw. nie den Kühler wechseln. Ganz einfach weil die Kühler heute bedeutend besser geworden sind als noch vor vielen Jahren. Und mir mittlerweile paar Prozent mehr Leistung dank Freesync unwichtig sind. Klar... wenn die original verwendete Kühlung mehr Takt zulässt und die Grafikkarte immer noch extrem leise ist nehme ich den Bonus mit. Aber nicht um jeden Preis.

Es ging jetzt aber um eine Karte, die massiv teurer ist und 3-4x so hohe Taktreserven hat wie dir von dir angesprochenen Radeons.

Sorry, aber du übertreibst wieder maßlos!

Mit 2Ghz bist du gerade mal 21% über dem Referenztakt der Titan X. Eine Custom P10 schafft auch ihre ~14% über Referenztakt (1350 vs. 1180Mhz) wenn man es möchte. Wo siehst du da Faktoren von 3-4? Du solltest vielleicht mal langsam auf Prozentrechnung und nicht Taktvergleiche umschwenken. :wink:

[pixeljetstream]

Referenz P10 vs. Referenz GP106 trennen 15% Rohleistung. Du kannst mir gerne erklären warum AMD bei Vega plötzlich 33% mehr TFLOPs gegenüber Pascal braucht ...

Unabhängig davon ob es zutreffen mag (also ich nicht Partei in NV vs AMD ergreifen will), so fallen je nach Anwendungsfall andere units der Hardware mal mehr oder weniger ins Gewicht. Bei "purem" compute, wird hier vermutlich nichts verpuffen, aber ob eine große GPU auch dementsprechend mehr von den anderen units mitbringt steht auf nem anderen Blatt. Es kann also schon sein dass dadurch gerade bei Grafik wo mehre fixed function units involviert sind, das relativ gesehen zu nem stärkeren Bottleneck wird als bei kleineren Chips (oder umgekehrt je nachdem wie das Verhältnis dieser sekundären units so ist).
Vermutlich kann man am "async compute" benefit darauf schließen wieviel andere bottlenecks der chip so umgehen kann.

[AngelDust 32]

GP106 ist in etwa 5% schneller im Performance Rating bei CB. P10 hat 5.8 TFL, GP106 hat 4,7. Sind 23% mehr Rohleistung. Addiere ich den Performancevorsprung, braucht Polaris 30% mehr Rohleistung für ein gleiches Ergebnis.



Auch wenn das alles OT ist

http://www.3dcenter.org/news/hardware-und-nachrichten-links-der-weihnachtsfeiertage-2016

"In der Summe an DirectX-11- und DirectX-12-Titeln messen Hardware Canucks nunmehr inzwischen einen groben Gleichstand der Radeon RX 480 8GB selbst schon unter der FullHD-Auflösung aus – je nachdem wie man -2% unter DirectX 11 sowie +6% unter DirectX 12 gewichtet, könnte sogar ein leichter Vorteil der AMD-Lösung herauskommen."

[Godmode]

Bitte zum Thema Zurück. Es gibt einen eigenen Thread für GP102

[Gipsel]

Noch einen Modtext gibt es nicht mehr dazu.
Das Thema lautet Vega.

[Setsul]

@robbitop:
Der Punkt ist, dass Maxwell/Pascal sicherlich nicht deferred ist. Von IMR auf TBIM ist wesentlich einfacher als direkt auf TBDR. Und dann ist noch nicht einmal sicher ob es überhaupt TBIM ist, sondern nur dass es irgendwas mit tiling vor sich geht.

Mit tiling ist V11 mit nur einem Stack wenigstens halbwegs realistisch, dementsprechend V10 mit 2 und V20 mit 4.

Tiling sollte auch bei AMD früher oder später kommen, die Vorteile sind einfach zu groß. Gerade wenn man solche Spielereien mit einer GPU aus mehreren Dies auf einem Interposer machen will, könnte tiling extrem hilfreich sein.

[Gipsel]

Von IMR auf TBIM ist wesentlich einfacher als direkt auf TBDR. Und dann ist noch nicht einmal sicher ob es überhaupt TBIM ist, sondern nur dass es irgendwas mit tiling vor sich geht.
Definiere IMR, TBIMR und TBDR!
In etwas weiterem Sinne sind alle AMD-GPUs seit einiger Zeit in gewisser Weise "tile based", es wird aber im Wesentlichen nichts gesammelt und "deferred". Insofern sind das IMRs. Die neueren nVidia-GPUs puffern nach meinem Verständnis dagegen in gewissem Umfang on-chip in Tiles (aber nicht komplett, wieviel und wie genau ist nicht bekannt). Das wären also vielleicht partially deferred IMRs? In jedem Fall eine Art Mischform. Hier hat AMD die Chance aufzuholen. Die bisherigen Schritte in dem Bereich waren in den letzten Jahren überschaubar.

[Unicous]

http://ve.ga/

[Achill]

http://ve.ga/

Wollte auch auch gerade schreiben, in etwas mehr als 3d 21h 20m wissen wir mehr.

9R8F-aN6W4g

[[MK2]Mythos]

Seit wann kann AMD Marketing? :D
Die vielen Trommeln in der Lagerhalle bedeuten garantiert, dass zum Erscheinen von VEGA die Händler mit ausreichend Karten versorgt sind!111einseins

[Locuza]

Das Marketing ist wieder selbstsicher. :redface:
http://i.imgur.com/7fcPHA2.png

[M4xw0lf]

Das Marketing ist wieder selbstsicher. :redface:
http://i.imgur.com/7fcPHA2.png
Somnum Industries und Poor Volta :ulol:
Wär gut wenns nicht nur beim Sprücheklopfen bliebe.

[Schnoesel]

AMD scheint wieder selbstbewusst. Ist mir wesentlich lieber als die Beißreflexe garniert mit Vorwürfen unter Richard Huddy oder der komische Fixxer Typ. Jetzt muss das Produkt noch stimmen.

[Setsul]

@Gipsel:
Nach meinem Verständnis gehts bei deferred rendering darum, dass sich die Reihenfolge ändern kann. Nur sammeln und dann trotzdem in der selben Reihenfolge rendern bringt ja nichts.

Man sieht in den entsprechenden Tests, dass sich bei nVidia die Reihenfolge nicht ändert. Also ist das schonmal außen vor.

IMR sollte klar sein.

TBIM(R): Aufteilen in Tiles, und dann die Tiles nacheinander abarbeiten, teilweise mehrere gleichzeitig. Die eine Ecke des Bildes wird also früher fertig, aber in jeder Tile bleibt die Reihenfolge erhalten.

Ich habe gewisse Theorien, wie die Aufteilung bei nVidia mit den GPCs zusammenhängt, die ich nicht überprüfen kann, weil ich weder 2 verschiedene Maxwell, noch verschiedene Pascal GPUs zur Hand habe.



4 Tage dauern viel zu lang.

Die Trommeln bedeuten offensichtlich dass AMD jetzt Trommeln verkauft. Trommeln mit GPUs. Oder es gibt jetzt eine Trommel gratis zu jeder Vorbestellung. Oder ich versteh Marketing nicht.

[Blediator16]

@Gipsel:
Nach meinem Verständnis gehts bei deferred rendering darum, dass sich die Reihenfolge ändern kann. Nur sammeln und dann trotzdem in der selben Reihenfolge rendern bringt ja nichts.

Man sieht in den entsprechenden Tests, dass sich bei nVidia die Reihenfolge nicht ändert. Also ist das schonmal außen vor.

IMR sollte klar sein.

TBIM(R): Aufteilen in Tiles, und dann die Tiles nacheinander abarbeiten, teilweise mehrere gleichzeitig. Die eine Ecke des Bildes wird also früher fertig, aber in jeder Tile bleibt die Reihenfolge erhalten.

Ich habe gewisse Theorien, wie die Aufteilung bei nVidia mit den GPCs zusammenhängt, die ich nicht überprüfen kann, weil ich weder 2 verschiedene Maxwell, noch verschiedene Pascal GPUs zur Hand habe.



4 Tage dauern viel zu lang.

Die Trommeln bedeuten offensichtlich dass AMD jetzt Trommeln verkauft. Trommeln mit GPUs. Oder es gibt jetzt eine Trommel gratis zu jeder Vorbestellung. Oder ich versteh Marketing nicht.

Einfach mal die Anzahl der Trommeln zählen das ergibt dann den Takt.

[[MK2]Mythos]

Einfach mal die Anzahl der Trommeln zählen das ergibt dann den Takt.
Boost oder Base?

[Tamagothi]

Wer hat lust die Trommeln zu zählen freiwillige vor :)

[Achill]

Einfach mal die Anzahl der Trommeln zählen das ergibt dann den Takt.

:)

Somnum Industries und Poor Volta :ulol:
Wär gut wenns nicht nur beim Sprücheklopfen bliebe.

Gibt ja noch mehr zu sehen ... ;)

Konnte noch nicht alles zuordnen - auf jeden Fall ein interessanter Mix (incl. Plot/Handlung) - ob das schon ein Forecast sein soll?
- The Last Command (https://en.wikipedia.org/wiki/The_Last_Command_(1928_film))
- Le Jour où la Terre s'arrêta (https://en.wikipedia.org/wiki/The_Day_the_Earth_Stood_Still)
- When Worlds Collide (https://en.wikipedia.org/wiki/When_Worlds_Collide_(1951_film))

https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=58527

[dargo]

Das Marketing ist wieder selbstsicher. :redface:
http://i.imgur.com/7fcPHA2.png
Das ist zu geil. ;D

[BlacKi]

Mythos;11252124']Seit wann kann AMD Marketing? :D
Die vielen Trommeln in der Lagerhalle bedeuten garantiert, dass zum Erscheinen von VEGA die Händler mit ausreichend Karten versorgt sind!111einseins
oder ein hinweis auf die lautstärke, trommeln und so, passt auch zum schlusssatz "make some noise"^^

[[MK2]Mythos]

Wer hat lust die Trommeln zu zählen freiwillige vor :)
Es sind 4096+16! :O

[Gipsel]

@Gipsel:
Nach meinem Verständnis gehts bei deferred rendering darum, dass sich die Reihenfolge ändern kann. Nur sammeln und dann trotzdem in der selben Reihenfolge rendern bringt ja nichts.Was heißt Reihenfolge ändern? Das Ergebnis muß am Ende natürlich identisch sein. Aber TBDR machen z.B. mehr oder weniger vollständig das hidden surface removal (und puffern dazu die Geometrie) bevor die Pixelshader ins Spiel kommen. Im Optimalfall (der der Normalfall sein sollte) wird jeder Pixel des Rendertargets nur einmal von den ROPs geschrieben. Dies geschieht bei IMRs nicht. Jedes transformierte Dreieck geht nach den Rasterizern direkt zu den Pixelshadern (es werden nur mehrere in Wavefronts/Warps gruppiert, mehr als dafür nötig wird nicht gepuffert). Aber das Rendertarget in Tiles gliedern machen auch IMRs (wie Radeons), um z.B. das Setup zu parallelisieren (sonst funktionieren z.B. die mehreren parallelen Rasterizer nicht) oder die Bandbreiteneffizienz der ROP-Caches zu erhöhen. Aber Geometrie wird bei AMD in den Tiles nicht für das HSR gesammelt, sondern sofort den weiteren Stages zugeleitet (deswegen sind es IMRs; Early-Z, Primitive Discard Accelerator und Co. sind nur Krücken, um es etwas effizienter zu machen, ändern aber nicht das Prinzip).
Man sieht in den entsprechenden Tests, dass sich bei nVidia die Reihenfolge nicht ändert. Also ist das schonmal außen vor.Auf welche Tests beziehst Du Dich da? Neuere nV-GPUs puffern afaik sehr wohl eine begrenzte Menge an Geometrie in den Tiles und erreichen so z.B. in einigen Tests scheinbar Füllraten, die die ROPs gar nicht hergeben würden (weil HSR zumindest teilweise vor den ROPs gemacht wird? es läuft offenbar nicht Alles durch die ROPs). Es werden offenbar schlicht weniger Pixel durch die ROPs rausgeschrieben (es wird weniger überschrieben), was wesentlich für die erhöhte Bandbreiteneffizienz ist (und nicht unbedingt die Kompression des Framebuffers). NV macht Scene Tiling mitsamt (limitiertem) Sammeln von Geometrie in Tiles und HSR darauf, AMD nicht.
TBIM(R): Aufteilen in Tiles, und dann die Tiles nacheinander abarbeiten, teilweise mehrere gleichzeitig. Die eine Ecke des Bildes wird also früher fertig, aber in jeder Tile bleibt die Reihenfolge erhalten.Um die Tiles nacheinander abzuarbeiten, mußt Du die Geometrie für die Tiles sammeln und zwischenspeichern (und dann kannst Du eigentlich auch gleich HSR drauf machen, bevor Du es durch die Pixelshader jagst und hast einen TBDR). Alternative wäre, die Geometrie mehrfach durch die Vertexshader (stellvertretend für alle Shaderstages vor dem Rasterizer) zu schicken und Alles, was nicht in die gerade passende Kachel fällt zu verwerfen. Bei den typischen Kachelgrößen von maximal ein paar tausend Pixeln ist das ziemlich verschwenderisch bei heutigen Auflösungen und Geometriemengen (bei kleinen Auflösungen und wenige Geometrie ist das aber ein passabler Ansatz). Oder man sammelt die Geometrie in Tiles, macht aber kein HSR (sondern nur early-Z wie auch die normalen GPUs) und vertraut auf die Caches, die externe Bandbreite für das Rendern in den Tiles abzufangen (machen wohl einige Mobil-GPUs so). Das hilft der Bandbreiteneffizienz auch schon, man verschwendet aber tendentiell Rechenleistung/Stromverbrauch und ist immer noch von der Renderreihenfolge abhängig (front 2 back vs. back 2 front).
Wenn man aber die Geometrie in die Tiles binned, sammelt und HSR macht, dann hat man einen vollen TBDR. NV sammelt allerdings nicht vollständig, sondern nur eine gewisse (unbekannte) Menge an Geometrie in den Tiles (bis eine gewisse Größe im L2 gefüllt ist?), die dann gesammelt an die nachfolgenden Shaderstages geschickt wird. Deswegen habe ich das "partially deferred" genannt (unter der Annahme, daß auch schon irgendwie HSR gemacht wird, die über early-Z hinausgeht).
Bei AMD werden Dreiecke entsprechend dem Screenspace tile, in den es fällt, einem Rasterizer zugewiesen (als Mittel der Parallelisierung) und danach sofort weiter abgearbeitet (und die ROPs sind ebenfalls bestimmten Screentiles fest zugewiesen). Es fehlt aber das Puffern der transformierten Geometrie wie bei nV (und einigen Mobil-GPUs).

[d2kx]

oder ein hinweis auf die lautstärke, trommeln und so, passt auch zum schlusssatz "make some noise"^^

Am Donnerstag geht es um die GPU, nicht um fertige Produkte, die so vielleicht oder vielleicht auch nicht im Regal stehen werden.

[BoMbY]

Definiere IMR, TBIMR und TBDR!
In etwas weiterem Sinne sind alle AMD-GPUs seit einiger Zeit in gewisser Weise "tile based", es wird aber im Wesentlichen nichts gesammelt und "deferred". Insofern sind das IMRs. Die neueren nVidia-GPUs puffern nach meinem Verständnis dagegen in gewissem Umfang on-chip in Tiles (aber nicht komplett, wieviel und wie genau ist nicht bekannt). Das wären also vielleicht partially deferred IMRs? In jedem Fall eine Art Mischform. Hier hat AMD die Chance aufzuholen. Die bisherigen Schritte in dem Bereich waren in den letzten Jahren überschaubar.

Könnte relevant sein:


Hybrid render with preferred primitive batch binning and sorting (http://www.freshpatents.com/-dt20161222ptan20160371873.php)

A system, method and a computer program product are provided for rendering graphics with deferred primitive batch binning.

[Setsul]

Wunderbar, ewig langer Post vom Security Token gefressen.
Bin gerade nicht motiviert genug um alles neu zu tippen.

Tests siehe z.B. David Kanter. NV schreibt anscheinend anscheinend in der Reihenfolge aus wie alles reinkommt, nur eben in Tiles. TBDR ist in der Hinsicht eine Black Box, nachdem nur ein Ergebnis pro Pixel rauskommt, kann man nicht sehen in welcher Reihenfolge alles reinkam oder abgearbeitet wurde. Bei nV ist deferred eher ein Nebeneffekt, keine Grundbedingung.



@topic:
Ich habe des Rätsels Lösung: Vega kommt mit Wasserkühlung und die Pumpe hört sich an wie eine Trommel!

[Botcruscher]

Mach keine Witze. AMD schafft das. Nach dem Zahnbohrer ohne QM trau ich denen alles zu...
AMD scheint wieder selbstbewusst. Ist mir wesentlich lieber als die Beißreflexe garniert mit Vorwürfen unter Richard Huddy oder der komische Fixxer Typ. Jetzt muss das Produkt noch stimmen.

... wo wir beim eigentlichen Problem wären. Der Berg gebar eine Maus mit dem Namen P10. P11 war dann gleich eine Fehlgeburt. Marketing schön und gut. Ich sehe schon wieder den totalen Fail bei den Herstellerkarten. Seit Hawaii war aber auch wenig Gelegenheit um irgendwas besser zu machen. Nachdem Polaris nicht die Revolution war muss AMD ja irgendwo den eigen Prinzipien treu bleiben. Mal sehen ob es nächste Woche auf der CES was zusehen gibt.

[Rincewind]

sei doch nicht so pessimistisch...

[Screemer]

Er ist nicht pessimistisch, er trolliert einfach standardmäßig gegen amd.

[Gipsel]

Tests siehe z.B. David Kanter. NV schreibt anscheinend anscheinend in der Reihenfolge aus wie alles reinkommt, nur eben in Tiles. TBDR ist in der Hinsicht eine Black Box, nachdem nur ein Ergebnis pro Pixel rauskommt, kann man nicht sehen in welcher Reihenfolge alles reinkam oder abgearbeitet wurde. Bei nV ist deferred eher ein Nebeneffekt, keine Grundbedingung.Falls Du das Ding mit dem YT-Video von David Kanter meinst, das ist gar nicht dafür geeignet, das festzustellen. Allerhöchstens kann man ableiten, daß die Rasterizer anhand von Screentiles zugewiesen werden und das die Tiles offenbar nach einer gewissen Pufferung bevorzugt mit räumlicher Lokalität abgearbeitet werden. Deferred oder nicht kann der Test prinzipiell nicht sagen (edit: es wird nicht über drawcalls hinweg gesammelt, nur innerhalb eines einzelnen drawcalls; angeblich wird bis zu 64kB Geometrie [pro Rasterizer?] gepuffert, bevor die Tiles fertig gerastert und die Pixelshader angeworfen werden, also recht limitiert im Vergleich zu "richtigen" tiled Renderern). Mit GCN-Karten mit mehreren Rasterizern sieht man übrigens ähnliche Tiles (daß Kanter da eine alte VLIW5-GPU mit einem einzigen Rasterizer als Vergleich genommen hat, naja, Schwamm drüber :rolleyes:), aber weniger bevorzugte räumliche Lokalität. Daraus würde ich im Vergleich zu nV eine deutlich geringere (also minimale) Pufferung der Geometriedaten vor den Rasterizern ableiten, wie schon gesagt.
https://abload.de/img/patternamd27nkip.png
Die sichtbaren Tilegrößen ändern sich übrigens auch bei AMD mit dem Pixelformat, ähnlich wie bei nV.

[Nakai]

Ein Architecture-Preview bezüglich Vega? Ich freu mich. :D

Ich bin gespannt wie die neuen CUs aussehen.

€: Falls man mit Vega eine feinere SIMD-Granularität und ein dynamisches Wavefront-Repackaging einführen möchte, wird eine CU nicht mehr wiedererkennbar sein.

[Setsul]

@Gipsel:
Spoiler irgendwie im Eimer?
Ich habe gewisse Theorien bezüglich der Aufteilung, aber zum Testen müsste ich mir 2 verschiedene Maxwell/Pascal GPUs kaufen und das ist mir der Spaß nicht wert.
Hatte ich alles schon geschrieben und dann Security Token eben.
Aber richtig erkannt, im Vergleich zu "richtigen" tiled Renderern ist es geradezu verkrüppelt.

[Gipsel]

@Gipsel:
Spoiler irgendwie im Eimer?Also ich sehe Alles, sowohl von PC als auch vom Handy.

[StefanV]

Aber hat ATi nicht vor langer Zeit mal einen TBDR gehabt (Imageon??) und entsprechendes Know How mal vor urzeiten (200x oder früher) eingekauft?

[Gipsel]

Nein. Adreno ist ein TBIMR.

[Setsul]

Fehler gefunden, das Forum macht schon komische Dinge.

GCN3/4 haben daran nicht viel geändert oder? Wie gesagt habe Theorien aber nicht genug neue nV Karten um sie zu überprüfen.

[Gipsel]

An Details hat sich bei den verschiedenen GCN-Generationen schon was geändert, am grundlegenden Prinzip aber nicht.

[Ailuros]

Nein. Adreno ist ein TBIMR.

Adrenos sind seit R5xx etwas flexibler mit dem tiling generell geworden; ist zwar alles nur eine sw Affaere aber theoretisch kann der Treiber so manches flexibleres anstellen als nur stures IMR. Ist aber auch alles reine Qualcomm GPU team Entwicklung, denn die ersten Imageon GPUs aud der ATI Aera waren ziemlich unterdurchschnittlich. Ist zwar OT aber momentan hat QCOM im ULP SoC Bereich die kleinste die area fuer =/>DX11, ich hab aber auch den Verdacht dass sie ziemlich an fixed function hw dass nicht pflichtmaessig ist fuer DX11 gespart haben.

Falls Du das Ding mit dem YT-Video von David Kanter meinst, das ist gar nicht dafür geeignet, das festzustellen. Allerhöchstens kann man ableiten, daß die Rasterizer anhand von Screentiles zugewiesen werden und das die Tiles offenbar nach einer gewissen Pufferung bevorzugt mit räumlicher Lokalität abgearbeitet werden. Deferred oder nicht kann der Test prinzipiell nicht sagen (edit: es wird nicht über drawcalls hinweg gesammelt, nur innerhalb eines einzelnen drawcalls; angeblich wird bis zu 64kB Geometrie [pro Rasterizer?] gepuffert, bevor die Tiles fertig gerastert und die Pixelshader angeworfen werden, also recht limitiert im Vergleich zu "richtigen" tiled Renderern). Mit GCN-Karten mit mehreren Rasterizern sieht man übrigens ähnliche Tiles (daß Kanter da eine alte VLIW5-GPU mit einem einzigen Rasterizer als Vergleich genommen hat, naja, Schwamm drüber :rolleyes:), aber weniger bevorzugte räumliche Lokalität. Daraus würde ich im Vergleich zu nV eine deutlich geringere (also minimale) Pufferung der Geometriedaten vor den Rasterizern ableiten, wie schon gesagt.
https://abload.de/img/patternamd27nkip.png
Die sichtbaren Tilegrößen ändern sich übrigens auch bei AMD mit dem Pixelformat, ähnlich wie bei nV.

Nebenbei da deferred rendering seit die tile based rasterizing Geschichte fuer GeForces herauskam mal wieder komischerweise immer und immer wieder erwaehnt wird, es ist und bleibt nach wie vor kein Allerheil-Mittel. Heutige IMRs verzoegern sporadisch so oft wo es einen Vorteil bringen kann, genauso wie ein DR dort zum immediate mode umschwankt wo es wirklich nicht anders geht.

[Popopinsel]

https://abload.de/img/vega_wordcloud-01-7687ru4w.png
Quelle: http://ve.ga/wp-content/uploads/2016/12/Vega_Wordcloud-01-768x432.png

Der ganze WP-Ordner scheint durchsuchbar, interessant sind http://ve.ga/wp-content/uploads/2016/12/ oder auch http://ve.ga/wp-content/themes/radeon/dist/images/

Edit: Nett ist auch dieses Render-Video, falls es sich um Realtime handeln sollte: http://ve.ga/wp-content/uploads/2016/12/home.webm

Edit#2: to all you news sites out there, please be aware that the linked wordcloud image at the ve.ga website does include an alpha channel (white) and needs to be displayed on a darker background instead of pure white. There's white text in the image alongside the red and grey. Thanks.

[Skysnake]

In den Ordnern findet sich Instinct. Also wird man wohl VEGA in Verbindung mit der neuen Profiserie vorstellen. Also statt FirePRO.

Die Bilder sind schon krass. Da erkenne ich nicht mehr wirklich das es sich dabei um Rendergrafiken handelt (Essensbilder) Man sieht nur an einem Bild mit Hand, dass das ein Renderbild ist und dann eben durch den Direktvergleich der beiden Angestellten. Da wurde bei den Schuerzen einfach mal ein paar Falten hinzugefuegt. Daher weiss man das es sich um Renderbilder handelt. Man kann die Falten nicht einfach hinzufuegen ohne sich zu bewegen.

[Pirx]

LOL was ist das für ne Schlamperei, thx

[Skysnake]

Aus dem Word bild wissen wir dann jetzt auch, das man 8GB stacks haben wird. Also mehr als einen ;)

Vega kommt also mit >= 16GB RAM. Oder falls es doch nur einer weden sollte zumindest mit 8GB.

[Botcruscher]

Im Maximum eben. Speichert mal einer das Zeug eh der Admin aufwacht.

[Skysnake]

Ein rekursives wget ist dein Freund ;)

Liegt alles jetzt auf der Platte :D

[BoMbY]

2x Peak Throughput per clock == Verdoppelung der IPC?
Draw Stream Binning Rasterizer (siehe verlinktes Patent oben?)
Primitive Shaders?

[Skysnake]

Nein, sicherlich geht es dabei nur um native FP16 durchsatz. Mehr sollte man sich dabei wirklich nicht versprechen.

Ansonsten die Bilder von den Kellnern, durch die man sieht, das es Renderbilder sind (Schürzen):
http://ve.ga/wp-content/themes/radeon/dist/images/WAB_image_careers-a.jpg
http://ve.ga/wp-content/themes/radeon/dist/images/WAB_image_careers.jpg

Und dann unten rechts der Daumen, der sieht auch Freaky aus, also Render mäßig.
http://ve.ga/wp-content/themes/radeon/dist/images/WAB_hero-3.jpg

[tm0975]

einfach gutes Guerilla-Marketing. :-)

Mal sehen, welche Seite wie lange braucht für die "News".

[Gipsel]

Nein, sicherlich geht es dabei nur um native FP16 durchsatz. Mehr sollte man sich dabei wirklich nicht versprechen.Sehe ich genauso. Alles Andere wäre eine Überraschung.
"Draw Stream Binning Rasterizer" klingt so ein wenig nach der nV-Lösung mit Sammeln der Geometrie vor den Rasterizern. Eventuell mit dem High Bandwidth Cache (deutlich größerer und anders organisierter L2 oder noch ein L3?) gleich mit mehr Pufferung als bei nV? Generalüberholte ROP-Architektur mit Cachen des Framebuffers im L2 wäre vielleicht auch nett.
Na mal sehen.

[Nakai]

Ein Haufen Buzzword-Bingo.

Next Generation Computer Engine
Next Generation Pixel Engine
Draw Stream Binning Rasterizer
Vega NCU

Naja klingt nicht so, als ob Vega nur ein Polaris+HBM2 wird.

[iuno]

Damit ist auch 1 GHz HBM2 bestaetigt (2x bandwidth/pin)

Eine Sache fehlt mir aber in der Wordcloud, und zwar der neue Interconnect (infinity fabric)...


Die Bilder sind schon krass. Da erkenne ich nicht mehr wirklich das es sich dabei um Rendergrafiken handelt (Essensbilder) Man sieht nur an einem Bild mit Hand, dass das ein Renderbild ist und dann eben durch den Direktvergleich der beiden Angestellten. Da wurde bei den Schuerzen einfach mal ein paar Falten hinzugefuegt. Daher weiss man das es sich um Renderbilder handelt. Man kann die Falten nicht einfach hinzufuegen ohne sich zu bewegen.

Edit: Nett ist auch dieses Render-Video, falls es sich um Realtime handeln sollte: http://ve.ga/wp-content/uploads/2016/12/home.webm
Wieso soll das Zeug denn gerendert sein? IMHO sind das normale Aufnahmen, die halt nachbearbeitet wurden. Die Falten wurden nachtraeglich retuschiert und etwas mit Filtern gespielt :confused:
Das werden schlicht Bilder von irgend einem Event sein.

[Popopinsel]

Nein, sicherlich geht es dabei nur um native FP16 durchsatz. Mehr sollte man sich dabei wirklich nicht versprechen.

Ansonsten die Bilder von den Kellnern, durch die man sieht, das es Renderbilder sind (Schürzen):
http://ve.ga/wp-content/themes/radeon/dist/images/WAB_image_careers-a.jpg
http://ve.ga/wp-content/themes/radeon/dist/images/WAB_image_careers.jpg

Und dann unten rechts der Daumen, der sieht auch Freaky aus, also Render mäßig.
http://ve.ga/wp-content/themes/radeon/dist/images/WAB_hero-3.jpg

Tut mir Leid Dich enttäuschen zu müssen, aber die Bilder stammen alle von der Webseite http://wearebar.com/ der Londoner Bar "We Are Bar" (Daher auch das WAB im Dateinamen). Hat AMD etwa deren Seite geklaut und vergessen den alten Wordpress Content zu löschen? :freak:

Wieso soll das Zeug denn gerendert sein? IMHO sind das normale Aufnahmen, die halt nachbearbeitet wurden. Die Falten wurden nachtraeglich retuschiert und etwas mit Filtern gespielt :confused:
Das werden schlicht Bilder von irgend einem Event sein.
Bei den Bildern gebe ich Dir wie oben beschrieben Recht, aber dieses Home-Video ist definitiv gerendert. Das erkennt man meiner Meinung nach an den Animationen des Blattwerks und der Person am Boden.

[Unicous]

High Bandwidth Cache = HBM IMO aber vllt. mit dem ein oder anderen Schmankerl im Hinblick auch auf das Infinity Fabric.

[Troyan]

Die Marketingfirma stammt aus London: http://www.brandanddeliver.co.uk/work/radeon-rx-campaign/

ve.ga ist auf die Firma registriert: https://hardforum.com/threads/vega-countdown-has-appeared.1921304/page-2#post-1042731007

Die sind bestimmt auch für den Onlineauftritt der Bar verantwortlich gewesen. Man spart eben überall, wenn man kein Geld hat und unbedingt den Konkurrent in die Suppe spucken will. :lol:

[iuno]

Tut mir Leid Dich enttäuschen zu müssen, aber die Bilder stammen alle von der Webseite http://wearebar.com/ der Londoner Bar "We Are Bar" (Daher auch das WAB im Dateinamen). Hat AMD etwa deren Seite geklaut und vergessen den alten Wordpress Content zu löschen? :freak:

lol, hatte mich schon gefragt was es mit dem slogan auf sich hat.
Ich denke, sie haben das wp theme uebernommen und angepasst, oder dieselben Leute engagiert (https://raggededge.com/), denen das dann passiert ist

[dargo]

Ein Haufen Buzzword-Bingo.

Next Generation Computer Engine
Next Generation Pixel Engine
Draw Stream Binning Rasterizer
Vega NCU

Naja klingt nicht so, als ob Vega nur ein Polaris+HBM2 wird.
Das war doch von Anfang an klar. :confused:

[Screemer]

Das sind Bilder von wearebar (wab in den dateinamen). Deren Website ist von reggetdedge. Die haben wohl einfach das wp theme für nen anderen Kunden weiter genutz und die Daten in den Ordnern gelassen. Einmal mit Profis arbeiten...

http://wearebar.com
Http://raggededge.com

Wie alle abgehen :ugly:

Edit: zu spät, aber wenigstens bin ich nicht der einzige der es gerafft hat.

[Nakai]

Das war doch von Anfang an klar. :confused:

Naja nicht für alle. Mir war es auch klar. Ich wollte es nur als Statement nochmal erwähnen. ;D

[Skysnake]

LOL -.-

Das ist antuerlich schon hart... Ok, wäre aber auch zu schön gewesen. Wobei ich den Namen von dem Restaurant irgendwie mit AMD in Verbindung gebracht hatte durch ein früheres Event.

[Screemer]

So ordner sind dicht. Ich hoffen einer hat trotzdem mal wget angeschmissen. Könnte ja noch was brauchbares dabei sein.

[Popopinsel]

Schade, war gerade dabei auch den Ordner http://ve.ga/wp-content/themes/radeon/src/ zu durchstöbern :P

[D3fault]

Link 2 und 3 sind schon nicht mehr erreichbar ;(

[dargo]

Vega kommt also mit >= 16GB RAM. Oder falls es doch nur einer weden sollte zumindest mit 8GB.
Hmm... 16GB machen mir schon wieder etwas Sorgen was den Endkundenpreis angeht. Wie flexibel ist man da eigentlich mit HBM? Kann man einfach zwei Dies anbieten oder wäre das mit hohen Kosten verbunden? Mit zwei Dies meine ich eine 8GB und ein 16GB Version. Einfach einen Stack für 8GB weg nehmen geht ja nicht. Da würde sich die Bandbreite halbieren.

[Skysnake]

Man muss einfach nur einen 4hi Stack nehmen, dann halbiert sich schon der Speicher ;)

So wie es aussieht kommt Vega wohl auch wirklich zuerst fuer den Profi Bereich.

Am interessantesten wird sein, ob AMD bei HBM2 die volle Bandbreite bringen wird oder wie nVidia runter schalten muss.

[Gipsel]

High Bandwidth Cache = HBM IMO aber vllt. mit dem ein oder anderen Schmankerl im Hinblick auch auf das Infinity Fabric.Denke ich nicht. Insbesondere mit 8GB Stacks wird das der VRAM, nicht nur Cache.

[dargo]

Man muss einfach nur einen 4hi Stack nehmen, dann halbiert sich schon der Speicher ;)

Schon klar... das ist aber dann eine Änderung am gesamten Interposer. Deshalb meine Frage ob hier irgendwelcher kostspieliger Zusatzaufwand notwendig ist?

[Gipsel]

Schon klar... das ist aber dann eine Änderung am gesamten Interposer. Deshalb meine Frage ob hier irgendwelcher kostspieliger Zusatzaufwand notwendig ist?Nö. 8Hi und 4Hi der gleichen Serie eines Herstellers unterscheiden sich nur in der Kapazität. Da muß gar nichts am Interposer geändert werden. Und am Kühler auch nicht, da die physische Höhe ebenfalls identisch ist.

[Unicous]

Denke ich nicht. Insbesondere mit 8GB Stacks wird das der VRAM, nicht nur Cache.

Verstehe nicht worauf du hinaus willst. Ich sagte lediglich, dass HBC=HBM ist, also lediglich ein neuer Name für das Altbewährte.

http://images.derstandard.at/2016/12/14/instinct.jpg

[Nakai]

Denke ich nicht. Insbesondere mit 8GB Stacks wird das der VRAM, nicht nur Cache.

Ich vermute eine Überarbeitung des generellen Cache- und Speichersystems.
Polaris hatte hierbei schon eine Verbesserung, nämlich die Verdopplung der Cache-Größe pro MC.
Ich bin mir nicht sicher, aber wenn man eben Non-Volatile Speicher nativ mit Vega unterstützen möchte (siehe AMD PIM; Radeon Pro SSG) sollte der Speichersystem auf jeden Fall überarbeitet werden. Ich weiß nicht so recht, was man hierbei erwarten kann. Das Problem ist auch, dass Fiji mit seinem fetten Crossbar schon ziemlich am Limit ist/war.

Eventuell sehen wir eine Lösung diesbezüglich.Wie wärs mit einer anderen Strukturierung der CUs. Ergo Gruppierungen von CUs, welche einen lokalen L2-Cache besitzen. Ganz unten gibt es einen L3-Cache über alle CU-Gruppen. Einerseits wird dadurch der übergroße Crossbar reduziert und man hätte mehr Cache. Andererseits forscht AMD bereits an Speicherkompressions-Algorithmen für GPU-Computing.

Umso mehr ich darüber nachdenke, desto mehr vermute ich, dass Vega10 die 450mm² sprengt.

[dargo]

Nö. 8Hi und 4Hi der gleichen Serie eines Herstellers unterscheiden sich nur in der Kapazität. Da muß gar nichts am Interposer geändert werden. Und am Kühler auch nicht, da die physische Höhe ebenfalls identisch ist.
Prima, danke. :)

[Butterfly]

Denke ich nicht. Insbesondere mit 8GB Stacks wird das der VRAM, nicht nur Cache.
Hi,
wie ist das zu verstehen, wird der Cache dann auch "HBM Zellen" haben?
Oder wird der HBM Stack Aufgeteilt in VRAM und Cache Adressen?
Letzteres wäre echt interessant, anstatt Daten zu "moven" zwischen VRAM und Cache einfach den "pointer" nutzen.
Oder wäre das völlig aus der Luft gegriffen?

[unl34shed]

@Butterfly: HBM Zellen gibt es nicht, das sind auch nur stinknormale SRAM Zellen

[ndrs]

Es wird einfach nur eine andere Bezeichnung sein. Oder man spielt auf die SSD onboard Geschichte an, wo der HBM als Cache auftritt.

[BoMbY]

Oder Cache könnte einfach nur Cache sein ... und wenn man High Bandwith Memory hat, braucht man auch High Bandwidth Cache, weil sonst der Cache den Speicher ausbremst, was ja einige bei Fiji vermuten.

[Popopinsel]

Auch witzig: Im Quelltext der Hauptseite findet sich im Script-Block für den Countdown eine auskommentierte Variable für das Ende des Countdowns:
var end = new Date('01/05/2017 09:00 AM EST');
//var end = new Date('12/20/2016 12:00 PM EST');
Scheinbar wollte man schon am 20.12.2016 etwas ankündigen :D

[y33H@]

Und am Kühler auch nicht, da die physische Höhe ebenfalls identisch ist.Da sagt aber Nvidia was anderes?

http://scr3.golem.de/screenshots/1604/GP100-Tesla-P100-Benchmarks-Details/thumb620/GP100-Benchmark-Details-09.jpg

[BoMbY]

Naja, die effektive Höhe dürfte immer gleich bleiben, wenn man davon ausgeht, dass der Spacer bei 8-High dünner wird. Es wäre auf jeden Fall sinnvoll, wenn die Höhe durch zusätzliches Silizium immer mit der GPU ausgeglichen wird.

[y33H@]

8Hi wäre aber nur so hoch wie 4Hi, wenn die einzelnen Dies dünner wären oder enger gepackt.

[Screemer]

Da sagt aber Nvidia was anderes?

http://scr3.golem.de/screenshots/1604/GP100-Tesla-P100-Benchmarks-Details/thumb620/GP100-Benchmark-Details-09.jpg
Den Sparer bastelt aber nicht der ihv drauf, sondern die kommen damit von hynix. Eben um einheitliche Höhen zu haben. Die hbm Stapel sind ja selbst auch noch mal ein package.

http://images.anandtech.com/doci/9969/hbm2_mechanical.png
http://hexus.net/media/uploaded/2016/1/c0a70a21-3b11-4d37-b3f8-aaa2cea16006.jpg

Wäre ja auch selten dämlich, wenn dem nicht so wäre.

[Botcruscher]

8Hi wäre aber nur so hoch wie 4Hi, wenn die einzelnen Dies dünner wären oder enger gepackt.
Deswegen ja der Spacer.

[y33H@]

Das ist mir schon klar, mir ging es nur um die Aussage 8Hi sei nicht höher als 4Hi. Das gilt aber freilich nur inklusive Spacer ...

[unl34shed]

Kannst du sie etwas ohne Spacer kaufen?

[y33H@]

Nvidia hatte es so dargestellt, als käme der Spacer von ihnen. Denn ein HBM2-Package ist als 2Hi, 4Hi oder 8Hi ja offenbar immer gleich hoch.

[StefanV]

Nvidia hatte es so dargestellt, als käme der Spacer von ihnen.
DAS machen die doch immer.

Da muss man dir die Frage stellen, warum du DENEN einfach so glaubst, ohne deren Behauptungen nachzuprüfen, was in diesem Falle ja wohl ohne Probleme möglich gewesen wäre.

[Skysnake]

Das ist aber b********

Zähl doch einfach mal die DIEs. Du hast den Base Layer und darauf 4 DIEs, wovon 3 gegrindet sind und der obere eben nicht. Damit gleicht man den Höhenunterschied aus ;)

[y33H@]

Da muss man dir die Frage stellen, warum du DENEN einfach so glaubst, ohne deren Behauptungen nachzuprüfen, was in diesem Falle ja wohl ohne Probleme möglich gewesen wäre.Äh ja, die GP100 vor Ort waren nur Mockups :P

[Achill]

DAS machen die doch immer.

Da muss man dir die Frage stellen, warum du DENEN einfach so glaubst, ohne deren Behauptungen nachzuprüfen, was in diesem Falle ja wohl ohne Probleme möglich gewesen wäre.

Äh ja, die GP100 vor Ort waren nur Mockups :P

Ich bin schwer dafür das beim nächsten Event y33H und format_c der Lederjacke die Karte weg schnappen (wenn diese wieder ohne Kühler in die Luft gehalten wird) und dann das gut Stück erst einmal vermessen ... ;) :devil:

[Gipsel]

Das ist mir schon klar, mir ging es nur um die Aussage 8Hi sei nicht höher als 4Hi. Das gilt aber freilich nur inklusive Spacer ...NVidia hat da Schwachsinn auf die Folie gepackt (das wurde schon damals diskutiert, btw.). Es gibt schlicht keinen Spacer. Wie Skysnake schon sagte, wird der oberste DRAM-Die bei 4Hi (oder 2Hi) Stacks bloß nicht soweit abgedünnt wie bei 8Hi-Stacks. Wie der bereits geposteten Tabelle zu entnehmen, beträgt die Höhe eines Stacks bei HBM2 immer 0,72mm, egal wie viele Dies verbaut sind.

[y33H@]

Danke, hatte die Spacer-Diskussion damals nicht mitbekommen.

[Skysnake]

Kein Ding, aber nVidia nimmt es oft mit der Wahrheit nicht all zu genau...

[Hübie]

Das mit HBC ist afaik nix weiter als diese SSG-Geschichte. Welche Speicherart die einsetzen werden und ob die MMIOU diesen ansprechen / adressieren kann wissen wir nicht. Letzteres bezweifel ich an der Stelle. Da wird vermutlich ein SoC mit drauf gepappt sein.
Double throughput ist, wie Skysnake schon sagte FP16 im Verhältnis 2:1 bzw 4:2:1 (16:32:64). Dedizierte FP64 ALUs wird man sich wohl auch hier wieder ersparen.

Also im Grunde leider noch nix Neuses.

[iuno]

Wobei es ja noch nicht sicher ist, ob wirklich auch die halbe fp64 Leistung dabei ist. Da gab es ja auch anderslautende Gerüchte.

Ich kann mir auch vorstellen, dass sie den hbm wegen dieser dracarys Geschichte jetzt cache nennen. Dazu passt doch auch die Nennung des großen address space?!
Vielleicht ist es aber echt ein extra controller, der dann mit der infinity fabric kommuniziert?

An die Diskussion mit dem "spacer" bei gp100 erinnere ich mich auch noch ;D

[Hübie]

Ganz genau so. Ob Vega da nun einen speziellen Bus hat oder es intern dann doch über PCIE läuft müssen wir mal abwarten. Schlecht ist die Idee nicht, wenn es denn alles klappt. Da gibt's ne Menge Stolpersteine seitens der Software und auch seitens der Administration (Backup, Zugriffsschutz / Berechtigungen und auch Schnittstelle).

[basix]

Auf einer der Folien stand prominent "4x times power efficiency". Ich nehme an, dass das irgendwo ein Best Case darstellt. Ich vermute mal bei FP16, das heisst im Optimalfall landet man bei Faktor 2 unter FP32. Nimmt man sich die Fury X als Massstab, kommt in etwa folgendes bei 4K-Benches heraus:

Fury X = 100% @ 289W @ FP32
GTX 1080 = 132% @ 173W @ FP32
Vega X = 200% @ 289W @ FP32
Vega X = 132% @ 191W @ FP32

Man wäre ungefähr in Schlagdistanz mit Pascal. Hört sich doch nicht schlecht an :) Und wenn jetzt die Nörgler kommen mit "die hat HBM2 und die andere nur GDDR5X etc. blabla", das spielt doch gar keine Rolle. Ein konkurrenzfähiges Produkt zu haben spielt die entscheidende Rolle. Und ausserdem, will man noch weiter Strom sparen kann man vielleicht ja noch den Bandbreitenüberschuss reduzieren oder was auch immer.

Vergleichswerte aus 4k und Stromverbrauchs-Übersicht von 3DC:
https://www.3dcenter.org/news/schneller-ultrahd-performance-ueberblick-der-281614nm-grafikkarten
https://www.3dcenter.org/artikel/stromverbrauch-aktueller-und-vergangener-grafikkarten

[[MK2]Mythos]

Ich denke für viele ist die 225Watt Marke so eine kritische Grenze. Solange Vega (bei angemessener Performance) darunter bleibt, gibts wohl nicht viel zu meckern.

[Tru]

2x peak throughput per clock bezieht sich nicht auf FP16. :)

[Nakai]

Auf einer der Folien stand prominent "4x times power efficiency". Ich nehme an, dass das irgendwo ein Best Case darstellt. Ich vermute mal bei FP16, das heisst im Optimalfall landet man bei Faktor 2 unter FP32. Nimmt man sich die Fury X als Massstab, kommt in etwa folgendes bei 4K-Benches heraus:

Fury X = 100% @ 289W @ FP32
GTX 1080 = 132% @ 173W @ FP32
Vega X = 200% @ 289W @ FP32
Vega X = 132% @ 191W @ FP32

Man wäre ungefähr in Schlagdistanz mit Pascal. Hört sich doch nicht schlecht an :) Und wenn jetzt die Nörgler kommen mit "die hat HBM2 und die andere nur GDDR5X etc. blabla", das spielt doch gar keine Rolle. Ein konkurrenzfähiges Produkt zu haben spielt die entscheidende Rolle. Und ausserdem, will man noch weiter Strom sparen kann man vielleicht ja noch den Bandbreitenüberschuss reduzieren oder was auch immer.

Vergleichswerte aus 4k und Stromverbrauchs-Übersicht von 3DC:
https://www.3dcenter.org/news/schneller-ultrahd-performance-ueberblick-der-281614nm-grafikkarten
https://www.3dcenter.org/artikel/stromverbrauch-aktueller-und-vergangener-grafikkarten

Gut, dass du das ansprichst. Ich habe es mir nicht getraut. :freak:

50% mehr Takt und dann noch 33% höhere IPC?

€: 2x peak throughput per clock bezieht sich nicht auf FP16. :)

Mhh, und mit was wurde verglichen? Oder besser gefragt. Was wurde überhaupt verglichen? Die CUs? Das Frontend? Die gesamte GPU?

[Troyan]

Die MI25 liegt bei 300W und 12,5TFLOPs. Einfach aufhören hier Fantasiezahlen zu verwenden.

[Langlay]

Fury X = 100% @ 289W @ FP32
GTX 1080 = 132% @ 173W @ FP32
Vega X = 200% @ 289W @ FP32
Vega X = 132% @ 191W @ FP32


Die Rechnung funktioniert so nicht. Verbrauch & Performance skalieren nicht linear, also kann man hier den Dreisatz nicht anwenden.

[Linmoum]

Die MI25 liegt bei 300W und 12,5TFLOPs. Einfach aufhören hier Fantasiezahlen zu verwenden.
Tesla P100 liegt auch bei 300W. Und jetzt?

[Troyan]

Was für ein Glück, dass nVidia für die Gamer einen anderen Chip verkauft. :rolleyes:

[robbitop]

Bei Polaris IPC läge man bei 12,5 tflops ca bei der Geforce 1080 +10%. Der geleakte Wert von Doom (?) lag doch auch im Bereich 1080 +10% oder?

[Troyan]

Nein, da PCGH Vulkan genommen hat. Unter OpenGL erreicht eine auf 2050Mhz getaktete GTX1080 rund 72FPS an der Stelle bzw. wäre 10% schneller bei 17% weniger Rechenleistung.

[Screemer]

Die MI25 liegt bei 300W und 12,5TFLOPs. Einfach aufhören hier Fantasiezahlen zu verwenden.

Bei <300w. Einfach aufhören unwahrheiten zu verbreiten.

http://cdn.videocardz.com/1/2016/12/AMD-INSTINCT-VEGA-VideoCardz.com-5.jpg

[basix]

Die Rechnung funktioniert so nicht. Verbrauch & Performance skalieren nicht linear, also kann man hier den Dreisatz nicht anwenden.

Schon mal was gehört von Daumen-mal-Pi Berechnungen? :D

Natürlich skaliert das nicht linear (Spannungen, Leckströme, Chiptemperatur, etc etc). Da das Power Target in etwa ähnlich zu den Nvidias oder AMDs Vorgängergenerationen ist, sollte man es aber "in etwa" vergleichen können als Abschätzung (ich hätte auch die Titan X vergleichen können, dort gibt es aber nicht so viele Berichte wie zur 1080). Ob das jetzt +/- 15% werden spielt dann schon eine Rolle, nur eben nicht für den Fingerzeig, in welche Richtung es geht ;)

Mir würde aber auch eine positive Überraschung gefallen, wenn Faktor 4 bei FP32 auftreten sollte (auch wenn gar unwahrscheinlich) ;)

[fondness]

2x peak throughput per clock bezieht sich nicht auf FP16. :)

Das macht die Sache interessant, vor allem, da ich mittlerweile weiß, dass man dir vertrauen kann. :)

Bei Polaris IPC läge man bei 12,5 tflops ca bei der Geforce 1080 +10%. Der geleakte Wert von Doom (?) lag doch auch im Bereich 1080 +10% oder?

Polaris IPC bringt bei einer anderen Architektur nur wenig.

[Troyan]

Vega erreicht keine 17,2TFLOPs bei rund 300W.

Bei <300w. Einfach aufhören unwahrheiten zu verbreiten.

Es sind 300W (von mir aus auch 299W). AMD steht es natürlich frei genauere Angaben in ihren Paperlaunches zu machen.

[Unicous]

Bei dem Namen sollte man ihm doch vertrauen können.:wink:



edit:

Weniger als 300 sind 300, oder auch 299. Schon klar.:freak:;D

[[MK2]Mythos]

Troyan macht sich schon mal warm... :D

[basix]

Vega erreicht keine 17,2TFLOPs bei rund 300W.

Quelle? ;D Du behauptest Dinge, die du nicht weisst und stellst sie als Tatsachen dar. Vielleicht schafft sie auch 20 TFLOPs bei 300W? Wer weiss...

Dann noch der Seitenhieb mit Paperlaunch. Ich amüsier mich ;):ass:

[Achill]

Folgende 3 Bilder von https://www.heise.de/newsticker/meldung/Rechenkarten-von-AMD-Radeon-Instinct-MI6-MI8-und-MI25-mit-Vega-GPU-3568504.html deuten darauf hin, das VEGA in Form der MI25 mit ~25 TFLOPS bei 16FP-Ops kommt:

100TF/s mit 4x MI25 bei 16FP-Ops
https://1.f.ix.de/scale/geometry/696x500/q75/imgs/71/2/1/0/5/0/3/6/2-19e2b9722d2eb86d.jpg

400 TF/s mit 16x MI25 bei 16FP-Ops
https://1.f.ix.de/scale/geometry/696x500/q75/imgs/71/2/1/0/5/0/3/6/3-b44eced7d4229934.jpg

3 PF/s mit 120x MI25 bei 16FP-Ops
https://1.f.ix.de/scale/geometry/696x500/q75/imgs/71/2/1/0/5/0/3/6/4-6a207270a02844be.jpg

[Troyan]

Quelle? ;D Du behauptest Dinge, die du nicht weisst und stellst sie als Tatsachen dar. Vielleicht schafft sie auch 20 TFLOPs bei 300W? Wer weiss...

Dann noch der Seitenhieb mit Paperlaunch. Ich amüsier mich ;):ass:

Quelle? AMD. Du musst nur eine Seite zurückgeben, da hat jemand die Folie der Deep Learning Produkte veröffentlicht. Da siehst du 12,5TFLOPs bei 300W. Du redest hier von 17,2TFLOPs bei 300W.

[Locuza]

~ 25 TF unter FP16, dafür steht auch die Zahl bei den Produktnamen, für die grobe FP16-Leistung.

MI6, MI8 und MI25.

[basix]

Die Frage ist, was das für FLOPs sind. Nvidia gibt für GP100 auch wahnsinnige FLOPs an, nur sind das dann aber meistens FP16 Angaben.

Edith @ Troyan:
Dort steht immer noch <300W oder in Worten "kleiner dreihundert Watt". Und es geht mir gar nicht darum ob es nun 12.5 TFLOPs oder 17 TFLOPs sind. Es geht mir nur darum, dass man eine Unschärfe drin hat und man darum gar nicht mit Bestimmtheit sagen kann, wie dann ein Vega Produkt "exakt" aussieht. Und du stellst regelmässig die Worst Cases als ultimativ fixe Werte dar. Das ist halt einfach nicht richtig. Ob jetzt die Herstellerangaben noch geschönt sind oder nicht, kann ebenfalls niemand genau sagen. Aber ich klinke mich hier aus. Ich weiss, dass ich dich eh nicht zu einem Umdenken bewegen kann ;)

[Achill]

~ 25 TF unter FP16, dafür steht auch die Zahl bei den Produktnamen, für die grobe FP16-Leistung.

MI6, MI8 und MI25.

Die Frage ist, was das für FLOPs sind. Nvidia gibt für GP100 auch wahnsinnige FLOPs an, nur sind das dann aber meistens FP16 Angaben.

Ja hatte ich zu spät mit der Auflösung der Bilder gesehen, es ist FP16 - Editiert wo es Locuza auch angemerkt hat. Was bei FP32 und FP64 raus kommt, das wissen wir noch nicht. Aber wie wir von NV wissen, ist FP16 ganz wichtig ... ;)

[[MK2]Mythos]

Zumal MI25 mit 12,5 TFlops @300(299)watt aber ziemlich ineffient wäre im Vergleich zu MI8 mit 8,2 Tflops @< 175watt.

[M4xw0lf]

~ 25 TF unter FP16, dafür steht auch die Zahl bei den Produktnamen, für die grobe FP16-Leistung.

MI6, MI8 und MI25.
Bei den ersteren beiden ist es die FP32-Leistung.

[Mancko]

Tesla P100 liegt auch bei 300W. Und jetzt?

Scheint mir dann aber auch zwischen 9 und 12 Monate vorher am Start gewesen zu sein.

[Nakai]

Das macht die Sache interessant, vor allem, da ich mittlerweile weiß, dass man dir vertrauen kann. :)


Und Vega ist noch etwa 25~50% höher getaktet als ein Fiji.

[Locuza]

Bei den ersteren beiden ist es die FP32-Leistung.
Ab GCN Gen 3 gibt es auch native FP16/INT16 ops, allerdings keine packed-math, entsprechend ist der FP16-Durchsatz einfach genauso hoch wie FP32.

[M4xw0lf]

Ab GCN Gen 3 gibt es auch native FP16/INT16 ops, allerdings keine packed-math, entsprechend ist der FP16-Durchsatz einfach genauso hoch wie FP32.
Ah.

[Troyan]

Mythos;11254072']Zumal MI25 mit 12,5 TFlops @300(299)watt aber ziemlich ineffient wäre im Vergleich zu MI8 mit 8,2 Tflops @< 175watt.

Tja, die Fragen stehen schon seit drei Wochen im Raum.
Ich denke, die takten 4096 Vega bis zum Kotzen, um P100 zu schlagen. Denn die Effizienz hier ist nur leicht besser als bei MI6.
Mit z.B. 1300Mhz erreicht man 10,6TFLOPs bei ca. 250W. Damit ist man 50% effizienter als Polaris 10.

[stinki]

2x peak throughput per clock bezieht sich nicht auf FP16. :)

vielleicht Takten die Vega NCUs mit doppeltem Takt verglichen mit dem Rest des Chips (wie in ähnlicher Form früher bei Nvidia)...dann würden die 1.5GHz bei 4K Shadern irgendwie Sinn ergeben...glaube ich zwar nicht, aber nichts ist unmöglich...ich glaube auch eher an mehr Shader als an 1.5GHz

[basix]

Ich dachte 4096 Shader sind confirmed?

[StefanV]

vielleicht Takten die Vega NCUs mit doppeltem Takt verglichen mit dem Rest des Chips (wie in ähnlicher Form früher bei Nvidia)...dann würden die 1.5GHz bei 4K Shadern irgendwie Sinn ergeben...glaube ich zwar nicht, aber nichts ist unmöglich...ich glaube auch eher an mehr Shader als an 1.5GHz
Naja, ausschließen würde ich das jetzt nicht unbedingt.
Zumal AMD ja auch 3GHz+ Chips bald wieder rausbringt.
Kann also sein, dass es zwischen der CPU Abteilung und der Grafikabteilung doch einige 'Synergien' gab, die den Takt hoch bringen lassen.

Es ist ja nicht so, dass AMD keinen hohen Takt kann, es ist eher so, dass sie es bisher nicht wollten...

[Locuza]

vielleicht Takten die Vega NCUs mit doppeltem Takt verglichen mit dem Rest des Chips (wie in ähnlicher Form früher bei Nvidia)...dann würden die 1.5GHz bei 4K Shadern irgendwie Sinn ergeben...glaube ich zwar nicht, aber nichts ist unmöglich...ich glaube auch eher an mehr Shader als an 1.5GHz
Da würde das Marketing aber extreme Gymnastik vollziehen, um doppelten ALU-Takt als doppelten Durchsatz pro Takt zu verkaufen.

Es bleibt eig. nichts übrig, außer die praktische Performance?
Wir wissen dank dem Instincts-Event, dass die MI25 25-TFLOPs an FP16-Leistung auf die Waage bringt, entsprechend hat AMD nichts getan, um die theoretische Leistung zu erhöhen.

Daneben gibt es auch das alte Linkedin-Profil, welches 4096 ALUs für Greenland angegeben hat, entsprechend hat AMD auch nicht etwas total umgekrempelt, wie halbe ALU-Anzahl aber z.B. 4 FMA-Operationen pro Takt.

[robbitop]

Polaris IPC bringt bei einer anderen Architektur nur wenig.
Ich bin gespannt. In den letzten Jahren waren die IPC Sprünge recht übersichtlich. So einen Sprung wie bei Kepler -> Maxwell pro CU gab es leider noch nicht. Wäre natürlich wünschenswert.

Bedeutet: Worst Case sind 1080+10% (12.5 TFLOPs bei 25% weniger IPC wenn Polaris Level) oder eben schneller. Das macht, sofern der Preis stimmt, ein interessantes Produkt.

[Nakai]

Es bleibt eig. nichts übrig, außer die praktische Performance?
Wir wissen dank dem Instincts-Event, dass die MI25 25-TFLOPs an FP16-Leistung auf die Waage bringt, entsprechend hat AMD nichts getan, um die theoretische Leistung zu erhöhen.

Wie wärs mit dem Offensichtlichstem?
Erstmal wird man mit Fiji vergleichen wollen und dann macht das
2x peak throughput per clock

eher in einer anderen Hinsicht Sinn:
- 4 => 8 Shader Engines (doppelte Anzahl an Rasterizern, Geometry Engines, etc.) - 4x16 Pixel/clk => 8x16 Pixel/clk
- 64 => 128 ROPs (o.Ä) - 64 Pixel/clk => 64 Pixel/clk

Schon allein mit diesen theoretischen Verbesserungen wäre Fiji ein gutes Stück schneller gewesen. Je nach Usecase hätte da locker 15~25% mehr Performance erreicht werden können.

[Setsul]

Der Effizienzdreisatz funktioniert sehr wohl, außer irgendjemand möchte darauf bestehen dass Vega nur dann doppelte Effizienz hat wenn es einen Chip gibt der genauso schnell ist wie ein existierender, aber die Hälfte verbraucht oder bei exakt gleichem Verbrauch doppelt so schnell ist.

Die Frage ist aber mit was würde verglichen und kann man dieses Versprechen halten. Polaris sollte auch "2.8x Performance / Watt" haben.


Mein Stand (2014) war, dass GCN maximal 4 SEs x 4 RBEs/SE x 4 CUs/RBE x 64 SPs/CU = 4096 SPs unterstützt. Vor Navi hätte ich eigentlich nicht erwartet, dass sich daran etwas ändert.


2x peak throughput per clock per hotclock wäre echt eine klassische Marketingauslegung, ich hoffe doch AMD lässt sich nicht zu solchem Schwachsinn hinreißen.


Viel interessanter wird erstmal ob "8x capacity / stack" und "2x bandwidth per pin" nur wieder Maximalwerte sind oder ob tatsächlich V11 mit einem Stack kommt. Entweder greifen tatsächlich die erhofften Maxwell-ähnlichen Maßnahmen oder V11 hinge dann mit HBM an der Bandbreite, selbst als P10-Ersatz.


Wenn V10 nicht über 16GB hinauskommt wegen 2 Stacks, dann ergeben V20 als Profi-Chip mit 1/2 DP und V10 eben mit weniger DP natürlich viel Sinn. Bedeutet aber auch, dass man bis 2019 Fiji, einen Chip mit nur 4GB also Profi-Chip für DP performance mitschleppen muss. Ich weiß nicht ob das so erstrebenswert ist. Und 2019 reichen auch nur wenn Global Foundries in diesem Jahrzehnt mal einen Zeitplan einhält.

Ich bin auch immernoch gespannt welche Größe V10 letztendlich hat. 1080+10% sind schön und gut, aber wenn man dabei im Bereich 400-450mm² ist, dann wäre das wirklich nicht berauschend in Sachen perf/mm². Entweder knapp unter 400mm² oder mehr Leistung wären wünschenswert.

Fragen über Fragen. Vielleicht werden übermorgen ein paar beantwortet.

[Nakai]

Man wird wohl zwischen GP104 und GP102 liegen.

Ahja auf Zauba macht das dann Sinn:
26-Aug-2016 84733030 PRINTED CIRCUIT BOARD ASSEMBLY (VIDEO GRAPHIC CARD)P/N:102-D02702-00 (FOC) Canada Hyderabad Air Cargo NOS 3 287,599 95,866

4-Oct-2016 84733030 PRINTED CIRCUIT BOARD ASSEMBLY (VIDEO/ GRAPHIC CARD)DRACARYS FIJI/SSD P/N:102-D02702-00 (FOC) Canada Hyderabad Air Cargo NOS 2 136,990 68,495
4-Oct-2016 84733030 PRINTED CIRCUIT BOARD ASSEMBLY (VIDEO/ GRAPHIC CARD)DRACARYS FIJI/SSD P/N:102-D02702-00 (FOC) Canada Hyderabad Air Cargo NOS 1 68,495 68,495

Hallo, Vega10. Letzte Charge 1000€ pro Vega10.

€: Das bedeutet nicht, dass man anhand des Preises des Zauba-Eintrags von Vega10 auf dessen Performance schließen kann. Das war nur ein Statement.
Ahja, der Preis liegt definitiv unter Fiji damals.

[Unicous]

Erstens: Dracarys ist mit großer Sicherheit der Codename für die Radeon Pro SSG (Fiji+SSD)

Zweitens: Wovon sprichst du? Ein Fiji PCB hatte einen Wert von ca. 75-80K INR.

Dittens: Der Preis sagt nichts aus. (Die von dir zitierten Beispiele zeigen das im Übrigen sehr gut.:wink:)

edit:
Eine SSG kostet derweil $10K (als Dev Kit).

[Digidi]

Wie wärs mit dem Offensichtlichstem?
Erstmal wird man mit Fiji vergleichen wollen und dann macht das


eher in einer anderen Hinsicht Sinn:
- 4 => 8 Shader Engines (doppelte Anzahl an Rasterizern, Geometry Engines, etc.) - 4x16 Pixel/clk => 8x16 Pixel/clk
- 64 => 128 ROPs (o.Ä) - 64 Pixel/clk => 64 Pixel/clk

Schon allein mit diesen theoretischen Verbesserungen wäre Fiji ein gutes Stück schneller gewesen. Je nach Usecase hätte da locker 15~25% mehr Performance erreicht werden können.

8 Rasterizer, das ist doch viel zu viel. Die 4 jetzigen erzeugen doch schon genug Durchsatz. Vermute eher 6000 Shader bei Takt von 1,5 ghz. Was auch doppelter Leistung entspricht

[victore99]

Wenn 4096 SP wirklich das GCN-Maximum sind, was spricht dann dagegen, zwei Chips mit exakt den gleichen HW-Daten (also von den Specsheets her komplett identisch) zu bauen, einmal mit 400mm2 (=> hohe Packdichte, niedriger Takt) und einmal mit 600mm2 (und entsprechend hohem Takt), und die Differenz dann rein die Taktraten erledigen zu lassen? Erspart viel Treiber- und Architekturarbeit, die Arbeit mit der Foundry hat man ja eh bei zwei Chips..

[Locuza]

8 Rasterizer, das ist doch viel zu viel. Die 4 jetzigen erzeugen doch schon genug Durchsatz. Vermute eher 6000 Shader bei Takt von 1,5 ghz. Was auch doppelter Leistung entspricht
4 Shader-Engines sind aber auch zu wenig, außer AMD schafft es die praktische Endleistung davon extrem aufzupumpen.

Hawaii fing schon mit 4 an bei 2816 ALUs, Tonga hat dann auch 4 verwendet bei nur maximal 2048 ALUs.
Polaris 10 verwendet auch 4 bei 2304 und jedes mal ist die Effizienz der Shader-Engines gestiegen, dennoch hat AMD ab Tonga auf 4 aufgerüstet und bei Polaris 10 nicht die besseren Geometry-Engines verwendet um wieder abzurüsten, obwohl sie nur bei 32 ROPs geblieben sind.

Man schaue sich Nvidia an, 6 GPCs beim GM200/GP102 mit entsprechend 96 ROPs.

In irgendeiner Form sollte AMD aufstocken und zwar nicht zu wenig, ansonsten wird es wieder Fälle geben, wo man unterdurchschnittlich skaliert.

[Leonidas]

Vielleicht bekommt das Forum raus, was die Dateinamen "Radeon 185" und "VEGA TYLER" bedeuten sollen ...
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-3-januar-2017

[Screemer]

Vielleicht bekommt das Forum raus, was die Dateinamen "Radeon 185" und "VEGA TYLER" bedeuten sollen ...
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-3-januar-2017

Oh oh. Also zumindest, dass das ein randering ist bezweifle ich sehr und glaube eher das es ein rest von nem alten projekt von ragget edge ist. Wie die "renderings" der getränke, die dann fotos von "we are bar" waren.

[Digidi]

4 Shader-Engines sind aber auch zu wenig, außer AMD schafft es die praktische Endleistung davon extrem aufzupumpen.

Hawaii fing schon mit 4 an bei 2816 ALUs, Tonga hat dann auch 4 verwendet bei nur maximal 2048 ALUs.
Polaris 10 verwendet auch 4 bei 2304 und jedes mal ist die Effizienz der Shader-Engines gestiegen, dennoch hat AMD ab Tonga auf 4 aufgerüstet und bei Polaris 10 nicht die besseren Geometry-Engines verwendet um wieder abzurüsten, obwohl sie nur bei 32 ROPs geblieben sind.

Man schaue sich Nvidia an, 6 GPCs beim GM200/GP102 mit entsprechend 96 ROPs.

In irgendeiner Form sollte AMD aufstocken und zwar nicht zu wenig, ansonsten wird es wieder Fälle geben, wo man unterdurchschnittlich skaliert.

Rasterizer sind nicht das Problem. Die haben genug Durchsatzt. Wenn dann wird sich was an den Geometry processor tun um besser Tesselation-Werte zu erzeugen.

Die Titan X Pascal ist beim API Overhead Test aucht nicht schneller als eine GTX 1080 da hängt es eher am Command Processor und AMD kommt mit FIJI auf die gleichen werte Taktbereinigt. Wenn man den Takt auf 1,5 GHZ steigert steigt ja auch die Rasterize Leistung um 50%

Hier kann man sich mal den Polygonendurchsatz in der Byond3d Suite anschauen:
http://www.pcgameshardware.de/Titan-X-Grafikkarte-265165/Specials/Test-Benchmark-Tuning-Overclocking-vs-1080-1206879/
Da sind alle 3 Gleichauf wenn man es um den Takt bereinigt.

[Dino-Fossil]

Vielleicht bekommt das Forum raus, was die Dateinamen "Radeon 185" und "VEGA TYLER" bedeuten sollen ...
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-3-januar-2017

AMD-Angestelter: "Hey Tyler, wo finde ich denn dein Rendering für den Vega Teaser?"
AMD-Tyler: "Schau mal im Projektordner nach 'Vega Tyler'"

:freak:

[Ailuros]

Wenn man von den Folien das "<" wegdenkt, handelt es sich bei den Zahlen um board form factor Werte.

[Tarkin]

https://www.reddit.com/r/Amd/comments/5lyecl/ryzen_vega_demo_ces_star_wars_battlefront_4k60fps/?st=IXIU6WBR&sh=73ffe2fb

Ryzen + VEGA Star Wars Battlefront 4K Demo @ konstant 60fps (framelock)

das schaut schon mal vielversprechend aus im Vergleich zu

http://www.techspot.com/articles-info/1246/bench/Battlefront_02.png

[tm0975]

wenn die grafiksettings passen ist das ergebnis sehr beeindruckend. es ist definitiv deutlich über der 1080 und möglicherweise auch über pascal titan. das game an sich liegt wahrscheinlich den radeon besser.

[MR2]

https://www.youtube.com/watch?v=0FEt2mzQQfs

AMD Ryzen VR Experience:freak:

[dildo4u]

wenn die grafiksettings passen ist das ergebnis sehr beeindruckend. es ist definitiv deutlich über der 1080 und möglicherweise auch über pascal titan. das game an sich liegt wahrscheinlich den radeon besser.
Nicht wirklich das sind Benches mit der FE,Custom 1080 sind deutlich schneller.

https://youtu.be/q_3rhvsLqPU

[Linmoum]

Nicht wirklich das sind Benches mit der FE,1080 OC sind deutlich schneller.

https://youtu.be/q_3rhvsLqPU
Und AMD hat da sicher schon einen Custom-Vega drin? ;)

[MR2]

Dildo, die Vega Karte war auch ne Standard, keine OC...

[cyrusNGC_224]

Wenn V10 nicht über 16GB hinauskommt wegen 2 Stacks, dann ergeben V20 als Profi-Chip mit 1/2 DP und V10 eben mit weniger DP natürlich viel Sinn. Bedeutet aber auch, dass man bis 2019 Fiji, einen Chip mit nur 4GB also Profi-Chip für DP performance mitschleppen muss.Nicht Fiji, sondern Hawaii. Nur der hat 1/2 DP. Fiji hat nur 1/8.

[BlacKi]

eine grobe richtung zeigt das video schon. aber gibts denn genaue infos welche settings die anliegen? könnte ja auch sein, das manche features nicht aktiv sind usw. mehr als eine grobe richtung zeigt mir das video aber nicht.

Bleibt mal locker. Ich bin doppelt auf Morgen gespannt und auch recht hibbelig. Da muss man aber nicht flamen...auch wenn ich Nvidia User bin, glaub ich das AMD was großes bringt. Und wenn es so kommt, ist es gut für den Wettbewerb und uns.
ob man genauere infos über die benchmark szene oder andere performance einordnungen machen kann? wenn man die battlefront demo von polaris aus dem letzten jahr heranzieht, wirds wohl nicht viel mehr geben. wenn man sich an die einschätzungen zu polaris der user erinnert, weiß man das sie nicht zutrafen.

[fondness]

Sehe ich genau so. Eine grobe Richtung sieht man, mehr kann man bei einem fps-Lock unmöglich sagen. GTX1080-Speed wird man schon erreichen, allerdings wäre das eher zu wenig. Zumindest die GTX1080 klar schlagen, dass NV mit GP102 dagegen halten muss wäre IMO das mindeste, um von einem Erfolg sprechen zu können. Es sei denn, Vega10 liegt deutlich <400mm², aber das glaube ich nicht.

Dinge wie der doppelte FP16-Speed werden leider zu Beginn kaum eine Rolle spielen und bis es dann in mehr und mehr Spielen Einzug hält, wird wie üblich dann auch NV nachziehen.

[Setsul]

@cyrus:
Ja natürlich, langsam wirds echt schlimm mitm Gedächtnis.

Trotzdem, 5 Jahre auf 2,5 TFlops rumkrebsen hilft dem Marktanteil sicherlich nicht.

Ich war wohl irgendwie von der MI8 verwirrt.

Die Frage stellt sich aber was will man mit Fiji noch? Entweder kommt dann V11 so spät, dass man irgendwie die Lücke füllen muss oder es ist in Sachen Rohleistung kaum Unterschied zu P10.


Ja, ich suche schon wieder mögliche Probleme, aber wann V11 und V20 kommen ist noch nicht sicher zu sagen.

@topic:
Custom Taktraten sind auch wichtig, wie kann Vega dann dort mithalten? 1080 +10% auf stock sind ganz nett, aber wenn dann bei 1600-1700 MHz Schluss ist wäre das übel.

[tm0975]

Custom Taktraten sind auch wichtig, wie kann Vega dann dort mithalten? 1080 +10% auf stock sind ganz nett, aber wenn dann bei 1600-1700 MHz Schluss ist wäre das übel.

wieso? wenn vega mit 1250 mhz auf 1080 +10% käme und dann oc bis 1600/1700 ginge, wäre das doch eine annehmbare leistung.

[Kriton]

Was ich mich frage ist, ob sich die Vereinbarung mit Hynix (weiterhin) hinsichtlich HBM finanziell auszahlt. Also was genau (außer Know-How) bekommt/bekam AMD im Gegenzug?

[mboeller]

OT: noch 23,5h

[Nakai]

https://www.chiphell.com/thread-1690722-1-1.html

Es kommt. ;)

[Screemer]

wäre ja zu krass:

http://pic.yupoo.com/ztwss/G7FBFpeK/u4fLL.png

hat ja bisher kaum jemand für voll genommen, dass sowas schon mit vega kommen könnte. ich glaubs erst, wenn ich es sehe.

[Nakai]

Believe.;)

Es bringt eher keine höhere Performance, aber eine bessere Perf/Watt.

€:
http://www.freepatentsonline.com/20160085551.pdf

[Unicous]

Könntest du uns währenddessen mal verraten was du mit dem Zauba -> Vega10 Kommentar sagen wolltest?:confused:

[[MK2]Mythos]

Blöde Frage, der Typ von dem das kommt, kennt den wer?

[Nakai]

Könntest du uns währenddessen mal verraten was du mit dem Zauba -> Vega10 Kommentar sagen wolltest?:confused:

Eigentlich gar nichts. War nur ein Feedback, dass das sehr wahrscheinlich V10 ist.

Du musst nicht immer überall Haare in Suppen finden.

[fondness]

Okay, wenn das Bild stimmt, dann besteht eine NCU also aus Vec8 + vec4 + vec2 + vermutlich 1-2 Skalar ALUs?

[Unicous]

Eigentlich gar nichts. War nur ein Feedback, dass das sehr wahrscheinlich V10 ist.

Du musst nicht immer überall Haare in Suppen finden.

Ist es aber "sehr wahrscheinlich" nicht.:confused:

Geht nicht um Haare in der Suppe, sondern die Tatsache, dass das hier schon besprochen wurde und ich mich wundere warum du das herauskramst. Kann ja auch sein, dass ich was nicht gecheckt habe, denn aus dem Posting wird man nicht schlau.

[BoMbY]

Das Bild ist pure Spekulation auf Grundlage des einen Patents, und wurde gestern auf Reddit gepostet. Ist bisher nicht klar, ob Vega das wirklich beinhaltet.

[Agent117]

hat ja bisher kaum jemand für voll genommen, dass sowas schon mit vega kommen könnte. ich glaubs erst, wenn ich es sehe.

Ich auch. Woher stammt dieses Bild denn? Gab es vor par Tagen schon bei Anandtech zum Beispiel.

Radeon Vega Architecture Preview Thread (https://forums.anandtech.com/threads/radeon-vega-architecture-preview-thread.2496105/#post-38661031)

Wenn das wirklich so kommen sollte wird es auch des doppelten Durchsatzes Rätsels Lösung sein. Eine Cu hat dann im Mittel den doppelten Durchsatz wie bei den bisherigen GCN Iterationen.

Mit 4096 solcher SP (dann wohl 256 CUs; die Skalareinheiten sind dann mit inbegriffen) könnte Vega 10 dann doch deutlich schneller werden als erwartet. Möglicherweise ergeben die bisherigen Gerüchte P10 < V11 < V10 dann auch Sinn und zwischen V10 und P10 ist eine sehr große Lücke für V11.
Aber mal abwarten

[[MK2]Mythos]

Also auf deutsch, da hat irgendjemand eine halbwegs schicke Graphic über die neue Flexibilität irgendwelcher CU's gebastelt und schon sind alle überzeugt davon dass Vega so assieht? Daher meine Frage, wie glaubwürdig ist die Quelle?

[Gipsel]

Okay, wenn das Bild stimmt, dann besteht eine NCU also aus Vec8 + vec4 + vec2 + vermutlich 1-2 Skalar ALUs?Wäre aus meiner Sicht zu unflexibel. Man möchte ja nicht eine Wavefront von einem SIMD zu einem anderen transferieren (Overhead zu groß dafür). Das wird (falls es so kommt) vermutlich eher wie bei den alten Vektorrechnern laufen (auf die hat sich AMD ja schon bei der GCN-Vorstellung explizit bezogen), wo eine relativ schmale Einheit einfach mehrere Takte lang an einem variabel langen Vektor gearbeitet hat. Je länger der Vektor, desto mehr Takte.

Beispiel:
Unter vec4 macht es meiner Meinung nach zu wenig Sinn (eventuell nimmt man vec8 oder bleibt gar bei vec16, da bei kleinen Vektoren der Overhead für instruction issue recht groß wird), da die Pixelshader immer noch in Quads abgearbeitet werden. Lass eine CU also z.B. aus 16 vec4 Vektoreinheiten bestehen (statt vier mal vec16 bisher). Für eine Wavefront aus althergebrachten 64 Elementen benötigt so ein Ding dann 16 Takte. Werden mehrere Quads ausgeblendet, wird es entsprechend schneller (12 Takte bei 48 Elementen, 9 Takte bei 36, 3 Takte bei 12 usw.). Mit nur vier gültigen Elementen (1 Quad) kann jeden Takt ein neuer Befehl (aber für eine andere Wavefront, wegen Latenz) abgesetzt werden. Hierfür benötigt man dann aber viele Wavefronts, die zur Ausführung bereit sind, um die Latenzen zu verstecken. Mit ein wenig Aufwand kann man so auch Branching innerhalb einer Wavefront recht effizient handhaben (über Splitten der Wavefront in zwei kleinere, Rekonvergenz muß man halt hinkriegen, damit das wirklich gut funktioniert). Und so ein Umbau erlaubt es eventuell auch, die Latenz der Einheiten etwas zu erhöhen (hilft der Taktfähigkeit), wenn man flexibler mit dem Scheduling wird (was aber mehr Aufwand bedeutet, auch mit der Synchronisierung mit der Skalareinheit, wovon man dann eventuell eher zwei einbaut, um dem erhöhten Durchsatz kleinerer Wavefronts gerecht zu werden).
Als Mittelweg bieten sich vielleicht acht vec8 Einheiten (mit einer Latenz von 8 Takten statt bisher 4?) an. Oder man bleibt gar bei vier mal vec16, kann aber die Vektorlänge dynamisch auf bis zu 16 Elemente reduzieren (in Stufen von 64, 48, 32 oder 16). Für herkömmliche Wavefronts mit 64 Elementen ändert sich dann praktisch kaum etwas. Aber kleinere Wavefronts werden schneller, solange man genügend Occupancy (Füllgrad der CU mit Wavefronts) hat.

[iuno]

Okay, wenn das Bild stimmt, dann besteht eine NCU also aus Vec8 + vec4 + vec2 + vermutlich 1-2 Skalar ALUs?
Das Thema kam ja schon oefter auf. Unabhaengig davon, ob wir irgendwas in der Richtung bei Vega sehen, wuerde ich schaetzen, dass es nicht darum geht, SIMDs oder ganze CUs kleiner zu machen, sondern flexibler. Man schaltet wohl mehr Einheiten ab, um Strom zu sparen. Das suggeriert das Bild ja auch.
Das Bild ist aber imho fanmade, wobei ich mich gerne taeuschen lasse (wie erst bei Zen :D )

[Hübie]

Ist halt die Frage, was in der Praxis mehr vorkommt. Viele kleine Elemente in Vektoren oder weniger größere. :confused: Muss das eigentlich immer ein 4er, 8er oder 16er Teiler sein? Bei chiphell spekuliert einer auf 5 * Vec4 (Link (https://www.chiphell.com/forum.php?mod=redirect&goto=findpost&ptid=1690722&pid=35463980)). Geht so etwas (sinnvoll)?

[Nakai]

Warum sollte es nicht gehen?

Man hat dann 5 Ports á SIMD4. Der Scheduler muss dementsprechend etwas breiter werden.

Ich gehe eher davon aus, dass die SIMD16-Einheiten sich besser splitten lassen und gleichzeitig falls noch Platz auf der CU ist, mehrere Wavefronts parallel ausführen können.

[Agent117]

Als Mittelweg bieten sich vielleicht acht vec8 Einheiten (mit einer Latenz von 8 Takten statt bisher 4?) an. Oder man bleibt gar bei vier mal vec16, kann aber die Vektorlänge dynamisch auf bis zu 16 Elemente reduzieren (in Stufen von 64, 48, 32 oder 16). Für herkömmliche Wavefronts mit 64 Elementen ändert sich dann praktisch kaum etwas. Aber kleinere Wavefronts werden schneller, solange man genügend Occupancy (Füllgrad der CU mit Wavefronts) hat.

Du meinst also es wird gecheckt ob eine kleinere Vektorlänge ausreicht für die Wavefront und dann reduziert? Eine Wavefront mit 48 Elementen kann dann praktisch von 3 Vec 16 Einheiten über 3 Takte und eine mit 32 Elementen zum Beispiel von nur 2 Vec 16 EInheiten über 2 Takte abgearbeitet werden? Latenz und Durchsatz der kompletten CU würden sich aber natürlich nicht ändern aber wie du ja auch geschrieben hast kleinere Wavefronts schneller abgearbeitet?.
Bin auf keinen Fall mit GCN vertraut deshalb nochmal meine Frage ob das von den Caches und Registern her ohne weiteres so ginge oder habe ich das falsch verstanden?

[Tarkin]

Vsync war offenbar aktiviert bei dem Battlefront Demo

http://www.4gamer.net/games/300/G030061/20170104006/screenshot.html?num=004

[Gipsel]

Du meinst also es wird gecheckt ob eine kleinere Vektorlänge ausreicht für die Wavefront und dann reduziert? Eine Wavefront mit 48 Elementen kann dann praktisch von 3 Vec 16 Einheiten über 3 Takte und eine mit 32 Elementen zum Beispiel von nur 2 Vec 16 EInheiten über 2 Takte abgearbeitet werden? Latenz und Durchsatz der kompletten CU würden sich aber natürlich nicht ändern aber wie du ja auch geschrieben hast kleinere Wavefronts schneller abgearbeitet?.
Bin auf keinen Fall mit GCN vertraut deshalb nochmal meine Frage ob das von den Caches und Registern her ohne weiteres so ginge oder habe ich das falsch verstanden?Eine Wavefront wird immer nur von einer Vektoreinheit abgearbeitet. Bei den momentanen GCN-GPUs arbeitet eine vec16-Einheit über 4 Takte immer an einer 64er Wavefront (die vier vec16-Einheiten in einer CU arbeiten parallel an insgesamt vier Wavefronts, eine pro SIMD). Ein Befehl für kürzere Wavefronts wäre schneller fertig, benötigt also weniger Takte (eine 48er in 3 Takten, eine 32er in zwei Takten, eine 16er in einem Takt auf einer vec16-Einheit). Das gilt natürlich für den Durchsatz, Latenz ist noch mal was Anderes und wäre interessant, wie das genau gelöst wird (falls es überhaupt so kommt), da bisher gilt Latenz=Durchsatz=4 Takte (bzw. Vielfaches davon, z.B. für DP), was ein sehr simples Scheduling und ermöglicht (ein Abweichen davon bedeutet mehr Aufwand, da man deutlich aufwendiger Abhängigkeiten überprüfen muß und auch der Registerzugriff wird etwas komplizierter). Eventuell geht man auch auf vec4-Einheiten, hat aber trotzdem 16er Granularität bei den möglichen Wavefrontgrößen, um eben diese Beziehung mit Faktor 4 beizubehalten (dann hätte man im simpelsten Fall auch eine Skalareinheit pro vier vec4-Einheiten).

Aber ansonsten, ja. Caches haben damit keine Probleme. Die Ansteuerung der Registerfiles und Scheduling und Instruktionsissue müßten halt überarbeitet werden, damit das geht. Möglich wäre es aber auf jeden Fall.

[cat]

Wie AMD gruppieren wird ist den Ingeneuren überlassen, auch wie Sie wann welche Elemente teilen etc.
Der Punkt ist, dass AMD der Auffassung zu sein scheint, dass Vector-SIMD machen nur Sinn wenn eine Wavefront mindestens 4-Takte dauert und sinnvolle Aufgaben berechnet (also nichts mit predicated-off berechnet wird).

Aus den paar Beispielen in der Patentschrift scheint AMD evtl. nur wenn nötig die SIMD-ALUs teilen zu wollen bzw. behält sich vor im Standard weiterhin Vec-16 zu verfolgen.
Ein weiterer Punkt der daraus zu resulieren scheint ist der, dass ein Vec2-SIMD somit für Wavefronts von 2x4 also 8 Threads genutzt werden soll die nich neugruppiert werden sollen/müssen.

Falls das aus Gründen nicht möglich ist wird er in den Skalar-Einheiten ausgeführt, genauso wie alles was kleiner als 8-Threads ist und nicht neugruppiert wird.

**!! Schluss mit den ALU-besetzenden Zombie-Threads !!**

[basix]

Vsync war offenbar aktiviert bei dem Battlefront Demo

http://www.4gamer.net/games/300/G030061/20170104006/screenshot.html?num=004

Und alles auf Ultra Settings:
http://www.4gamer.net/games/300/G030061/20170104006/SS/005.jpg

Edit 1:
Evtl. ähnlich chnell wie Titan X? Wenn die Testszene vergleichbar ist könnte es hinhauen in Battlefront.
http://www.techspot.com/articles-info/1246/bench/Battlefront_02.png

Edit 2:
Es bringt eher keine höhere Performance, aber eine bessere Perf/Watt.
Wieso denn nicht? So wie ich das verstehe, kann man mit weniger ALUs die gleiche verwertbare Arbeit leisten. Peak Throughput steigt natürlich nicht, den erreicht man aber eh nur auf dem Papier.

[Agent117]

Eine Wavefront wird immer nur von einer Vektoreinheit abgearbeitet. Bei den momentanen GCN-GPUs arbeitet eine vec16-Einheit über 4 Takte immer an einer 64er Wavefront (die vier vec16-Einheiten in einer CU arbeiten parallel an insgesamt vier Wavefronts, eine pro SIMD). Ein Befehl für kürzere Wavefronts wäre schneller fertig, benötigt also weniger Takte (eine 48er in 3 Takten, eine 32er in zwei Takten, eine 16er in einem Takt auf einer vec16-Einheit). Das gilt natürlich für den Durchsatz, Latenz ist noch mal was Anderes und wäre interessant, wie das genau gelöst wird (falls es überhaupt so kommt), da bisher gilt Latenz=Durchsatz=4 Takte (bzw. Vielfaches davon, z.B. für DP), was ein sehr simples Scheduling und ermöglicht (ein Abweichen davon bedeutet mehr Aufwand, da man deutlich aufwendiger Abhängigkeiten überprüfen muß und auch der Registerzugriff wird etwas komplizierter). Eventuell geht man auch auf vec4-Einheiten, hat aber trotzdem 16er Granularität bei den möglichen Wavefrontgrößen, um eben diese Beziehung mit Faktor 4 beizubehalten (dann hätte man im simpelsten Fall auch eine Skalareinheit pro vier vec4-Einheiten).

Aber ansonsten, ja. Caches haben damit keine Probleme. Die Ansteuerung der Registerfiles und Scheduling und Instruktionsissue müßten halt überarbeitet werden, damit das geht. Möglich wäre es aber auf jeden Fall.

Vielen Dank für die Erklärung! Ich hatte das mit dem Round Robin bei GCN dann tatsächlich falsch verstanden, aber scheint ja nun so zu sein dass pro Takt eine andere Vec-16 Einheit eine Wavefront bekommt, somit jede Vec-16 Einheit jeden 4. Takt und die Wavefronts dann auch um einen Takt versetzt fertig werden. Ich dachte zuvor dass ein CU eine Wavefront über 4 Takte abarbeitet. Wenn alle gleichzeitig arbeiten und um einen Takt versetzt fertig werden müsste man bei geringerer Vektorlänge aber den Scheduler bzw. Sequenzer? auch das Verteilen von zwei bis vier verschiedenen Wavefronts pro Takt an zwei bis vier Vektoreinheiten ermöglichen, was ja bisher mit dem einfachen Sheduling und der dem Durchsatz entsprechenden Latenz nicht ging. Das klingt dann wiederum doch recht aufwendig aber wie gesagt ich bin da nicht so firm.

[Nakai]

Wieso denn nicht? So wie ich das verstehe, kann man mit weniger ALUs die gleiche verwertbare Arbeit leisten. Peak Throughput steigt natürlich nicht, den erreicht man aber eh nur auf dem Papier.

Wenn ich jetzt eine NCU mit 8+4+2+1+1 mit einer CU mit 16+16+16+16+1 miteinander vergleiche, hat man auf beiden Seiten die gleiche Anzahl an Ports. Wenn ich es mal ganz milchmädchenhaft angehen, dann wird letzteres immer genau gleich schnell sein, nur bei kleineren Blöcken (Wavefronts kleiner als 64) eben ineffizienter arbeiten.
Eine NCU wird bei großen Blöcken nicht den Peak-Durchsatz erreichen.

Wenn man nun davon ausgeht, das pro CU es immer noch 64SPs sind und die Anzahl variiert. Dann natürlich wird eine NCU bei kleinen Blöcken deutlich schneller sein. Man hat aber auch mehr Ausführungs-Ports.

[Setsul]

@tm0975:
Unter der Annahme 12,5 TFlops / 4096 SPs ~ 1525 MHz


@Gipsel:
Das Problem hat doch nur indirekt etwas mit der SIMD-Größe zu tun. Das Problem ist, dass der Scheduler jeder SIMD-Einheit nur alle 4 Takte eine Instruction gibt. Wenn man pro CU 4 Instructions pro Takt raushauen kann, reduziert sich das Problem auch mit vec16.
Mit 2,5 Wavefronts pro SIMD kann man doch kaum Latenzen verstecken, also muss die Anzahl der Wavefronts pro CU auch hoch. Jede SIMD braucht einen entsprechend großen Satz an Registern.
Also Frontend x4 und GPRs x4. So fürchterlich schlecht kann die Auslastung doch gar nicht sein, dass die Fläche alle Vorteile durch höhere Auslastung nicht auffrisst.
Und wo zum Teufel bekommt man 10.000 Wavefronts her? Fiji war doch schon kaum zu füttern.
Außerdem wenn man eben nicht auf 16er Gruppen beschränkt muss man in jedem Takt an jede SIMD issuen können, sonst wartet eine vec4 einfach nach einem einzelnen Quad 3 Takte.

Oder stehe ich jetzt völlig auf dem Schlauch?


@Nakai:
Wenn ich jetzt eine NCU mit 8+4+2+1+1 mit einer CU mit 16+16+16+16+1 miteinander vergleiche, hat man auf beiden Seiten die gleiche Anzahl an Ports. Wenn ich es mal ganz milchmädchenhaft angehen, dann wird letzteres immer genau gleich schnell sein, nur bei kleineren Blöcken (Wavefronts kleiner als 64) eben ineffizienter arbeiten.
Eine NCU wird bei großen Blöcken nicht den Peak-Durchsatz erreichen.
Bei 8+4+2+1+1 vs 16+16+16+16 und 64er Wavefronts kommt eine NCU doch nie und nimmer auf den gleichen Durchsatz wie eine CU. Bei 16 vs 64 FLOPs / Takt bringt die gleiche Anzahl der Ports doch nichts. Wie kann das immer gleich schnell sein?
Ich bin heute irgendwie extrem verwirrt.

[Locuza]

Rasterizer sind nicht das Problem. Die haben genug Durchsatzt. Wenn dann wird sich was an den Geometry processor tun um besser Tesselation-Werte zu erzeugen.

Die Titan X Pascal ist beim API Overhead Test aucht nicht schneller als eine GTX 1080 da hängt es eher am Command Processor und AMD kommt mit FIJI auf die gleichen werte Taktbereinigt. Wenn man den Takt auf 1,5 GHZ steigert steigt ja auch die Rasterize Leistung um 50%

Hier kann man sich mal den Polygonendurchsatz in der Byond3d Suite anschauen:
http://www.pcgameshardware.de/Titan-X-Grafikkarte-265165/Specials/Test-Benchmark-Tuning-Overclocking-vs-1080-1206879/
Da sind alle 3 Gleichauf wenn man es um den Takt bereinigt.
Der API-Overhead-Test ist doch für gar nichts zu gebrauchen.
Der Entwickler ratet selber davon ab, Hersteller untereinander zu vergleichen und das Ganze ist mit allem möglichen verbunden, ich würde da gar nichts ableiten wollen.

Wenn der Takt steigt, verbessert sich das Verhältnis ja nicht, die anderen Einheiten ziehen mit.
Der Polygondurchsatz hängt nicht mit dem Rasterizer zusammen, sondern dem Geometry-Processor.


[...]
Es bringt eher keine höhere Performance, aber eine bessere Perf/Watt.
[...]
Ich bin auf die Implementierung gespannt, Intel ist da extrem flexibel aufgestellt und es ist ein Teilgrund wieso die Performance unter Geometry-Shadern nicht so miserabel ausfällt wie unter Nvidia und besonders AMD:
http://www.joshbarczak.com/blog/?p=667

Je nachdem könnte es auch deutlich den praktischen Durchsatz erhöhen.

[Gipsel]

@Gipsel:
Das Problem hat doch nur indirekt etwas mit der SIMD-Größe zu tun. Das Problem ist, dass der Scheduler jeder SIMD-Einheit nur alle 4 Takte eine Instruction gibt.Das "Problem" ist, daß das Instruction Scheduling bei GCN ziemlich clever abgestimmt ist, um maximalen Effekt mit minimalem Aufwand zu erreichen. Die Latenz von 4 Takten, die 4 Vektoreinheiten mit einer Skalareinheit und das Verhältnis 4 zwischen Wavefrontgröße und SIMD-Größe ist nicht zufällig (sogar daß die Instruktionen maximal 4 Operanden [1 Ziel, 3 Quellen] haben, paßt da perfekt in die Pipeline) ;). Macht man das "zu dynamisch" oder ändert an nur einer Stelle was, paßt das nicht mehr zusammen und es gehen viele nette Eigenschaften verloren, sprich, daß muß man sich mit deutlichem Mehraufwand beim Scheduler und dem Registerzugriff erkaufen.
Wenn man pro CU 4 Instructions pro Takt raushauen kann, reduziert sich das Problem auch mit vec16.Das war ja eine der Möglichkeiten, die ich genannt habe: Wavefronts mit 16er Granularität auf vec16-Einheiten. Der Scheduling-Aufwand steigt natürlich und man benötigt dann mindestens vier 16er Wavefronts (statt einer 64er) um die Einheiten bei gleicher Latenz von 4 Takten am Laufen zu halten. Und man benötigt tendentiell mehr Skalarregister und Skalareinheiten (die halten bzw. bearbeiten Daten die pro Wavefront vorliegen, mehr Wavefronts =>mehr Daten in Skalarregistern).
Übrigens kann eine GCN-CU pro Takt bis zu 5 Instruktionen absetzen (Vektor-, Skalar-, LDS-, vMem- und Exportinstruktionen gehen parallel). Dies müßte vermutlich angehoben werden auf zwei bis drei pro Vektoreinheit (1 vALU + 1 sALU + 0.5 LDS + 0.5 Sonstiges oder sowas), also vielleicht 12 pro CU. Das verkompliziert so Einiges, z.B. auch die LDSdirect-Funktionalität (ein skalarer Operand für eine Vektorinstruktion [identisch für die ganze Wavefront] kann direkt aus dem LDS kommen und wird per Broadcast an alle vALU-Slots verteilt; dafür wird der Zugriff allen anderen vorgezogen, was natürlich nur klappt, wenn es keine Kollisionen mit anderen LDSdirect-vALU-Instruktionen gibt, was durch das round robin Scheduling mit maximal einer vALU-Instruktion pro Takt inhärent garantiert ist).
Mit 2,5 Wavefronts pro SIMD kann man doch kaum Latenzen verstecken, also muss die Anzahl der Wavefronts pro CU auch hoch. Jede SIMD braucht einen entsprechend großen Satz an Registern. Also Frontend x4 und GPRs x4.Kleinere Wavefronts benötigen weniger Register. Es ist also für den Vektor-Registerbedarf egal, ob ich 4x 64er Wavefronts habe oder 16x 16er. Bei Letzterem minimiert man eventuell sogar den Verschnitt, nutzt den Platz also effizienter. Man benötigt nur mehr Skalarregister (was sich dadurch lösen läßt, daß z.B. jede vALU ihre eigene sALU [mit entsprechendem Registersatz] bekommt).
Will sagen: Vervierfachung der vRegs wäre totaler Overkill. GCN hatte schon immer so viele Register pro ALU (1024, also 4kB) wie Pascal und zusätzlich noch die Skalarregister, die die Situation im Prinzip noch weiter entspannen (weil GCN im Gegensatz zu nV GPUs einige Daten in den sRegs statt vRegs halten kann).
So fürchterlich schlecht kann die Auslastung doch gar nicht sein, dass die Fläche alle Vorteile durch höhere Auslastung nicht auffrisst.Ist sie auch nicht, weswegen man auch nie und nimmer die vRegs auf 1MB pro CU aufblasen wird (momentan hat man 256kB, 64kB pro vALU).
Außerdem wenn man eben nicht auf 16er Gruppen beschränkt muss man in jedem Takt an jede SIMD issuen können, sonst wartet eine vec4 einfach nach einem einzelnen Quad 3 Takte.Das müßte man bei vec16 und Wavefronts kleiner als 64 Elemente doch auch. Bei minimal 16er Wavefronts und vec4-Einheiten ist jede Einheit erstmal wieder 4 Takte beschäftigt, genau wie jetzt eine vec16-ALU mit 64er Wavefronts. Man könnte eine CU praktisch vierteln (bzw. erzeugt vier Subgruppen in einer CU mit jeweils vier vec4-ALUs und einer sALU). Aber ob sich der Overhead dafür lohnt, keine Ahnung.

[Digidi]

@Locuza
Der API Overhead kann man deshalb nicht gebrauchen weill er nur einfache Shader verwendet. Aber er zeigt ganz gut wie gut der Durchsatz vom Command Prozessor und vom Rasterizer ist und da limitiert Nvidia vor AMD Taktbereinigt. AMD muss nur die Aufteilung der Rasterizer verändern und die Shader besser beliefern. Das ist der Knackpunkt. Dann kommt man auch mit 4 Rasterizern aus. Ich glaub AMD wird wenn dann mit 6 Rasterizern kommen. 8 Wären wirklich Overkill.

[Nakai]

@Nakai:

Bei 8+4+2+1+1 vs 16+16+16+16 und 64er Wavefronts kommt eine NCU doch nie und nimmer auf den gleichen Durchsatz wie eine CU. Bei 16 vs 64 FLOPs / Takt bringt die gleiche Anzahl der Ports doch nichts. Wie kann das immer gleich schnell sein?
Ich bin heute irgendwie extrem verwirrt.

Ich meinte die CU nicht die NCU.

Das Verhältnis zwischen 4 TMUs und 64 SPs ist doch ganz gut. Die TMUs sind immer an den Loadpipes gekoppelt. Das passt schon ganz gut. Ich denke eine Vega NCU hat immer noch 64 SPs.

[y33H@]

Vsync war offenbar aktiviert bei dem Battlefront Demo

http://www.4gamer.net/games/300/G030061/20170104006/screenshot.html?num=004Ja, war unschwer am 60-fps-Limit zu erkennen.

[Digidi]

Vielleicht kann mich mal jemand aufklären. Eine Wavefront hat 64 Threads (Aufgaben). Wieso macht man denn überhaupt Wavefronts ? Warum setzt man denn nicht jeden einzelnen Thread einzeln in der CU ab?

[Gipsel]

Vielleicht kann mich mal jemand aufklären. Eine Wavefront hat 64 Threads (Aufgaben). Wieso macht man denn überhaupt Wavefronts ? Warum setzt man denn nicht jeden einzelnen Thread einzeln in einer CU ab?Weil Du dann die kompletten Energie- und Flächeneffizienzvorteile von SIMD in den Wind schießen würdest. Du hättest praktisch eine Ansammlung von skalaren CPU-Kernen. Und bei denen frißt Dich der Overhead für das Instruktionsscheduling im Vergleich völlig auf.

[Nakai]

Eine Wavefront ist eigentlich der Thread.

[Gipsel]

Eine Wavefront ist eigentlich der Thread.Das zu erklären, habe ich schon vor Jahren aufgegeben ;).
Ich hoffe nur noch, daß sich die Nomenklatur von OpenCL oder von Vektorrechnern (wie manchmal von AMD benutzt) durchsetzt, dann erübrigt sich das hoffentlich irgendwann.

[Setsul]

Das war ja eine der Möglichkeiten, die ich genannt habe: Wavefronts mit 16er Granularität auf vec16-Einheiten.


Das müßte man bei vec16 und Wavefronts kleiner als 64 Elemente doch auch. Bei minimal 16er Wavefronts und vec4-Einheiten ist jede Einheit erstmal wieder 4 Takte beschäftigt, genau wie jetzt eine vec16-ALU mit 64er Wavefronts. Man könnte eine CU praktisch vierteln (bzw. erzeugt vier Subgruppen in einer CU mit jeweils vier vec4-ALUs und einer sALU). Aber ob sich der Overhead dafür lohnt, keine Ahnung.
Ich meinte das hier:
Eventuell geht man auch auf vec4-Einheiten, hat aber trotzdem 16er Granularität bei den möglichen Wavefrontgrößen, um eben diese Beziehung mit Faktor 4 beizubehalten (dann hätte man im simpelsten Fall auch eine Skalareinheit pro vier vec4-Einheiten).
Dann hat man genau das selbe Problem wie vorher, wenn die Wavefronts nicht 16 Threads ausnutzen. Natürlich ist das wesentlich seltener, aber jetzt hat man einfach 4 CUs mit 4x vec4 statt einer mit 4x vec16. Ob es den Overhead wert ist? Es ist definitiv nichts was ein offensichtlicher, enormer Vorteil ist, sonst hätte man das schon längst gemacht.
Auf jeden Fall wieder keine 100% Auslastung.



Übrigens kann eine GCN-CU pro Takt bis zu 5 Instruktionen absetzen (Vektor-, Skalar-, LDS-, vMem- und Exportinstruktionen gehen parallel). Dies müßte vermutlich angehoben werden auf zwei bis drei pro Vektoreinheit (1 vALU + 1 sALU + 0.5 LDS + 0.5 Sonstiges oder sowas), also vielleicht 12 pro CU. Das verkompliziert so Einiges, z.B. auch die LDSdirect-Funktionalität [...]




Kleinere Wavefronts benötigen weniger Register. [...]
Will sagen: Vervierfachung der vRegs wäre totaler Overkill.
[...]

Was ich meine ist, wenn man 64er Wavefronts behalten will, dann braucht man mehr Register. Klar landet man irgendwo beim Mittelweg, aber man erkauft sich alles an höherer Auslastung wieder durch mehr Fläche.
Vec4 mit 16er Wavefronts -> Frontend x4, selbe Probleme bei <16 wie vorher bei <64, wenn auch wesentlich seltener.
Vec16 mit 16er Wavefronts -> Scheduler bis zu x4, sonst Bubbles.
Mit vec4 und 64er Wavefronts wäre man dann irgendwo dazwischen, die kleineren Wavefronts brauchen weniger Register, aber es werden auch mehr Wavefronts. Der Anteil an großen Wavefronts spart ein bisschen Frontend, aber jede SIMD braucht ein paar Register mehr. Also zum Beispiel dann -> Frontend x2, GPRs x2.


Da kann man jahrelang diskutieren und simulieren um das Optimum zu finden, das für den nächsten Fall dann wieder ganz anders ist, aber riesiger Vorteile sehe ich einfach nicht.



Und es hat alles irgendwie nichts mit den asymmetrischen NCUs gemeinsam.
Wann genau ist eigentlich ist eigentlich die Breite einer Wavefront der Hardware bekannt? Bevor ich hier wilde Theorien aufstelle.

[Nakai]

Das zu erklären, habe ich schon vor Jahren aufgegeben ;).
Ich hoffe nur noch, daß sich die Nomenklatur von OpenCL oder von Vektorrechnern (wie manchmal von AMD benutzt) durchsetzt, dann erübrigt sich das hoffentlich irgendwann.

Schön wärs. Nur als allgemeine Info;
Das liegt hauptsächlich an NVs Begriff des SIMT und das einzelne Work-Items als Threads bezeichnet werden. Und jedes Workitem hat einen eigenen PC. Deswegen Wavefront = Thread.

[Gipsel]

Ich meinte das hier:

Dann hat man genau das selbe Problem wie vorher, wenn die Wavefronts nicht 16 Threads ausnutzen. Natürlich ist das wesentlich seltener, aber jetzt hat man einfach 4 CUs mit 4x vec4 statt einer mit 4x vec16. Ob es den Overhead wert ist? Es ist definitiv nichts was ein offensichtlicher, enormer Vorteil ist, sonst hätte man das schon längst gemacht.
Auf jeden Fall wieder keine 100% Auslastung.Man optimiert für den häufigen Fall, nicht für den Extremfall. 100% Auslastung kann man nie garantieren. Aber der Verschnitt wäre deutlich kleiner (bei 16er Gruppen 0 vs. 75% bzw. 100% Auslastung vs. 25%, für noch kleinere hat man immer Faktor 4 höhere Auslastung).
Ob sich das tatsächlich lohnt, bezweifle ich auch. Meistens sollten größere Wavefronts dominieren.
Was ich meine ist, wenn man 64er Wavefronts behalten will, dann braucht man mehr Register.Wieso? Und wenn, dann nicht sehr viel mehr.
Vec4 mit 16er Wavefronts -> Frontend x4, selbe Probleme bei <16 wie vorher bei <64, wenn auch wesentlich seltener.Vermutlich selten genug.
Vec16 mit 16er Wavefronts -> Scheduler bis zu x4, sonst Bubbles.Man kommt vermutlich mit etwas weniger als x4 Scheduler-Resourcen aus, da die kleinstmöglichen Wavefronts nicht dominieren sollten (sonst hätte man bisher nicht mit 64er leben können).
Mit vec4 und 64er Wavefronts wäre man dann irgendwo dazwischen, die kleineren Wavefronts brauchen weniger Register, aber es werden auch mehr Wavefronts. Der Anteil an großen Wavefronts spart ein bisschen Frontend, aber jede SIMD braucht ein paar Register mehr. Also zum Beispiel dann -> Frontend x2, GPRs x2.Man benötigt hauptsächlich mehr Skalarregister. Und die haben die letzten GCN-Versionen beinahe bis zum Umfallen (die wurden schon vergrößert, es gibt 800 pro Vektor-ALU, also 3200 pro CU), das fällt trotzdem kaum ins Gewicht im Vergleich zu den vRegs (eine Tonga-/Polaris-CU besitzt 256kB vRegs, 64kB LDS, 16kB L1-vD$ und 12,5kB sRegs), selbst wenn man die verdoppeln oder z.B. auf 32kB im Vergleich zu den ersten GCN-Generationen vervierfachen würde.
Und es hat alles irgendwie nichts mit den asymmetrischen NCUs gemeinsam.Asymmetrie ist typischerweise schlecht ;). Physisch unterschiedliche Breiten überzeugen mich nicht so sehr auf Anhieb, da das weitere Probleme mit sich bringt. Ich würde vermuten, daß unterschiedliche Ausführungszeiten mit verschieden langen Vektoren einfacher zu realisieren sind. Und man kann jede Vektorlänge auf jeder vALU laufen lassen, die alle identisch sind. Das ist das elegantere Design für mich.
Wann genau ist eigentlich ist eigentlich die Breite einer Wavefront der Hardware bekannt? Bevor ich hier wilde Theorien aufstelle.Das ist Konvention bzw. wird im gewissen Sinne beim Dispatch von Aufgaben zum Shaderarray (durch die ACEs für Computeshader bzw. den UTDP oder Rasterizer für Grafikshader) festgelegt. Hier könnte der Programmierer im Prinzip Einfluß nehmen (man kann die Workgroup Größe für bestimmte Shaderarten festlegen). Will man die Größe dynamisch machen, muß der Scheduler in der CU z.B. Branches erkennen und eine Wavefront z.B. bei einem Branch splitten (und möglichst wieder rekonvergieren lassen).
Schön wärs. Nur als allgemeine Info;
Das liegt hauptsächlich an NVs Begriff des SIMT und das einzelne Work-Items als Threads bezeichnet werden.Auch Microsoft ist nicht ganz unschuldig mit ihrer Terminologie bei Direct3D.

[Setsul]

Was ich meine ist, wenn man 64er Wavefronts behalten will, dann braucht man mehr Register.
Wieso? Und wenn, dann nicht sehr viel mehr.

64er sollten eigentlich relativ häufig sein, sonst würde das System ja nicht funktionieren, also sollte man schon einen guten Anteil an großen Wavefronts tolerieren können. Wäre kontraproduktiv den niedrigeren Overhead nicht mitzunehmen, wo immer es geht, außer eben die ganz extremen Fälle.


Ja, das ist alles worst case aber wie gesagt

Da kann man jahrelang diskutieren und simulieren um das Optimum zu finden, das für den nächsten Fall dann wieder ganz anders ist, aber riesiger Vorteile sehe ich einfach nicht.



Asymmetrie ist typischerweise schlecht ;). Physisch unterschiedliche Breiten überzeugen mich nicht so sehr auf Anhieb, da das weitere Probleme mit sich bringt. Ich würde vermuten, daß unterschiedliche Ausführungszeiten mit verschieden langen Vektoren einfacher zu realisieren sind. Und man kann jede Vektorlänge auf jeder vALU laufen lassen, die alle identisch sind. Das ist das elegantere Design für mich.

Jaaaaa, aber wer sagt, dass man unterschiedliche Latenzen will?
Und wie gesagt, das Patent will es so aber ich verstehe bis jetzt auch nicht warum.



Das ist Konvention bzw. wird im gewissen Sinne beim Dispatch von Aufgaben zum Shaderarray (durch die ACEs für Computeshader bzw. den UTDP oder Rasterizer für Grafikshader) festgelegt. Hier könnte der Programmierer im Prinzip Einfluß nehmen (man kann die Workgroup Größe für bestimmte Shaderarten festlegen). Will man die Größe dynamisch machen, muß der Scheduler in der CU z.B. Branches erkennen und eine Wavefront z.B. bei einem Branch splitten (und möglichst wieder rekonvergieren lassen).
Ich habe mich also nicht geirrt, man hätte bei Weitem genug Zeit und Möglichkeiten um Wavefronts einigermaßen gut nach Größe zu sortieren.
SIMD unit aufteilen in Blöcke (8/4/2/1/1) die man powergaten kann, innerhalb einer CU dann darauf achten dass alle Wavefronts auf derselben SIMD die gleiche Größe plus minus ein paar Prozent haben, powergaten nach Bedarf, Effizienz steigt ein bisschen, Latenzen bleiben so schön uniform wie gewohnt und gewünscht, alle Ressourcen (Decode/Scheduling/Memory/Register was auch immer) pro Wavefront bleiben wunderschön konstant, alle sind glücklich.

Sowas wird im Patent am Rande erwähnt und damit könnte ich mich definitiv anfreunden.

Man kann alles Mögliche machen und durch perfektes scheduling alle Lücken füllen und das Patent deckt natürlich alles ab was man jemals damit anstellen könnte, aber als erster Schritt wäre das doch nicht schlecht.
Ich meine es treiben sich schon genug Wavefronts auf einer GPU herum, wenn man dann auch noch noch mehr durchbringt weil man den Durchsatz bei den kleinen Wavefronts erhöht, dann braucht man wieder mehr Ressourcen um das Ganze zu kontrollieren.
Einfach nur die gleiche Anzahl Wavefronts durchzubringen und bei den kleinen weniger Strom zu verschwenden ist doch auch ganz nett.

[Gipsel]

64er sollten eigentlich relativ häufig sein, sonst würde das System ja nicht funktionieren, also sollte man schon einen guten Anteil an großen Wavefronts tolerieren können. Wäre kontraproduktiv den niedrigeren Overhead nicht mitzunehmen, wo immer es geht, außer eben die ganz extremen Fälle.Schon klar, aber wieso benötigt man dazu mehr Register?
Jaaaaa, aber wer sagt, dass man unterschiedliche Latenzen will?Hat man jetzt auch schon für einige Befehle (z.B. DP). Solange Latenz<=Throughput gilt, bleibt das Scheduling einfach, auch bei von der Vektorlänge abhängigen Taktzahlen.Ich habe mich also nicht geirrt, man hätte bei Weitem genug Zeit und Möglichkeiten um Wavefronts einigermaßen gut nach Größe zu sortieren.Die Frage wäre, wann treten überhaupt kleine Wavefronts auf? Solange niemand Unmengen Drawcalls mit einzelnen, kleinen Dreiecke absetzt, sollte das recht selten sein (weswegen ich immer noch zweifle, daß wir sehr viel Aufwand in die Richtung sehen werden).
Außer bei Branching innerhalb einer Wavefront. Und dann wird es dynamisch ohne Zeit für irgendwas zu haben.
SIMD unit aufteilen in Blöcke (8/4/2/1/1) die man powergaten kann, innerhalb einer CU dann darauf achten dass alle Wavefronts auf derselben SIMD die gleiche Größe plus minus ein paar Prozent haben, powergaten nach Bedarf, Effizienz steigt ein bisschen, Latenzen bleiben so schön uniform wie gewohnt und gewünscht, alle Ressourcen (Decode/Scheduling/Memory/Register was auch immer) pro Wavefront bleiben wunderschön konstant, alle sind glücklich.Außer die, die mehr Performance wollen.
Es widerspricht auch der Idee von einer CU mit verschieden breiten vALUs. Aber das gefällt mir ja wie gesagt schon aus dem Grund nicht, daß das statisch wäre und man sich mit der Verteilung irgendwie auf einen erwarteten Mix festlegt (und kleine Wavefronts müßten erheblich häufiger sein, als ich glaube, damit sich das lohnen könnte). Und man verbaut Ausführungsresourcen, die man im Peak nie gleichzeitig nutzen kann. Da würde es tatsächlich mehr Sinn machen, weiterhin vier vec16-ALUs zu verbauen und dynamisch Lanes zu gaten, wenn es einem nur um den Stromverbrauch geht.
Ich meine es treiben sich schon genug Wavefronts auf einer GPU herum, wenn man dann auch noch noch mehr durchbringt weil man den Durchsatz bei den kleinen Wavefronts erhöht, dann braucht man wieder mehr Ressourcen um das Ganze zu kontrollieren.
Einfach nur die gleiche Anzahl Wavefronts durchzubringen und bei den kleinen weniger Strom zu verschwenden ist doch auch ganz nett.Das geht wohl tatsächlich am einfachsten über das Gaten ungenutzter Vektorlanes bei weiterhin vier vec16-ALUs pro CU. Aber das wäre eine recht minimale Änderung, der ich kaum die Bezeichnung NCU zugestehen würde.
Will man aber die Performance mit kleineren Wavefronts steigern, benötigt man mehr (dafür kleinere) vALUs und mehr Scheduling Resourcen (die man bei großen Wavefronts clockgaten kann). Anders geht es nicht. Und es ist sogar effizient vom Stromverbrauch her (die Performance bei kleinen Wavefronts steigt mehr als der Stromverbrauch, bei großen Wavefronts ist es beinahe egal).

[Skysnake]

Weil Du dann die kompletten Energie- und Flächeneffizienzvorteile von SIMD in den Wind schießen würdest. Du hättest praktisch eine Ansammlung von skalaren CPU-Kernen. Und bei denen frißt Dich der Overhead für das Instruktionsscheduling im Vergleich völlig auf.
Daher bin ich bei deinem Vec16 Vorschlag auch etwas skeptisch.

Es ist allerdings wirklich sehr schwer abzuschätzen. Man könnte auf der anderen Seite ja das Registerfile eventuell weiter verteilen und damit wieder etwas rausreisen. Man würde damit halt die Anzahl an maximal nutzbaren Registern reduzieren. Aber von außen kann man das nicht abschätzen, wie sich das genau auswirkt.

Ich für meinen Teil bin auf jeden Fall etwas skeptisch, auch wenn es schon teils sexy wäre nur noch mit einer Granularität von 16 zu arbeiten. 64 ist halt schon recht fett. Man würde damit auch die Portierung von CUDA Code vereinfachen, da die ja auch 16er Granularität haben.

Das zu erklären, habe ich schon vor Jahren aufgegeben ;).
Ich hoffe nur noch, daß sich die Nomenklatur von OpenCL oder von Vektorrechnern (wie manchmal von AMD benutzt) durchsetzt, dann erübrigt sich das hoffentlich irgendwann.
Ja, das wäre sehr schön... Bis man den Leuten das erklärt hat....

Wobei der lustige Teil dabei ja ist, das sowohl die alten VECs von CRAY als auch die aktuellen von NEC ja für ihre guten Compiler bekannt waren/sind ;D

Wenn die Dinger halt auch nicht Vectorisieren, dann sind die Maschinen auch tot...

Bei der aktuellen SX-ACE brauchste Vektorlängen eher >256 damit da etwas geht.

[fondness]

AMD VEGA Präsentation:
http://videocardz.com/65406/exclusive-amd-vega-presentation

Das "over 2x peak throughput per clock" bezieht sich auf den Geometrie Durchsatz. Vega soll bis zu 11 Polygone/ Takt verarbeiten können vs. maximal 4 auf Fury X.

Eine NCU besteht nun wohl aus 128 SPs, die 256 16 bit Ops und 512 8 bit Ops raus hauen können, double precision konfigurierbar:

https://s23.postimg.org/c7trvwzvv/AMD_VEGA_VIDEOCARDZ_26.jpg (https://postimg.org/image/v05mzhw9z/)

https://s24.postimg.org/sx4lbg3ut/AMD_VEGA_VIDEOCARDZ_28.jpg (https://postimg.org/image/p0r9fgiv5/)

[Gipsel]

Wie vermutet: Ein binning Rasterizer der eventuell sogar mehr in den Tiles puffert als die nV-Lösung. ROP-Caches sind weg und Framebuffer wird jetzt vom L2 gecached. Packed Math.
Wie das mit den zwei FP32-Instruktionen pro Takt funktioniert, müssen wir aber wohl noch abwarten, das ist noch nicht klar. Eventuell einfach 128SPs pro NCU.

Gibt übrigens auch bei Vega weiterhin 4 Geometry-Engines. Auf die maximal 11 kommt man offenbar mit Clipping/HSR in den Tiles (bisher unterscheidet sich der Durchsatz bei AMD praktisch nicht, egal ob die Dreiecke sichtbar sind oder geclippt werden).

[Akkarin]

http://cdn.videocardz.com/1/2017/01/AMD-VEGA-VIDEOCARDZ-27.jpg

Dass ist wohl der chart über den die letzten seiten diskutiert wurde.

[Gipsel]

http://cdn.videocardz.com/1/2017/01/AMD-VEGA-VIDEOCARDZ-27.jpg

Dass ist wohl der chart über den die letzten seiten diskutiert wurde.
Nein ;). Das hat nichts mt variablen Wavefrontgrößen zu tun. Die werden in den Slides nicht erwähnt, kommen also vermutlich nicht. Ein paar Leute waren ja sowieso skeptisch.

[AffenJack]

Das sieht auf den ersten Bilck richtig gut aus. Endlich seit GCN 1 ein richtiger größerer architektureller Sprung. Der binning rasterizer sollte bestimmt sehr nützlich sein und die 128 SP NCUs sind auch interessant. Wieso man da wohl umgestiegen ist? Für Deep Learning ist mit 4x8Bit auch alles dabei. Sieht einfach top aus. Ich bin gespannt, was in den Artikeln noch so alles zu den Bildchen stehen wird.

[tm0975]

die frage ist, wieviel davon als unterstützung per treiber kommt und was die software, vor allem im bereich gaming, liefern oder speziell nutzen muß.

[Ailuros]

http://cdn.videocardz.com/1/2017/01/AMD-VEGA-VIDEOCARDZ-27.jpg

Dass ist wohl der chart über den die letzten seiten diskutiert wurde.

Verlese ich mich oder ist es entweder 1* FP32 oder 3* FP16? Wenn ja liegt die Frequenz dann doch wohl auf 1GHz.

[Locuza]

Ich sehe da drei Möglichkeiten, 1x FP32, 2x FP16 oder 1x FP16.

[Ailuros]

Ich sehe da drei Möglichkeiten, 1x FP32, 2x FP16 oder 1x FP16.

Wird es irgendwo anders erlaeutert wo ich es uebersehen habe? Ich bin mir nie sicher mit zwielichtigem marketing Gefusel.

[AffenJack]

Steht doch schon in der NCU Folie, 128 Ops 32Bit oder 256 16 Bit, also 2x.

[deekey777]

"Exclusive: AMD VEGA Presentation"

Exklusiv. Das sind doch xxx. Aber wirkliche xxx.

[BlacKi]

bin ja mal gespannt wie hoch später getaktet wird, wenn sie es schon auf die folie schreiben.

[Setsul]

Schon klar, aber wieso benötigt man dazu mehr Register?
Größere Wavefronts -> mehr Register, wenn die Anzah der WF ähnlich bleibt.

Aber jetzt zum Interessanteren:
128 SPs. Da haste deine höhere Leistung.
Wie wird jetzt die Aufteilung? Bei doppelter Größe lohnen sich auch entsprechende power saving features mehr.
Es bleibt spannend.

Wie vermutet: Ein binning Rasterizer der eventuell sogar mehr in den Tiles puffert als die nV-Lösung.
Noch mehr nVidia "kopieren". Nur besser. Das wäre schon höchst amüsant.
Oder schlechter. Das wäre auch höchst amüsant.

http://cdn.videocardz.com/1/2017/01/AMD-VEGA-VIDEOCARDZ-28.jpg
HOTCLOCK CONFIRMED ;D
Spaß beiseite, ein oder zwei Pipelinestufen mehr wären echt mal angebracht. Das Scheduling dürfte bei 128 SPs auch etwas aufgeblasen werden.

[Locuza]

Also die MI25 müsste bei 4096 ALUs entsprechend bei ~1,5 Ghz getaktet sein.
Das ist schon ein ordentlicher Uplift gegenüber Polaris der @ Stock unter 1,3 Ghz spezifiziert ist.

Die Consumer-Products können sich dann natürlich vom Takt unterscheiden, aber dank der MI25 denke ich schon das man hier mindestens 10% erwarten kann.

[fondness]

Normalerweise takten die Consumer-Karten ja höher als professionelle Karten. Von daher könnte man da schon in NV Regionen vorstoßen, P100 taktet ja auch ~1,5Ghz AFAIK.

[Sunrise]

Gefällt mir bisher alles was ich sehe und höre, ich denke NV wird überrascht. Der wirklich einzige Vorteil ist noch der deutlich höhere Takt bei Pascal, AMD wird bei vielem nicht nur aufholen. :wink:

[[MK2]Mythos]

Auch wenn es heute nur um die GPU Architektur geht, hoffe ich, dass wir auch was zum Stromverbrauch hören werden. 1080+X Leistung bringt mir nichts wenn das Teil trotzdem wieder knapp 300 Watt zieht.

[Gipsel]

Größere Wavefronts -> mehr Register, wenn die Anzah der WF ähnlich bleibt.Bisher hat man auch 64er Wavefronts, größer wird es nicht.
Aber jetzt zum Interessanteren:
128 SPs. Da haste deine höhere Leistung.
Wie wird jetzt die Aufteilung? Bei doppelter Größe lohnen sich auch entsprechende power saving features mehr.
Es bleibt spannend.Oder das mit den variablen Wavefrontgrößen war falscher Alarm.
Noch mehr nVidia "kopieren". Nur besser. Das wäre schon höchst amüsant.
Oder schlechter. Das wäre auch höchst amüsant.Seit Northern Islands und Fermi wurde darüber geredet, daß AMD da was machen muß. Dies ist nur die logische Entwicklung. Wie sich die Lösungen im Detail unterscheiden, wissen wir doch noch gar nicht. Außerdem hat es nV ja auch nicht gerade erfunden, die machen das auch nur nach ;). Und verschiedene andere Entwicklungen mit Maxwell und Pascal haben einige Sachen bei nV viel näher an GCN gebracht, als es noch bei Fermi und Kepler war.

[AffenJack]

Normalerweise takten die Consumer-Karten ja höher als professionelle Karten. Von daher könnte man da schon in NV Regionen vorstoßen, P100 taktet ja auch ~1,5Ghz AFAIK.

WX7100 und WX4100 takten doch ähnlich wie die Consumer-Karten, genauso Mi6 und Mi8. Ich gehe da von keinen großen Unterschieden aus.

[Troyan]

Und verschiedene andere Entwicklungen mit Maxwell und Pascal haben einige Sachen bei nV viel näher an GCN gebracht, als es noch bei Fermi und Kepler war.

Maxwell geht klar wieder in Richtung Fermi und hat nichts mit GCN zu tun. Es ist AMD, die sich sehr stark an nVidia anlehnen, da GCN nicht mehr konkurrenzfähig ist.

Das Osbornen von Polaris nach 6 Monaten zeigt doch, dass selbst AMD die alte Architektur aufgegeben hat.

[fondness]

Das NDA fällt laut den Folien übrigens um 9AM EST, das wäre also 15:00 Uhr unserer Zeit.

[[MK2]Mythos]

Das NDA fällt laut den Folien übrigens um 9AM EST, das wäre also 15:00 Uhr unserer Zeit.
Logisch, da ist ja auch die Präsi?

[MR2]

Das NDA fällt laut den Folien übrigens um 9AM EST, das wäre also 15:00 Uhr unserer Zeit.

Steht schon länger fest.
http://ve.ga/

[deekey777]

Um 15:00 ist aber auch mit Artikeln von gebrieften Redakteuren zu rechnen, darum wohl der Hinweis. Diese Folien sind für den Arsch.

[fondness]

Oh stimmt, sorry.

[Digidi]

Was ist Binning Rasterizer, klärt mich auf.

[Setsul]

@Gipsel:
Ich rechne jetzt nicht Register Overhead vs Occupancy vs Latency vs Utilization vs SIMD unit size vor.


Und ja, alles ist wieder offen.


"Kopieren" steht aus gutem Grund in Anführungszeichen. Wenns schlechter wird ist die Häme groß (Troyan geht schon in die Richtung), wenns besser wird werden sie wieder einige Kandidaten beschweren das sei eine Unverschämtheit und AMD solle sich gefälligst etwas eigenes ausdenken.

[fondness]

Das Argument ist doch maximal kindisch. Wie Gipsel schon sagte, gibt es entsprechende Lösungen die sogar noch weiter gehen als das was NV hat seit Jahrzehnten. Bereits Kyro Anno 2001 war ein TBLR, die ersten entsprechenden Chips gab es noch vor der Jahrtausendwende. Mich wundert es höchstens, dass beiden dieses Thema so lange ignoriert haben.

[Nakai]

Mhh, 128 SPs pro NCU? Dann also auch 8 TMUs pro NCU? Oder wird man die Anzahl der TMUs wieder reduzieren. Höchtwahrscheinlich nicht, da diese an die Load-Pipes gekoppelt sind.

Ahja dumme Frage?
Wo lest ihr das mit den 11 Tris/clk bei 4fach Frontend?
€: Ah, habs gefunden.

Ahja, vom Schaubild her, sieht Vega sehr nach einem TBDR aus. Das wird auch auf der Folie angedeutet. Der Aufbau sieht einem PowerVR-Chip schon ähnlich.

[[MK2]Mythos]

Die ganzen Kyro Patente wurden aber nie lizensiert, oder?

[deekey777]

Vielleicht steigt AMD wieder in den ULP-Markt ein, daher TBDR.

Das ist mein Ernst: Wenn Windows 10 für ARM-Geräte verfügbar wird, dann hätte AMD gleich was zu bieten. Und Nvidia. Vielleicht auch Intel.

[Botcruscher]

Das da wäre? Und warum sollen die genannten irgendwie auf W10 angewiesen sein? Wir warten mal auf W10 weil Andriod so schlecht läuft.:freak:

Mal sehen ob 15:00 wenigstens was zur Architektur kommt.

[M4xw0lf]

Mal sehen ob 15:00 wenigstens was zur Architektur kommt.
Hä? Die geleakten Slides behandeln doch die Architektur und sind Inhalt des um 15 Uhr ablaufenden NDAs.

[Botcruscher]

Ein wenig mehr Details dürfen es dann doch sein.

[M4xw0lf]

Halte ich für unwahrscheinlich. AMD hat ja nicht zu einem "Techday" geladen.

[deekey777]

Halte ich für unwahrscheinlich. AMD hat ja nicht zu einem "Techday" geladen.
Dann bringen diese Folien nichts.

[M4xw0lf]

Dann bringen diese Folien nichts.
Na zu den Folien werden sie schon ein paar erklärende Worte verlieren, aber wohl kaum fundamental darüber hinausgehen, das meine ich.

[deekey777]

Na zu den Folien werden sie schon ein paar erklärende Worte verlieren, aber wohl kaum fundamental darüber hinausgehen, das meine ich.

Mehr ist auch derzeit nicht nötig.

So, AMD setzt bei den NCU auf GeforceFX-Design (genauer NV40/G70): Zwei ALUs hintereinander. X-D

Diese Leaks sind Scheiße.

[Loeschzwerg]

https://www.heise.de/newsticker/meldung/AMD-zeigt-Ryzen-und-Vega-in-Aktion-3588751.html

Heise hat ein Video wo Doom @ 4k @ Ultra @ Vulkan auf Ryzen + Vega läuft (kurz wird auch auf die FPS Anzeige gezoomt).

[Isen]

Hier die bessere Variante davon, erkennt man die fps wenigstens fast durchgehend ^^

W0tZFOB98n0

[Gipsel]

Maxwell geht klar wieder in Richtung FermiNein. Der Aufbau der SMs und das Scheduling funktioniert völlig anders als bei Fermi und nV geht prinzipiell sehr wohl viel mehr in die Richtung wie GCN (kein Scoreboarding für arithmetische Instruktionen, feste und deutlich niedrigere Latenzen, Result forwarding, statisches Scheduling, dependency counter). Alles schon mehrfach diskutiert.

[Tru]

AMD VEGA Präsentation:
[url]http://videocardz.com/65406/exclusive-amd-vega-presentation[/url
Gnarf.

Edit: Natürlich geben die Folien schon das meiste wieder. Man muss ja im Hinterkopf behalten, dass in Sonoma (ein Tag + wenige Stunden vom nächsten) nicht nur Vega, sondern auch noch (Ry-)Zen und Freesync 2 behandelt wurden. Wahnsinnig viel Zeit bleibt da nicht mehr.

[[MK2]Mythos]

Hier die bessere Variante davon, erkennt man die fps wenigstens fast durchgehend ^^

http://youtu.be/W0tZFOB98n0
Um das mal in Relation zu setzen, eine Maxwell Titan X liegt im Schnitt 10 fps darunter bei den Settings.

[KORE]

Hier die bessere Variante davon, erkennt man die fps wenigstens fast durchgehend ^^

http://youtu.be/W0tZFOB98n0

Hoffen wir mal für Vega das Doom im CPU-Limit war. XD