AMD/ATI - VEGA (Vega10, Vega11, Vega12, Vega20) - 2017 [Archiv] - Seite 8

Leonidas

2017-01-16, 23:59:40

HOT

2017-01-17, 00:56:57

Hm, wenn man davon ausgeht, dass AMD superfrühes Sample schon mit 1,5GHz lief, dürfte das Endprodukt deutlich höher takten. Ich denke eher, Vega ist sowas wie AMDs Maxwell. Effizienter in Speicherbandbreite, ALU-Auslastung und Takt. Dafür nimmt man sicher gern etwas größere Chips in Kauf - wie bei Maxwell.
8TFLOPs für V11 wär aber einfach zu nah dran, wenn man damit rechnet, dass P10 als P10XT2 auf einer RX580 zum Einsatz kommen drüfte mit ca. 1,4GHz, was die reine Rechenleistung schon verdammt nah daran bringen würde. Ich denke eher, dass P10XT2 6,5TFLOPs bringen wird, V11XT ca. 9,5 und V10XT eher so 14. Die 12TFLOPs galt sicher nur für die professionelle V10-Variante. Auch Hawaii ist deutlich niedriger getaktet als FirePro-Variante und hat dennoch eine höhere TDP.

Leonidas

2017-01-17, 01:34:24

Ich hab bezüglich V10 meine Erwartungen etwas runtergeschraubt. Die AMD-Folie sagt 12 TF. Die MI25 soll 12,5 TFlops haben - aber dafür bei 300W und passiver Kühlung. Ich vermute da einen eher hochgezogenen Max-Takt und dafür die hohe TDP. Hinzu kommt der Effekt, das für GPGPU-Einsatz diverse Einheiten brach liegen und damit die TDP kaum belasten - Platz für Mehrtakt.

Ob man es mit Hawaii vergleichen kann, bin ich unsicher. Der war von Haus aus ein Hitzkopf, deswegen musste man da mit dem Takt für die Profi-Versionen runter. V10 würde ich nicht so grenzwertig einschätzen.

D.h. Gaming-Lösungen von V10 doch eher mit leicht niedrigerem Takt, normaler TDP auf 250W (oder 225W) und damit 12 TF. Das man Vorab-Aussagen deutlich überbietet, passiert eher selten.

Es passiert natürlich trotzdem ab und zu mal. Wenn V10 auf 14 TF kommt, würde ich auch V11 höher einschätzen (Deine 9,5 TF sind eine gute Annahme). Allerdings gehe ich nicht davon aus, das P10 auf mehr kommt. Das drückt nur den Stromverbrauch nach oben. Wenn, dann bräuchte man dafür in jedem Fall ein neues Stepping mit wirklich verbesserten Stromverbrauchs-Eigenschaften.

Screemer

2017-01-17, 07:19:18

Oha. Gleiche semantik wie troyan? <300W = 300W.

Ailuros

2017-01-17, 07:29:25

Oha. Gleiche semantik wie troyan? <300W = 300W.

Nochmal da es sich um board form factor handelt ist es ziemlich wurscht ob man <300 oder 300W angiebt. Mehr als 250 sind es allemal.

--------------------------------------------------------------------------------------

Leo,

Der kleinere Vega muss nicht unbedingt so wenig clusters haben. Sonst gewinnt ingesamt V10 sehr gering vom Takt im Vergleich zu Polaris als desktop SKU; die brutale Mehrzahl kommt von der Architektur selber.

krötenfresse

2017-01-17, 11:15:39

wird nur vega mit gcn5 auch freesync2 unterstützen?

ich plane mir noch dieses jahr nen neuen moni zu kaufen.

Gipsel

2017-01-17, 11:19:47

wird nur vega mit gcn5 auch freesync2 unterstützen?Nein. FreeSync2 wird ab Bonaire unterstützt, genau wie FreeSync.

BoMbY

2017-01-17, 11:21:14

D.h. Gaming-Lösungen von V10 doch eher mit leicht niedrigerem Takt, normaler TDP auf 250W (oder 225W) und damit 12 TF. Das man Vorab-Aussagen deutlich überbietet, passiert eher selten.

Ich finde es immer wieder extrem lustig, dass so viele Leute denken dass eine Gaming-Karte gleiche, oder sogar weniger, Frequenz/Flops haben soll, als eine semi-passiv gekühlte Computing Karte. :rolleyes:

Deswegen hat auch die FirePro S9300 X2 13.9 TFLOPs, und die Pro Duo 16.4 ...

tm0975

2017-01-17, 11:28:45

Botcruscher

2017-01-17, 11:32:26

:confused:
Es ist doch eher umgekehrt. Der Profibereich ist eher auf Stabilität, TDP oder Baugrößen ausgelegt und hat deswegen weniger Takt.

iuno

2017-01-17, 14:10:06

Ich finde es immer wieder extrem lustig, dass so viele Leute denken dass eine Gaming-Karte gleiche, oder sogar weniger, Frequenz/Flops haben soll, als eine semi-passiv gekühlte Computing Karte. :rolleyes:

Deswegen hat auch die FirePro S9300 X2 13.9 TFLOPs, und die Pro Duo 16.4 ...
Einfach mal nicht alten dual GPU Krempel anschauen, sondern was so aktuell ist und auch zum Thema passt:
R9 Nano: 8,3 TF bei ~175 W, MI8: 8,2 TF bei "<175W"
RX 480: 5,8 TF bei "150 W" (= 165 W), MI6: 5.7 TF bei "<150W", uebrigens ebenfalls passiv.
Zumal die Peak-Werte, wie man auch an der Nano sieht, ohnehin eher theoretischer Natur sind.

wenn selbst die nano bei ca. 900 mzh bei um die 175 watt bleibt in 28 nm, dann wird dieselbe anzahl an wenn auch gcn5-rechenknechten bei 1,5 ghz wohl kaum 300 watt veranschlagen. das glaubt doch nicht wirklich jemand, oder? taktausgereizt werden es vielleicht max. 225
Je nach Last sind es bei der Nano uebrigens auch mal deutlich unter 900 MHz bei 180 Watt aufwaerts. Ich weiss auch nicht was es soll, hier die Nano heranzuziehen. AMD wird mit Vega ordentlich Performance liefern, aehnlich der Fury X. Und die lag bei 1050 MHz ungedrosselt (ootb) einfach mal bei 350-450 Watt. Ob noch eine Nano nachkommt, ist dabei relativ nebensaechlich.
Eine 470 schluckt bei 1,4 GHz auch mal 250 Watt. AMD muss es erstmal hinbekommen, deutlich hoehere Taktraten bei anstaendigen Spannungen fahren zu koennen. Der Wechsel auf FinFET alleine bringt es halt nicht. Und solange da nicht sicher ist, dass sie das endlich in den Griff bekommen haben, bleibt es fuer mich bei 300 W.

BoMbY

2017-01-17, 14:28:18

Solange Vega 10 ungefähr die doppelte Leistung wie Fiji XT bringt, kann es gerne auch wieder 275W TDP haben.

Die Nano funktioniert nur wegen dem harten TDP limit. Die Fury X läuft bei Furmark auch ins TDP Limit und taktet runter.

Die semi-passive FirePro S9300 X2 mit 13.9 TFLOPs hat 2x Fiji XT, und werden mit 300W TDP angegeben. Für genau diese Karte wäre die MI25 ein Ersatz, und wird vermutlich etwa 225W TDP haben, aber gleiche (bzw. im Detail bessere) Leistung mit nur einem Chip bringen.

Ich denke man kann recht sicher von 275W TDP von der Gamer Vega 10 ausgehen, mit etwas mehr, und etwas stabilerem Takt. Da kommt man dann bei ungefähr 15 TFlops raus, was etwa Fiji mit 1835 MHz entsprechen würde.

tm0975

2017-01-17, 14:31:08

Je nach Last sind es bei der Nano uebrigens auch mal deutlich unter 900 MHz bei 180 Watt aufwaerts. Ich weiss auch nicht was es soll, hier die Nano heranzuziehen. AMD wird mit Vega ordentlich Performance liefern, aehnlich der Fury X. Und die lag bei 1050 MHz ungedrosselt (ootb) einfach mal bei 350-450 Watt. Ob noch eine Nano nachkommt, ist dabei relativ nebensaechlich.

800 mhz sind einzelfallnegativbeispiele. meine nano kratzt regelmäßig an den 1000 mhz, freilich nicht konstand. deine wattzahlen entsprechen welchen messungen? mein powertarget ist etwas heruntergesetzt. die nano setze ich wegen der anzahl der shader und dem hbm speicher entgegen. die paar % mehrleistung der fury x interessieren mich persönlich nicht.

Der Wechsel auf FinFET alleine bringt es halt nicht. Und solange da nicht sicher ist, dass sie das endlich in den Griff bekommen haben, bleibt es fuer mich bei 300 W.
es steht dir frei, die verbrauchsunterschiede zwischen einer 470 und einer 380x zu messen und dir abzäglich speicher und pcb den stromverbrauch anzuschauen und dann hast du dir deine frage bzgl. glofos 14nm verbeserungen selbst beantwortet.

iuno

2017-01-17, 14:59:19

Messungen gibt es bei Igor. Der durchschnittliche Spieleverbrauch ist halt auch nicht direkt vergleichbar mit konstant ueber laengeren Zeitraum anliegender Compute Last und dafuer wird die Serie gebaut. Und was uns persoentlich interessiert, juckt AMD leider kein Stueck. Fuer mich war auch die Nano der Star der Fiji Serie, leider kam da halt erstmal gar nichts. Da gab es nur die X mit AiO, Monate spaeter dann die Nano in kleinen Stueckzahlen. Bei Polaris war es dasselbe Spiel; im Prinzip ordentlich, aber nicht "richtig" eingestellt. Man muss ums Verrecken die 1060 schlagen, verbraucht mehr und handelt sich dann auch noch den "Skandal" ein. Danach kamen dann noch Radeon Pros, die es etwas besser gemacht haben. Ich gehe daher davon aus, dass sie es mit Vega genauso angehen. Das Teil wird relativ am Limit laufen.

Ich habe ueberhaupt keine Frage gestellt. Mir ist voellig klar, dass AMD FinFET alleine nicht reicht, das haben wir alle schon gesehen. Uebrigens auch schon vorher. Maxwell hat den Takt im selben Fertigungsverfahren deutlich hochgezogen, ohne laecherlich hohe Spannungen fahren zu muessen, sodass der Verbrauch durch die Decke geht. Bei AMD bringt Undervolting nach wie vor zu viel, Uebertaktungspotenzial fehlt im direkten Vergleich trotzdem.
Ich hoffe ja auch, dass sie das in den Griff bekommen, bleibe aber bis dahin einfach vorsichtig.

Bei Fiji wurde uebrigens mitunter genau dasselbe gesagt; HBM, neue GCN Iteration, wieso soll das Teil so viel verbrauchen wie Hawaii? Gelandet ist man sogar noch deutlich darueber.

BlacKi

2017-01-17, 15:05:32

endlich sagt das mal jemand! das auswürfeln von möglichen spezifikationen auf der basis wissentlich falscher annahmen empfinde ich immer als ziemlich anstrengend.

und die 300 Watt nerven auch langsam. klar wird v10 möglicherweise mit den entsprechenden stromanschlüssen kommen. aber wenn selbst die nano bei ca. 900 mzh bei um die 175 watt bleibt in 28 nm, dann wird dieselbe anzahl an wenn auch gcn5-rechenknechten bei 1,5 ghz wohl kaum 300 watt veranschlagen. das glaubt doch nicht wirklich jemand, oder? taktausgereizt werden es vielleicht max. 225, bei sinnvollem takt dual v10 bei 300 watt.
auch wenn es nur ein prototyp war, aber der stromanschluss sagt mir eigentlich das es nicht mehr wie 225w werden. vl sind es sogar wirklich um die 225w, aber nicht mehr, eher weniger. welchen grund soll für 250w oder mehr sprechen?

=Floi=

2017-01-17, 15:27:29

1500mhz und die 12,5TFlop

Ich denke in diese richtung wird man auf jedenfall gehen, um auf dem papier nv unter druck zu setzen. wenn der chip die 1500 schafft, wird man sicherlich auch so eine karte bringen. Es spricht aber auch nichts gegen eine zweite 225watt version.

die 300wat sind super, weil so der boost takt wesentlich länger gehalten werden dürfte. für 2 min im startbildschirm bringen mir die 1500mhz nichts.

Dino-Fossil

2017-01-17, 15:35:17

Der Einzige Hinweis auf die 300W entspringt ja der professionellen Compute-only Karte auf Basis von Vega. Damit läge AMD rein von den offiziellen Angaben bei Perf./Watt im Profi-Bereich praktisch gleichauf zu nVidia.

Im Gaming-Segment ist hingegen alles offen, auch wenn man vielleicht vermuten könnte, dass Vega etwas schlechter abschneiden wird als Pascal, einfach schon weil AMD vermutlich keine separaten Gaming- und Profi-Chips auflegt, so wie nVidia das tut (womit man etwas mehr "Ballast" herumschleppt).

BoMbY

2017-01-17, 15:55:14

Der einzige Hinweis sind < 300W auf der neuen Folie und 225W für 12 TFlops auf der Folie aus dem September:

http://i.imgur.com/ggcLncB.jpg

Und nein, im Gegensatz zu WCCFtech ist Videocardz bisher eher nicht durch falsche Informationen aufgefallen. Und alle Angaben auf den Folien (http://videocardz.com/65521/amd-vega-10-and-vega-20-slides-revealed) machen im Kontext Sinn.

Agent117

2017-01-17, 16:15:04

Das sind doch die gefälschten Folien. Die sehen ja schon richtig grottig aus.
Die Daten hinter den Folien sollen aber zum Großteil stimmen, aber eben nicht alles. Gerade bei Vega 20 steht da viel Mist. Dass es Navi 10 und 11 geben soll ist vmtl. auch nur eine Vermutung des Erstellers.

Edit: ich sehe gerade da fehlt ja sogar jede Spur von FP8. Das hätte AMD sicher mitdraufgepackt wenn man doch sonst so oft von Deep Learning usw. spricht.

BoMbY

2017-01-17, 16:20:28

Locuza

2017-01-17, 16:22:01

Es ist nicht FP8, sondern Int8.

Ailuros

2017-01-17, 16:28:55

Es ist nicht FP8, sondern Int8.

....und es ist sehr wohl verdammt relevant heutzutage fuer professionelle Loesungen und es wird natuerlich auch ziemlich wichtig fuer VEGA sein.

Locuza

2017-01-17, 16:32:43

Jep, aber das fehlen der Angabe muss nicht unbedingt heißen das die Folien gefälscht sind.
Bei V10 stimmen alle Details nahezu überein, wobei man argumentieren könnte, dass jemand einfach plausible Vermutungen drauf geschrieben hat, aber HW Page Management ist ein Detail das vermutlich nicht einfach so erraten werden konnte.

BoMbY

2017-01-17, 16:40:38

....und es ist sehr wohl verdammt relevant heutzutage fuer professionelle Loesungen und es wird natuerlich auch ziemlich wichtig fuer VEGA sein.

Lol, nein. Niemand und nichts kann überhaupt mit FP8 umgehen. Das ist alles theoretisch, und für 99% der Anwendungszwecke ist die Genauigkeit total unbrauchbar. Deswegen gibt es auch überhaupt keine IEEE-Spezifikation für FP8.

Locuza

2017-01-17, 16:44:33

Er führt meinen Beitrag weiter aus, wo ich geschrieben habe, dass es um Int8 geht und nicht FP8.
Die 512 8-Bit OPs bei der Vega Vorschau bezogen sich auf Int8.

Ailuros

2017-01-17, 16:47:40

Lol, nein. Niemand und nichts kann überhaupt mit FP8 umgehen. Das ist alles theoretisch, und für 99% der Anwendungszwecke ist die Genauigkeit total unbrauchbar. Deswegen gibt es auch überhaupt keine IEEE-Spezifikation für FP8.

Nochmal es ist INT8 (INT fuer integer) und kein floating point. Alles dass mit computational photography bzw. vision applications zu tun hat (u.a. deep learning) profitiert von zusaetzlichen integer arithmetic Faehigkeiten und diese wurden auch beim VEGA aufgepumpt. Aber danke fuer die Unterhaltung allemal :P

Dino-Fossil

2017-01-17, 17:07:16

Das sind doch die gefälschten Folien. Die sehen ja schon richtig grottig aus.

Die (<)300W der MI25 kommen auch auf anderen Folien vor, die durchaus offiziell sind.

Edit: Aber wie gesagt - das sind Werte für die professionellen Karten, die nicht unbedingt Rückschlüsse auf Gaming-Varianten ermöglichen.

Ailuros

2017-01-17, 17:11:45

Wen es interessiert sollte Wavey eine PM bei B3D schicken, um zu fragen wie sie solche Werte in seiner Abteilung behandeln. AMD vermarktet mit board form factor und wenn es 2*8pin sind wird auch irgendetwas 300W dafuer angegeben, egal wie viel es am Ende verbraucht.

BoMbY

2017-01-17, 17:24:49

Wenn Ihr 8-bit Integer meint, solltet Ihr nicht 8-bit float sagen. Das auf der Folie nur von Float gesprochen wird, und nicht von Integer, heißt jedenfalls nicht, dass sie falsch ist.

Ailuros

2017-01-17, 17:33:51

Wenn Ihr 8-bit Integer meint, solltet Ihr nicht 8-bit float sagen. Das auf der Folie nur von Float gesprochen wird, und nicht von Integer, heißt jedenfalls nicht, dass sie falsch ist.

Ich hab persoenlich nirgends etwas von "FP8" erwaehnt. Mir ging es auch nicht um die Folie.

HOT

2017-01-17, 19:55:16

Die (<)300W der MI25 kommen auch auf anderen Folien vor, die durchaus offiziell sind.

Edit: Aber wie gesagt - das sind Werte für die professionellen Karten, die nicht unbedingt Rückschlüsse auf Gaming-Varianten ermöglichen.
Man darf ja auch nicht vergessen, dass die, wenn die Karten voll mit 2x FP16 pro CU voll ausgelastet sind, deutlich mehr Energie verbraten dürften, also wenn die FP32 (oder später vielleicht auch mal teilweise mit FP16)-Spiele berechnen. Die höhere TDP ist sicherlich der anderen Workloads geschuldet. Auch der Turbo dürfte bei den professionellen Karten anders arbeiten.

Die Instinct MI25 ist ein reiner Rechenprozessor, während die auf der Folie (und sicherlich gemeinte) abgebildete Karte eine RadeonPro ist, das sind zwei völlig unterschiedliche Produkte.

MI25: 1,5GHz @300W aber völlig ohne Energiebeschränkung bei Vollauslastung mit 24 TFLOPs FP16 oder 48 TIOPs Int8
RadeonPro V10: 1,5GHz @225W
RadeonRX V10: 1,7GHz+ @250-275W
Das wär meine Einschätzung. Die Pro-Varienten sind für Gewöhnlich 5-15% niedriger getaktet als die Gamerkarten, das wird jetzt ganz sicher nicht anders sein. Die 12TFLOPs galten bislang stets für die Profikarten, dann werden die Gamerkarten sicherlich bei 14TFLOPs landen.

Foobar2001

2017-01-17, 19:58:24

FP16 Pairs sind weniger Arbeit als FP32. Multiplier-Größe ist quadratisch mit der Breite.

aufkrawall

2017-01-17, 20:07:10

Foobar2001

2017-01-17, 20:43:29

Du irrst dich.

aufkrawall

2017-01-17, 20:58:54

Und wobei bitte? Willst du trollen?

iuno

2017-01-17, 20:59:25

Womit denn genau?
Du willst nicht bestreiten, dass es Spiele gibt, wo Fiji auch mal extrem viel verbraucht und dennoch nicht aussergewoehnlich schnell ist oder?

Beispiel auf die Schnelle: das System mit der Fury X braucht bei CB (https://www.computerbase.de/2016-06/radeon-rx-480-test/9/#diagramm-leistungsaufnahme-des-gesamtsystems-star-wars-battlefront) verglichen mit der 980 Ti in SWBF ueber 100 W mehr, bei XCOM sind es nur noch 60W Differenz. Der Unterschied in der Performance ist aber quasi derselbe.

horn 12

2017-01-17, 21:10:11

iuno

2017-01-17, 21:13:28

Verbrauch heisst Krach, Hitze, Drosselung, weniger bleibendes Potenzial... und ja, fuer einige spielt das durchaus eine Rolle, nicht nur in Deutschland. Wenn man irgendwann mal wieder in die Top(/Green)500 will, uebrigens auch :P Das hatten wir alles oft genug hier, wir muessen hier nicht wieder beim kleinen 1x1 anfangen.

davidzo

2017-01-17, 21:25:18

Ui, immer der Verbrauch bei unseren Deutschen und Vielen Europäern.
Da müssten wohl alle eine GTX 1050 bzw. RX 460 kaufen
Sicher auch Wichtig der Verbrauch, aber da gibt es weitaus Wichtigeres oder zockt hr Alle 10+ Stunden am Tag Außer vielleicht an den Wochenenden mal die 4+ Stunden am Stück... ?

Mich interessiert neben der praktischen Leistung irgendwie auch immer was die bessere Architektur ist, die effizientere und modernere. Ich bin ein permanenter optimierer, ich finde es geil "die fortschrittlichste Architektur" zu haben und nicht nur einfch brute force.
Und irgendwie sind wir das doch alle hier, wieso würden wir sonst Abende verbringen und darüber spekulieren was als nächstes herauskommt?

Brauchen wir einfach nur möglichst viel Spieleleistung geht man in den Laden und kauft ne aktuelle Titan, dann muss man sich nicht weiter damit beschäftigen. Wenn es wirklich darum geht Spiele flüssig zu spielen, wären uns 10% mehr oder weniger auch egal, da das zwar mit Framecountern messbar ist, aber wohl kaum einen harten Unterschied zwischen Spielbar und unspielbar ausmacht.

Uns geht es hier nicht um die praktische Spieleleistung, uns geht es um das theoretische der Architektur. Und da ist (Energie-) Effizienz nunmal mit das Interessanteste wenn eine neue Architektur kommt!

Ex3cut3r

2017-01-17, 21:53:38

Stark comment davidzo :up:

AMDler reden nur nocht nicht gerne über Effizienz ist einfach nicht deren stärke, weder bei den CPUs noch bei den GPUs *duck und weg* :biggrin:

basix

2017-01-17, 21:58:41

Stark comment davidzo :up:

AMDler reden nur nocht nicht gerne über Effizienz ist einfach nicht deren stärke, weder bei den CPUs noch bei den GPUs *duck und weg* :biggrin:

Wahr ist es im Vergleich zu den direkten konkurrenten im Consumer Markt. Aber das ändert sich ja bald ;D

Gipsel

2017-01-17, 22:06:20

Wenn die Recheneinheiten bei GCN wirklich voll ausgelastet waren, ging der Verbrauch bisher immer durch die Decke. Sofern die Recheneinheiten also nicht einen effektiven Umbau zur Effizienzverbesserung erfahren haben, würd ich von eher hohem Verbrauch ausgehen. Besonders, wenn die Auslastung allgemein erhöht sein sollte.
Bei Fiji hatte man gesehen, dass die effizientere Bandbreite durch HBM nur die halbe Miete ist und deshalb bei einigen Spielen der Verbrauch in Relation zur Performance trotzdem grotesk hoch sein konnte.
Du irrst dich.
Und wobei bitte?
Vermutlich damit, daß der Stromverbrauch bei Vollauslastung der ALUs am Anschlag ist. Datenbewegungen auf dem Chip kosten auch viel Power im Vergleich zu den eigentlichen Rechnungen. Zur Maximierung des Stromverbrauchs sollte man also nicht nur die ALU-Auslastung maximieren, sondern dies möglichst auch mit möglichst großen Instruktionen mit jeweils 4 Argumenten machen, parallel den LDS und die TMUs auslasten und dabei noch kräftig die ROPs und das Speicherinterface quälen.
Die Bandbreiteneffizienz zu erhöhen (nicht nur extern, sondern durch geeignete hierarchisch aufgebaute Caches auch intern) hilft also der Energieffizienz ebenso (wenn nicht mehr), wie Tuning der ALUs.

Foobar2001

2017-01-17, 22:07:33

Und wobei bitte? Willst du trollen?
Damit das dual rate FP16 mehr Strom verbraucht als FP32. Macht null Sinn wenn man versteht was eigentlich passiert.

HOT

2017-01-17, 22:48:08

Es ging damit auch eigentlich um die optimale Auslastung aller CUs. Ob das mit 2x FP16 einfacher ist war ein Schluss, aber ein falscher.
Das Problem bleibt aber. Bei der Instinct dürfte die Vollauslastung die TDP beeinflussen.

Screemer

2017-01-17, 23:02:56

Doom mit vulkan zeigt aber doch nicht wirklich Auffälligkeiten bei der Leistungsaufnahme, oder?

iuno

2017-01-17, 23:04:35

Doom verbraucht nicht ausserordentlich viel bzw. laeuft ja auch dementsprechend schneller. Das Seltsame sind ja Spiele, die Stromfresser sind, aber trotzdem "langsam" (/normal) laufen.
Damit das dual rate FP16 mehr Strom verbraucht als FP32.
Du hast dich glaub beim User vertan.

Screemer

2017-01-17, 23:08:26

Ich sollte aufmerksamer lesen.

Nicht:
instincts dürften die Vollauslastung und die TDP beeinflussen.

Sondern:
Bei der Instinct dürfte die Vollauslastung die TDP beeinflussen

:ugly: gn8

Locuza

2017-01-18, 00:54:44

Besser spät als nie, aber Charlie hat wieder ein technisches Masterpiece zu Vega geschrieben:
http://semiaccurate.com/2017/01/17/amd-talks-vega-high-level/

Einige Auszüge:
It is called the Primitive shader and it is lumped under the heading of New Programmable Geometry Pipeline. The old way of doing things was to have separate pixel, vertex, and geometry shaders fed by a compute engine (ACE) or geometry command processor (GCP).
Now we come to the Next-Generation Compute engine or NCU.[...]
Actually they listed it at 512 8b ops or 256 32b ops per clock with a configurable DP rate. This one is interesting because if they are calling the NCU the replacement for an ACE, that would mean the listed rate is per unit. If you recall Fiji/Fury had eight ACEs, Vega will likely have more. This number puts the device in perspective unless AMD is calling an NCU a shader group, then the numbers make a lot more sense but the higher level bits don’t.
Like it’s Polaris predecessors, Vega can do 2x 16b ops per clock or one 32b op, the non-packed 16b math is kind of useless but legacy code likely demands it’s use of opcode space.
Officially the claim is that this change will help a lot with deferred shading but it opens the door to a lot of hacks. What those hacks will be are yet to be seen, but a large universal L2 cache is never a bad thing for software trolls.

Foobar2001

2017-01-18, 01:06:51

Polaris kann kein dual rate FP16.

Locuza

2017-01-18, 01:08:48

Hübie

2017-01-18, 01:26:22

Polaris kann kein dual rate FP16.

Genau das dachte ich auch beim Lesen, aber war mir dann nicht mehr sicher. Na ja kein Artikel ohne Patzer von Charlie. Liest sich schon mal interessant. Leider sind immer noch viele Fragen offen.

iuno

2017-01-18, 01:42:47

NCU ist auch kein replacement fuer ACE, schreibt der immer solchen Muell?

Locuza

2017-01-18, 01:53:14

rentex

2017-01-18, 05:55:39

Mich interessiert neben der praktischen Leistung irgendwie auch immer was die bessere Architektur ist, die effizientere und modernere. Ich bin ein permanenter optimierer, ich finde es geil "die fortschrittlichste Architektur" zu haben und nicht nur einfch brute force.
Und irgendwie sind wir das doch alle hier, wieso würden wir sonst Abende verbringen und darüber spekulieren was als nächstes herauskommt?

Brauchen wir einfach nur möglichst viel Spieleleistung geht man in den Laden und kauft ne aktuelle Titan, dann muss man sich nicht weiter damit beschäftigen. Wenn es wirklich darum geht Spiele flüssig zu spielen, wären uns 10% mehr oder weniger auch egal, da das zwar mit Framecountern messbar ist, aber wohl kaum einen harten Unterschied zwischen Spielbar und unspielbar ausmacht.

Uns geht es hier nicht um die praktische Spieleleistung, uns geht es um das theoretische der Architektur. Und da ist (Energie-) Effizienz nunmal mit das Interessanteste wenn eine neue Architektur kommt!

Jupp, das ist mir ebenfalls wichtig und finde es interessant.

Ailuros

2017-01-18, 07:25:59

Er tut das auf jeden Fall häufiger, sein technisches Verständnis und write-up scheint sich seit einem Jahrzehnt nicht weiter zu entwickeln.
Das einzige wofür er und die Seite gut ist, sind einige interessante Infos-Leaks, die manchmal stimmen, manchmal nicht (Semi Accurate muss ja erfüllt werden).
Ich habe gehofft das beim Vega Artikel vielleicht etwas interessantes erwähnt wird, aber es ist größtenteils selbst interpretierte Grütze mit falschen Informationen.

Es ist zwar OT aber da ich von Zeit zu Zeit mit ihm privat plaudere hat er schon seine Quellen und die Fetzen die er abbekommt sind dann auch meistens korrekt. Das Problem liegt dann eher bei der Interpretation der Fetzen bzw. einzelne kleinere Details in ein plausibles spekulatives Puzzle zusammenzufuegen.

Bei CPUs bzw. GPU writeups geht es ja noch halbwegs. Wenn er sich aber auf irgend ein ULP SoC Glatteis z.B. wagt wird es um zich mal tragischer und es ist fuer ihn selber eine Schande denn das Potential hat er schon, es ist wohl eher irgendwelche Faulheit bzw. Arroganz oder eine Kombination dieser die ihn davon abhaelt sich auf dem laufenden zu halten.

Er ist aber auch leider nicht der einzige dort draussen. Ich hab gerade mal wieder etwas von einem Anandtech Kerl gelesen wo sich mir das Fell straeubte.....

mksn7

2017-01-18, 12:29:29

Inwiefern helfen L2 backed ROPs bei Deferred Rendering? Ich hab das jetzt schon mehrmals gelesen, aber der angedeutete Mechanismus macht für mich keinen Sinn.

reaperrr

2017-01-18, 12:56:05

Er ist aber auch leider nicht der einzige dort draussen. Ich hab gerade mal wieder etwas von einem Anandtech Kerl gelesen wo sich mir das Fell straeubte.....
Das extremste Beispiel ist für mich nach wie vor Fudo.

Unicous

2017-01-18, 13:05:58

Das extremste Beispiel ist für mich nach wie vor Fudo.

Der Unterschied zu Fudzilla ist aber, dass AT eine renomierte IT-Seite ist die sich in letzter Zeit aus Ermangelung an Schreibern so manche Kröte ins Boot geholt hat und trotzdem es nicht schafft Reviews zu aktueller hardware zu veröffentlichen.

Fudzilla hingegen ist nichts weiter als ein Boulevardblatt ohne tiefergehende Artikel, dafür aber mit dem ein oder anderen scoop. Dass dabei auch viel Quatsch rauskommt und die Einordnung ins Gesamte entweder vollkommen daneben ist oder der Quelle überlassen wird ist daher nicht verwunderlich.

Dass AT sich so gehen lässt, hätte ich nicht erwartet. Auch Techreport hat unter dem Abgang von Scott Wasson (u.a.) zu leiden, so richtig gut ist es aktuell um den amerikanischen IT-Journalismus jedenfalls nicht bestellt.

Ailuros

2017-01-18, 13:54:35

Das extremste Beispiel ist für mich nach wie vor Fudo.

Ein Faulenzer kann sich eventuell aufkrempeln und doch noch etwas liefern; bei sturer Dummheit laesst sich nichts mehr anrichten :weg:

fondness

2017-01-18, 18:53:10

I-wFVIlMY_0

Interview mit Scott Wasson über Vega. Er verkündet natürlich keine neuen Infos, er sagt aber, dass Vega zum einen einige Feature hat, die erst in Games implementiert werden müssen und zum anderen das es noch einige Features gibt, die bis jetzt noch nicht veröffentlicht wurden.

BlacKi

2017-01-18, 19:17:13

zb. das mit dem effizienteren nutzen des speichers. ähnlich wie mantle oder AC wird die verbreitung zu wünschen übrig lassen, und ob man es wirklich benötigen wird ist dabei auch nicht sicher. zum glück ist dieses feature auch nicht absolut nötig.

Gipsel

2017-01-18, 19:48:02

Inwiefern helfen L2 backed ROPs bei Deferred Rendering? Ich hab das jetzt schon mehrmals gelesen, aber der angedeutete Mechanismus macht für mich keinen Sinn.Deferred Renderer können einen relativ großen G-Buffer haben und fressen dann mitunter merklich Bandbreite (weswegen es eventuell als Beispiel herausgestellt wurde, keine Ahnung, vielleicht fällt Foobar oder irgendwem Anderen was ein). Hier hilft dann (nicht nur der Draw Stream Binning Rasterizer sondern auch) die erhöhte effektive Cachegröße, Speicherbandbreite zu sparen. Außerdem muß man wohl die Caches zwischen den Passes nicht flushen, was noch mal ein wenig zusätzlich bringen könnte. Alles Folgende gilt aber ganz allgemein.

Es gibt ein älteres Paper von Mike Houston, was den Zusammenhang zwischen Cachegröße, Blockgröße der Framebufferkompression und der Bandbreitenersparnis untersucht. Daraus kommt folgende Tabelle (die genauen Werte unterscheiden sich natürlich je nach Anwendung, kann also nur die grobe Richtung vorgeben):
https://abload.de/img/cache_tile_size_comprt0jss.png

Cachegröße, Hit- und Miss-Rate sind selbsterklärend. Tile Size gibt die Kantenlänge der Blöcke des Kompressionsalgorithmus an (die immer komplett geladen und geschrieben werden; 4 bedeutet 4x4 Pixel große Blöcke, 8 bedeutet 8x8 Pixel Blöcke) und Break Even die erforderliche Kompressionrate, um überhaupt eine Bandbreitenersparnis zu haben. Liefert der Kompressionsalgorithmus im Mittel weniger als das, so erhöht sich trotz Kompression der letztendliche Bandbreitenbedarf sogar. Im Prinzip will man etwas größere Tiles benutzen, weil das die Kompressionsrate tendentiell erhöht. Bei einem Cache Miss, hat man dann allerdings mehr potentiell ungenutzte Daten zu kopieren, was den Overhead vergrößert (und wird das zu groß, benötigt man mehr Bandbreite als ohne Kompression). Große Tiles (mit hoher Kompression) sind also nur bei großen Caches mit hoher Hitrate sinnvoll. Praktisch wird dies noch durch die Größe der Cachelines verkompliziert, weil man immer 64Byte-Cachelines am Stück schreibt. 4x4 Tiles sind also praktisch gesehen hierfür wenig sinnvoll.

AMD GPUs haben bisher in jedem Render-Backend (Gruppe aus 4 ROPs) einen relativ kleinen Tilecache von 16kB für den Color-Buffer und 4kB für Z-Buffer, die direkt am Speichercontroller hängen, was demzufolge die Effizienz der Framebufferkompression limitiert. Bei Vega soll es neben dem L1-Cache für das Pixel-Backend (vermutlich bleiben also kleine Caches in den ROPs) das Ganze vom L2 unterstützt werden. Dies ermöglicht es zum einen, auf gerade geschriebene Framebufferdaten ohne Umweg über den VRAM zuzugreifen (über den L2) als eben auch die effektive Cachegröße massiv zu erhöhen und somit zum einen größere Tiles zu erlauben (was die Kompression der Tiles erhöht) und auch die Cache-Hitrate zu erhöhen, was eben die Speicherbandbreitenanforderungen senkt.
Der Tiling Rasterizer hilft hier übrigens zusätzlich, weil man die Lokalität der Zugriffe und somit auch die Cache-Hitrate unter Umständen deutlich erhöht (das eigentliche "Geheimnis" der niedrigeren Bandbreitenaforderung der Maxwell- und Pascal-GPUs im Vergleich zu den AMD-Konkurrenten).

Ailuros

2017-01-18, 20:22:53

Werden bei AMD's neuer binning Loesung auch Parameter und Geometrie komprimiert oder nur FB-compression?

Fuer's flushing kann man einfache mehrere thresholds einsetzen wo und bei welchem Wert wieder gelehrt wird.

Gipsel

2017-01-18, 20:46:30

Werden bei AMD's neuer binning Loesung auch Parameter und Geometrie komprimiert oder nur FB-compression?Nichts Genaues weiß man nicht.
Details dazu gibt es bisher einfach nicht. Da muß man wohl noch warten. Sind ja aber vermutlich auch noch ~5 Monate bis zum Launch.

Ailuros

2017-01-19, 06:43:33

Dachte ich mir schon. Auf jeden Fall je mehr man jegliche zwischengespeicherte Daten komprimiert, desto kleiner der Bandbreiten-Verbrauch bei der endlosen "herum-pufferei" dieser.

Insgesamt kann ich mir aber schon vorstellen dass wenn eine game engine anstaendig Daten verwirft, man mit solchen Methoden schon einen guten Gewinn haben kann. Man muss eben nur verdammt vorsichtig sein alle moegliche Fallen zu meiden. Wendet man wenn moeglich solches rasterizing nur dann an wo es zum absoluten Vorteil ist, ist der Gewinn auch ziemlich klar.

Die naechste Frage danach waere (und ja natuerlich noch viel zu frueh dafuer) ob und wie man TB rasterizing mit Tessellation kombiniert.

Hübie

2017-01-19, 08:58:35

Es wird sich auch zeigen müssen in wie weit der Treiber eingreifen kann, wenn die Grafik-Engine nicht exklusive features die mit Vega eingeführt werden unterstützt. Es wurde ja explizit gesagt es bedarf der Implementierung auf Enginecode-Basis. Das ist so lang brachliegendes Ackerland wie es weder eine API-Spec gibt, noch von Software unterstützt wird (wobei wir ja nicht wissen wovon die Rede ist). So oder so dürfte Vega ein Haufen Arbeit für das Treiberteam sein.
Auf dem Papier liest sich vieles gut. Bleibt also abzuwarten was am Ende übrig bleibt.

Übrigens hatte ich Charlie jetzt so verstanden, dass jeder NCU eine Art ACE zugeordnet ist bzw. nicht mehr unterschieden wird welche Art Shader da nun geplant wird. Dann müsste ja während der Laufzeit in der pipeline einfach ein 'anderer Ausgang' geöffnet werden. CS gehen ja z.B. nicht durch die TMUs oder ROPs, was die Latenz von I/O verkürzt wenn ich es richtig verstanden habe... Deutet auf ein komplexes des OCN Design hin. Wahrscheinlich wird hier auch weiter mit limitierter branch prediction gearbeitet oder was denkt ihr?

Gipsel

2017-01-19, 09:54:56

Es wird sich auch zeigen müssen in wie weit der Treiber eingreifen kann, wenn die Grafik-Engine nicht exklusive features die mit Vega eingeführt werden unterstützt. Es wurde ja explizit gesagt es bedarf der Implementierung auf Enginecode-Basis.Das gilt für die Benutung von Primitive Shadern. Der Rest (also auch der Binning Rasterizer) sollte ohne Codeanpassungen funktionieren.
Übrigens hatte ich Charlie jetzt so verstanden, dass jeder NCU eine Art ACE zugeordnet ist bzw. nicht mehr unterschieden wird welche Art Shader da nun geplant wird.Vergiß das mal gleich wieder. Das war einfach Schwachsinn.

Gipsel

2017-01-19, 10:01:08

Die naechste Frage danach waere (und ja natuerlich noch viel zu frueh dafuer) ob und wie man TB rasterizing mit Tessellation kombiniert.Das sollte ohne Probleme funktionieren. Die Rasterizer liegen ja hinter den Stages, die mit Tessellation zu tun haben. Die Rasterizer sollte es also im Prinzip gar nicht kümmern, woher die Dreiecke kommen und wie die erzeugt worden sind. Es ist aber mal ein anständiges Load-Balancing erforderlich, daß AMD von dem Limit von nur einem einzigen gerastertem Dreieck pro Takt bei Tessellation wegkommt. Aber da will AMD ja dran drehen. Mal sehen.

G3cko

2017-01-19, 11:59:11

Nichts Genaues weiß man nicht.
Details dazu gibt es bisher einfach nicht. Da muß man wohl noch warten. Sind ja aber vermutlich auch noch ~5 Monate bis zum Launch.

Ich dachte es stand immer Q1 im Raum?:eek:

Linmoum

2017-01-19, 12:07:11

Q1 bei Ryzen, H1 2017 bei Vega.

Nakai

2017-01-19, 12:14:07

Ich dachte es stand immer Q1 im Raum?:eek:

Naja, wenn du ein unfertiges Produkt sehen willst.

Ich sage schon seit einiger Zeit, dass es Q2/Q3 wird. Im Q1 wird AMD Zen launchen und im Q2 kommt eben Vega dran. Wohl erst für den professionellen Markt und dann für den Consumerbereich.

Und dann im H2 kommt wohl Vega11. P12 kommt auch noch, welcher aber wohl einfach heimlich zu den OEMs geschoben wird.

G3cko

2017-01-19, 12:28:29

Bei so einem späten release darf man hoffentlich 16GB erwarten. Auch wenn es HBM Speicher ist. 2 Jahre nach der 390 sind 8GB keine High end Ausstattung mehr. Erst rech nicht wenn man mit der Bandbreite auf GDDRX5 Niveau rumdümpelt.

Complicated

2017-01-19, 12:35:28

AMD hat Technologien für Vega angekündigt, welche den Speicherbedarf drastisch reduzieren.
WCCF Tech, da sich bisher nur wenige scheinbar damit überhaupt beschäftigen:
http://wccftech.com/amds-vega-doubles-usable-graphics-memory/

http://cdn.wccftech.com/wp-content/uploads/2017/01/slides-19.jpg
With Vega the High Bandwidth Cache Controller is clever enough to know beforehand what data is actually useful and load it into the cache and what data isn’t and leave it out. Which would not only cut the amount of memory allocated by games in half it would also make things like alt-tabbing out of games significantly faster, because the frame buffer isn’t clogged up with all of these wasteful data allocations.

dargo

2017-01-19, 12:57:53

Das wäre natürlich toll wenn es funktioniert. Und zwar in Hardware, sprich ohne zutun vom Spieleentwickler.

G3cko

2017-01-19, 13:02:36

Bin ich noch skeptisch. Die 970 hat 0,5GB langsam angebundenen VRAM der dennoch schneller ist als PCIe und dennoch reicht die Performance nicht. Wenn die Daten im RAM liegen ist das einfach zu langsam. Zumindest muss man in Tests genau prüfen ob es auch wirklich funktioniert oder nur ein adaptiertes Profi Features ist was für Games am Ende in der Praxis nur einen Papiertiger darstellt.

mksn7

2017-01-19, 13:09:39

Deferred Renderer können einen relativ großen G-Buffer haben und fressen dann mitunter merklich Bandbreite (weswegen es eventuell als Beispiel herausgestellt wurde, keine Ahnung, vielleicht fällt Foobar oder irgendwem Anderen was ein). Hier hilft dann (nicht nur der Draw Stream Binning Rasterizer sondern auch) die erhöhte effektive Cachegröße, Speicherbandbreite zu sparen. Außerdem muß man wohl die Caches zwischen den Passes nicht flushen, was noch mal ein wenig zusätzlich bringen könnte. Alles Folgende gilt aber ganz allgemein.
[...]

Danke für die ausführliche Antwort. Der reuse der ROPs wird also besser, weil von einem größeren Cache unterstützt, was vor allem bei den großen Render Targets von Deferred Renderern hilft.

Ich hatte das vorher so verstanden, das der Reuse aus dem L2 zwischen dem Geometrie Pass und dem Shading Pass passiert. Dafür ist für mein Verständnis aber der L2 viel zu klein bzw. der G-Buffer viel zu groß.

tm0975

2017-01-19, 13:11:50

wenn vega aber wie angekündigt deutlich effizienter mit dem vram umgeht, könnten auch 8 gb schon viel sein.

=Floi=

2017-01-19, 13:14:11

amd will ja weniger in den vram laden und genau hier sehe ich zwei probleme.
1. wieder kleinerer vram?
2. macht es einfach sinn, brutforcemassig alles was geht in den vram zu laden. ich muss da noch immer an rage und diverse speile mit nachladeruckler und miserablem texturstreaming denken.
ich bin von der idee bisher auch nicht überzeugt, auch weil vram nicht so unermesslich teuer ist.

tm0975

2017-01-19, 13:16:45

... auch weil vram nicht so unermesslich teuer ist.

langsamer, alter vram ist sicherlich billig, aber zudem unnötige energieverschwendung

schneller, moderner und effizienter vram ist (mutmaßlich) noch sehr teuer.

=Floi=

2017-01-19, 13:20:24

die hohe bandbreite der fury x bring der karte 0,0. hätte sie dagegen 8GB GDDR5 würde ide wesentlich besser dastehen.

Linmoum

2017-01-19, 13:24:10

Der Balken beim Verbrauch wäre zwar noch mal länger, aber das ist nicht wirklich besser. ;)

Gipsel

2017-01-19, 13:51:39

Ich hatte das vorher so verstanden, das der Reuse aus dem L2 zwischen dem Geometrie Pass und dem Shading Pass passiert. Dafür ist für mein Verständnis aber der L2 viel zu klein bzw. der G-Buffer viel zu groß.Die Tiles, in die gebinnt wird, werden ja nacheinander abgearbeitet. Zu jedem Zeitpunkt muß also nur die ein oder maximal zwei Frame-/G-buffer-Abschnitte im L2-Cache stehen, die zur gerade abgearbeiteten Binning-Tile gehören.
Und dann hängt das ganz davon ab, wie AMDs Binning Rasterizer nun genau arbeitet und auch wie groß die Caches sind. Wieviel Geometrie kann er zusätzlich zum entsprechenden Teil des Framebuffers für eine Binning Tile on Chip (im L2) halten? Kann AMD eventuell sogar über Drawcalls hinweg binnen (nVs Lösung kann das wohl nicht)? Da ist eben viel von der konkreten Umsetzung abhängig, die wir einfach noch nicht kennen. Im Prinzip hat AMD ja nur gesagt, daß sie im Zuge der Arbeit an der Bandbreiteneeffizienz einen Draw Stream Binning Rasterizer einführen (so einen haben im Prinzip alle Tile based Architekturen) und andeuten, HSR zu machen, was über Hi-/Early-Z hinausgeht. Mehr wissen wir schlicht nicht.
Wir können aber sicher annehmen, daß Vega natürlich immer noch im Grunde ein immediate Mode Renderer bleibt, bei dem das Binning auch auf Null gedreht werden kann (als Fallback). Das Binning wird nur so weit gemacht, solange man nicht in Probleme läuft, die grundlegendere Umbauten zu einem deferred Renderer erfordern würden. Jeglicher Reuse ist also limitiert und nicht vollständig. Man verfolgt die niedriger hängenden Früchte.

Der_Korken

2017-01-19, 14:02:27

Das mit dem reduzierten Speicherverbrauch klingt sehr interessant und ist eigentlich genau das, was AMD braucht, um HBM für bezahlbare Preise anzubieten. Ich habe zumindest das Gefühl, dass einige neuere Titel extrem verschwenderisch mit dem VRAM umgehen, sodass selbst für Midrange-Karten schon 4GB zu wenig sind. Für >1080-Performance müssten die dann noch bisherigen Maßstäben wirklich auf 16GB hochgehen für das Topmodell, was natürlich sehr teuer wird. Mich wundert nur eine Sache (aus dem Link von Complicated):

So basically a game that says it uses 4GB of VRAM right now, is in actuality using 2 and with Vega, you’re saying, it will actually allocate 2.

Ich habe bisher keine Erfahrungen mit GPU-Programmierung, von daher ist die Frage vielleicht blöd. Wenn ich bspw. in C++ sage ich hätte gerne 4GB, dann kann mir das System ja nicht einfach 2GB geben, weil es ja gar nicht weiß, was ich wo in dem Speicher ablegen will (Der Speicherbereich muss natürlich nicht zusammenhängend sein, weil das Programm sowieso nur mit virtuellen Adressen arbeitet). Wie muss ich mir das bei GPUs vorstellen? Wird die Allokation da über eine Zwischenschicht geregelt, die AMD mit Hilfe des neuen Speichercontrollers/HBM-Speichers dann optimiert, sodass der Programmierer davon quasi nichts mitbekommt?

mksn7

2017-01-19, 14:30:41

Ich habe bisher keine Erfahrungen mit GPU-Programmierung, von daher ist die Frage vielleicht blöd. Wenn ich bspw. in C++ sage ich hätte gerne 4GB, dann kann mir das System ja nicht einfach 2GB geben, weil es ja gar nicht weiß, was ich wo in dem Speicher ablegen will (

Tatsächlich kann das OS genau das machen, und tut es auch (jedenfalls unter Linux). Der Speicher wird in 4kB Seiten gemapped, wenn du ihn das erste mal anfasst. Deswegen kann man auch absurd große Speichermengen wie 4TB erfolgreich allokieren. Wenn du da aber einmal durchgehst um bspw. alles mit 0 zu initialisieren, dann geht irgendwann tatsächlich der Speicher aus.

Evtl. kommen Dinge erst in den VRAM, wenn sie das erste mal angefasst werden. Bei x86 CPUs ist die Granularität klassischerweise 4kB, AMD könnte für die GPUs alles mögliche wählen.

Screemer

2017-01-19, 14:31:29

IF signaling does not constrain topologies either, it could be point to point, rings, busses, meshes, or 3D structures like a torus. Since Vega is using IF in a mesh topology it probably will start off on the complex end of that list. How Vega is using IF,whether for to and from die transmissions or does it subsume the on-die unit to unit communications too, is yet to be revealed, but there is a big hint in the granularity.

AMD went to great lengths to explain how granular IF is, it is one of the technology’s key selling points. Like all modern fabrics it has a firware driven microcontroller but as you would expect, that doesn’t scale well. IF has scalability as one of its pillars. Instead of a single controller AMD broke up the control tasks into many tiny sub-controllers, one per IP block. That IP block bit is a bit nebulous but given how the speakers were talking about granularity, think shader rather than GPU, it sounded like they made it granular enough to have thousands of sub-contollers across a die like Vega, not tens.

http://semiaccurate.com/2017/01/19/amd-infinity-fabric-underpins-everything-will-make/

dargo

2017-01-19, 14:44:04

Nightspider

2017-01-19, 15:13:20

Nichts für ungut aber solange man nicht gezeigt hat das dieses Feature in allen Spielen funktioniert will ich lieber 16GB VRAM haben.

8GB ist einfach zu wenig für eine TopDog Karte in 2017.

dildo4u

2017-01-19, 15:16:51

Es wird erstmal keine 16GB Consumer Karte geben,in dem langen Interview wurde extra gesagt man will von der Menge wegkommen und die Transferrate bewerben.

BlacKi

2017-01-19, 15:23:26

AMD hat Technologien für Vega angekündigt, welche den Speicherbedarf drastisch reduzieren.
WCCF Tech, da sich bisher nur wenige scheinbar damit überhaupt beschäftigen:
http://wccftech.com/amds-vega-doubles-usable-graphics-memory/

http://cdn.wccftech.com/wp-content/uploads/2017/01/slides-19.jpg
das hat nvidia mit der 970 schon treiberseitig so ähnlich hinbekommen. nichtmehr benötigte daten wurden gelöscht, wenn der speicher voll war. nicht das das speziell ein 970 oder nvidia feature wäre, alle grafikkarten halten die nichtmehr benötigten so lange im speicher vor bis deren speicherplatz benötigt wird. das vorhalten der aktuell nicht benötigten daten soll das erneute laden überflüssig machen.

jetzt kommt amd und hält nur noch die daten vor die tatsächlich gerade gebraucht werden im speicher und der rest wird gleich gelöscht obwohl er vl sonst erneut gebraucht werden könnte? das das kostet pcie bandbreite, wer weiß wieviel.

aufkrawall

2017-01-19, 15:25:42

Klingt imho einfach zu gut, um wahr zu sein.
AMD hat es insofern natürlich einfach, als dass es momentan noch schwer ist, 8GB zu überfüllen. Folglich werden wohl viele Redaktionen es gar nicht auf die Reihe bekommen, dieses Feature ernsthaft zu testen und ggf. zu entzaubern.

mkh79

2017-01-19, 15:30:53

Nichts für ungut aber solange man nicht gezeigt hat das dieses Feature in allen Spielen funktioniert will ich lieber 16GB VRAM haben.

8GB ist einfach zu wenig für eine TopDog Karte in 2017.
Ich glaube nicht, dass das 2017 oder 2018 nötig sein wird, 16GB VRAM zu haben.

Dass es jetzt mehr um Bandbreite geht, als um Speichermenge, fühlt sich allerdings wirklich danach an, als würde man schon vorbereiten wollen, dass HBM2 erstmal im Desktopbereich auf 8GB limitiert bleibt. Sehe da allerdings kein Problem.

BlacKi

2017-01-19, 15:35:55

Ich glaube nicht, dass das 2017 oder 2018 nötig sein wird, 16GB VRAM zu haben.

Dass es jetzt mehr um Bandbreite geht, als um Speichermenge, fühlt sich allerdings wirklich danach an, als würde man schon vorbereiten wollen, dass HBM2 erstmal im Desktopbereich auf 8GB limitiert bleibt. Sehe da allerdings kein Problem.
das hat man von fiji anfang 2015 auch gesagt, 2016 kamen die ersten ernsthaften probleme. zumal man mit vega 8gb erst ca mitte des jahres kommt. gerade die speicherverwöhnten amd anhänger könnten damit hadern.

KORE

2017-01-19, 15:41:10

Ich warte ja auch schon eine Weile und zur 390x muss überall was drauf gelegt werden, sonst fühlt es sich einfach nicht richtig an. -.-
Aber NV wird ja auch nicht auf der Stelle treten, vielleicht wird es dann wieder eine NV.

Nightspider

2017-01-19, 16:30:31

Es wird erstmal keine 16GB Consumer Karte geben,in dem langen Interview wurde extra gesagt man will von der Menge wegkommen und die Transferrate bewerben.

Als ob die Speicherbandbreite mit 512GB/s so toll wäre. Das bot schon die Fury X und selbst die war noch im Speicherbandbreitenlimit.
Damals hats ein Übertakter geschafft den HBM Speicher zu übertakten wodurch die Fury X schneller wurde.

Damit zu werben wäre extrem unbeeindruckend.

Selbst von der uralten R9 290X gab es Versionen mit 8GB Speicher. 2,5 Jahre später hätte ich gerne wenigstens die Option zu einer 16GB Variante zu greifen.
Und gerade für ein Spiel wie Star Citizen würde ich gerne die Optik so tweaken das auch für weit entfernte Objekte schon die hochaufgelösten Schatten und Texturen geladen werden.

Digidi

2017-01-19, 16:39:32

Als ob die Speicherbandbreite mit 512GB/s so toll wäre. Das bot schon die Fury X und selbst die war noch im Speicherbandbreitenlimit.
Damals hats ein Übertakter geschafft den HBM Speicher zu übertakten wodurch die Fury X schneller wurde.

Damit zu werben wäre extrem unbeeindruckend.

Selbst von der uralten R9 290X gab es Versionen mit 8GB Speicher. 2,5 Jahre später hätte ich gerne wenigstens die Option zu einer 16GB Variante zu greifen.
Und gerade für ein Spiel wie Star Citizen würde ich gerne die Optik so tweaken das auch für weit entfernte Objekte schon die hochaufgelösten Schatten und Texturen geladen werden.

Nur Mal so. Wenn AMD wirklich Vram einspart kommt das auch der Bandbreite zu gute.

Hinzu kommt das Vega ein total anderer Chip ist als FIJi! Da kann Bandbreite sehr von Nutzen sein. Und du sagst ja selbst das bei FIJi die Bandbreite limitiert hat also dann gddr5 nehmen!

Dein Post ist total unlogisch nightspider

HBM ist zurzeit das schnellste was es gibt. Ein zu großes Speicherinterface kostet nur DieFläche die man besser für Schader Nutzen kan.

Nightspider

2017-01-19, 16:43:00

Dein Post ist unlogisch. Nur weil ich gesagt habe das Fiji auch noch durch die Speicherbandbreite limitiert wurde, habe ich nicht automatisch behauptet das der VRAM ausreichen würde. Was ist das denn für eine absurde Schlussfolgerung?

Solange hier niemand genau erklären kann wie die VRAM Ersparnis funktionieren wird, ist es erst mal spekualtiv ob dadurch Speicherbandbreite eingespart wird.

Digidi

2017-01-19, 16:44:08

Nightspider

2017-01-19, 16:44:33

Was für einen Unterton?

Digidi

2017-01-19, 16:48:24

Was für einen Unterton?

Habs korrigiert bin in der Zeile verrutscht. Das mit der Vramgröße bezog sich darauf das man ja sieht das 4GB gut reichen bei FiJi das Management muss stimmen. Bei FiJi gibt es kaum Probleme mit Microruckler selbst in Spielen die auf anderen gpus 8gb Vram verschlingen

Pirx

2017-01-19, 16:50:50

Wird schon auch 16 GB-Karten geben, aber da nV+User uns ja zeigen, daß sich selbst richtiggehende Speicherkrüppel immer wieder wunderbarst verkaufen und rechtfertigen lassen, kann ich mir schon vorstellen, daß AMD hier im Hiblick auf den langfristigen Absatz nicht zu großzügig sein wird.

Nightspider

2017-01-19, 16:51:14

Durch die 512GB/s werden die Frametimes sicherlich nicht so sehr in Mitleidenschaft gezogen bei wenig VRAM.
Dennoch dürfte es schon Spiele geben die einige Details von selbst ausblenden wenn der VRAM voll ist.
Die fehlen also effektiv Details in einigen VRAM intensiven Spielen mit 4GB bei Fiji.
"Gut reichen" ist deshalb schon mehr als optimistisch.

y33H@

2017-01-19, 16:53:24

Die 512 GB/s haben doch nichts mit dem PCIe-Interface zu tun über das geladen wird, wenn der Videospeicher voll ist ...

Digidi

2017-01-19, 16:54:35

Nightspider

2017-01-19, 16:57:03

Die 512 GB/s haben doch nichts mit dem PCIe-Interface zu tun über das geladen wird, wenn der Videospeicher voll ist ...

Hast Recht, eigentlich dürfte mehr Speicherbandbreite bei VRAM Mangel auch nicht viel oder gar nix bringen.

Lurtz

2017-01-19, 17:01:33

Digidi

2017-01-19, 17:03:36

Hast Recht, eigentlich dürfte mehr Speicherbandbreite bei VRAM Mangel auch nicht viel oder gar nix bringen.

Die Fragestellung ist doch was AMD mit der Bandbreite anstellt. Wie gesagt trotz großer Texturen und viel Vram ruckeln da einige Spiele nicht. Also hilft die Bandbreite indirekt schon. Kann mir gut vorstellen das durch die Bandbreite die Auslastung vom Vram besser wird weil die Daten schneller dahin kommen wo sie hin sollen u d es weniger Überschneidungen gibt.

G3cko

2017-01-19, 17:18:27

Das hat rein gar nichts mit dem Krüppeldesign der 970 zu tun.

Doch hat es. Der Krüppelspeicher der GTX970 hat grundsätzlich das identische Problem. Hier werden Daten mit deutlich untschiedlicher Bandbreite gelagert. Die Frage ist halt wie effektiv die Bereitstellung bzw die Aufteilung funktioniert.

In doom konnte man bei der GTX970 sehen wir viele Texturen nachgeladen werden (matschig->scharf) ohne das das Bild geruckelt hat. Das macht ein Spiel zwar flüssiger und besser spielbar, aber es ersetzt eben keinen fehlenden VRAM gleichwertig.

Aktuell sieht es so aus, dass man mit den 4GB stacks kosten sparen will. Nur Performance auf GDDRx5 Niveau. Dafür stromsparender und kaum teuerer. Zu lasten eben von speichermenge und mehr Performance durch weitere stacks.

Wenn man auch nur 4GB produziert kann man später auch mit 4 (oder 3stacks) weitere größere speichermengen + mehr Performance anbieten ohne alle HBM DIEs wieder zu entsorgen wie bei Fiji.

Complicated

2017-01-19, 17:42:06

Doch hat es. Der Krüppelspeicher der GTX970 hat grundsätzlich das identische Problem. Hier werden Daten mit deutlich untschiedlicher Bandbreite gelagert. Die Frage ist halt wie effektiv die Bereitstellung bzw die Aufteilung funktioniert.
Nein die 970 hat ein Problem in der Crossbar. der 3,5 GB und 0,5 GB Anteil sind eigentlich gleich schnell angebunden (gemeinsam an einer Leitung). Nur kann man auf die 0,5 GB nur zugreifen, wenn kein Zgriff auf die 3,5 GB erfolgt, weil die letzten 0,5 GB sich eine Anbindung teilen und nur abwechselnd die beiden Speicher ansprechen kann. Nvidia verhindert durch das Treibermanagement, dass relevante Daten im 0,5 GB Bereich liegen. Siehe damaliges Schaubild:

http://bilder.pcwelt.de/3504990_620x310.jpg
Immer wenn der 3,5 GB Pool dran ist, wird der L2 geflushed, ebenso wenn das letzte 0,5 GB Daten bereitstellen muss. Hier entstehen die Verzögerungen. Das hat mit dem üblichen Speichermangel gar nichts zu tun.

Dass HBM beim Texture-Steaming auch mit Fiji Vorteile hat ist erwiesen:
http://www.hardocp.com/article/2016/02/29/rise_tomb_raider_graphics_features_performance/14

VRAM utilization was one of the more interesting aspects of Rise of the Tomb Raider. It appears to be very different depending on what GPU you are running. There is no question this game can consume large amounts of VRAM at the right settings. With the GeForce GTX 980 Ti we maxed out its 6GB of VRAM just at 1440p with No AA and maximum settings. The TITAN X revealed that it was actually using up to 7GB of VRAM for that setting. In fact, when we pushed the TITAN X up to 4K with SSAA it used up to almost 10GB of VRAM.

However, for the AMD Radeon R9 390X utilization was a bit odd when you first see it, never exceeding 4.2GB and remaining "flat" with "Very High" textures and SSAA. We did see the proper decrease in VRAM using lower settings, but the behavior was odd indeed. This didn't seem to negatively impact the video card however. The VRAM is simply managed differently with the Radeon R9 300 series.

The AMD Radeon R9 Fury X kind of backs that statement up since it was able to allocate dynamic VRAM for extra VRAM past its 4GB of dedicated VRAM capacity. We saw up to a 4GB utilization of dynamic VRAM. That allowed the Fury X to keep its 4GB of dedicated VRAM maxed out and then use system RAM for extra storage. In our testing, this did not appear to negatively impact performance. At least we didn't notice anything in terms of choppy framerates or "micro-stutter." The Fury X seems to be using the dynamic VRAM as a cache rather than a direct pool of instant VRAM. This would make sense since it did not cause a performance drain and obviously system RAM is a lot slower than local HBM on the Fury X. If you remember a good while ago that AMD was making claims to this effect, but this is the first time we have actually been able to show results in real world gaming. It is awesome to see some actual validation of these statements a year later. This is what AMD said about this in June of 2015 (http://www.hardocp.com/article/2015/06/24/amd_radeon_r9_fury_x_video_card_review).

http://www.hardocp.com/article/2016/04/01/ashes_singularity_day_1_benchmark_preview/5

http://images.hardocp.com/images/articles/145950436379jEKuNgdA_5_1.gif

However, you will notice that what is consistent on both video cards is that running under the DX12 API actually consumed much more VRAM. While the Dynamic VRAM was hardly touched on the Radeon R9 Fury X under DX11, at DX12 it was highly utilized, about 2.4GB of it consistently. Our VRAM numbers also went up on the GeForce GTX 980 Ti across the board under DX12 even though performance was slower.

G3cko

2017-01-19, 18:02:44

Ok, einverstanden. Aber Vega soll nun mit externem Speicher nahtloser arbeiten? Kann ich mir kaum vorstellen. Ich denke man hat einfach das Profi-Feature mit einer SSD auf dem PCB, umgemodelt mit externer Speicheradressierung für Games. Glaube jedoch nicht, dass der Umweg über PCIe hier ausreichend schnell ist.

Bei Tombraider muss ich dir wiedersprechen. Das ist ein klasse Beispiel für einen modernen Konsolenport. Die Konsolen haben bekanntlich einen Unified Speicher für VRAM und RAM. Was macht man also auf dem PC? Man schiebt soviel in den VRAM wie möglich. Je mehr im VRAM ist desto kleiner fällt der RAM-Verbrauch aus.

VRAM:
http://techbuyersguru.com/sites/default/files/pictures/TheGamersBench/RoTRDX12/RoTR%20VRAM%20fix.jpg
RAM:
http://techbuyersguru.com/sites/default/files/pictures/TheGamersBench/RoTRDX12/RoTR%20RAM%20Fix.jpg

Das heißt nicht, dass man bereits 8 GB zwingend braucht sondern nur wohin die Reise geht. Nun über einen externen Pool vorzugauckeln die Grafikkarte hat effektiv mehr VRAM ist solange sinnvoll wie eben das Spiel diesen nicht wirklich braucht. Wenn man mal ein Game hat was effektiv mehr als 8GB wirklich benötigt werden auch diese nicht reichen. Ich bin mal gespannt ob es Tester gibt die das Nachprüfen auch wirklich hinbekommen.

BoMbY

2017-01-19, 18:09:13

Ja, nein. Optimiertes Texture-Streaming würde auch ohne HBM etwas bringen. Ich denke das ist eine reine Marketing-Nummer von AMD. PCIe, über was die Texturen laufen müssen, ist auf maximal 16 GB/s limitiert - da ändert auch HBM nichts dran. Was eventuell etwas bringt ist, dass der Fiji Memory Controller auch von sich aus eventuell schon in der Lage ist DMA-Zugriffe zu starten, also an der CPU vorbei. Also im Prinzip schon ein Vorgänger des "High Bandwidth Cache Controllers" - nur wie gesagt, würde das auch funktionieren, wenn da GDDR5 auf der Karte kleben würde.

Complicated

2017-01-19, 18:16:45

Genau das macht Vega mit dem HBCC eben nicht:

http://assets.hardwarezone.com/img/2016/11/vega_L2.jpg

https://www.extremetech.com/extreme/242122-amd-releases-new-details-new-gpu-architecture-codename-vega0
The HBC and HBCC give Vega a large (in comparison to on-die caches, though exact size isn’t known) memory pool that it can use in a variety of ways. AMD isn’t giving out the exact details on how this cache functions yet, but the goal is to enable fine-grained data movement and keep important data local to the GPU without having to pull it out of memory. It can also be accessed without stalling other workloads — normally the GPU will stall if pulling texture data out of main memory, whereas AMD’s HBCC avoids this problem.

aufkrawall

2017-01-19, 18:18:29

AMD hat schon mit ausreichend VRAM häufiger Frametime-Probleme mit DX11 als Nvidia und laut CB-Test mit der API auch zusätzlich mehr Probleme, wenn es knapp wird. DX12 ist bislang ein Rohrkrepierer und braucht tendenziell auch mehr VRAM als 11.
So eine schnelle Karte mit genau so viel VRAM wie der Hawaii-Refresh ist einfach unausgewogen, sofern diese Secret Sauce tatsächlich nicht der Überbringer ist.

Complicated

2017-01-19, 18:29:38

DX12 braucht mehr Speicher und hat deutlich überlegenes Speichermanagement. Daher ein schlechter Vergleich. Siehe die beiden Links von Hardocp wo dies ausgeführt wurde.

Vega hat ein neues Speichermanagement, und wenn hier noch jemand meint er muss DX11 und Hawaii als Vergleich heranziehen, dann kann ich auch nicht mehr weiter helfen. Vor allem da die Radeon Pro Duo ja zeigt wie gut es funktioniert. Oder denkt wirklich jemand die 1TB SSD auf der Karte sind schneller angebunden als 16 GB/s?

Noch keine DX Version hat sich so schnell verbreitet - Rohrkrepierer?

aufkrawall

2017-01-19, 18:34:59

DX12 braucht mehr Speicher und hat deutlich überlegenes Speichermanagement. Daher ein schlechter Vergleich. Siehe die beiden Links von Hardocp wo dies ausgeführt wurde.

Du meinst wohl "DX12 braucht weniger Speicher". Ist aber falsch, die meisten Spiele brauchen damit mehr. Ashes ist offenbar die Ausnahme.
Abgesehen davon halte ich Kyle für ziemlich inkompetent. Gerade du als AMD-Fahnenträger solltest das ähnlich sehen.

Vega hat ein neues Speichermanagement, und wenn hier noch jemand meint er muss DX11 und Hawaii als Vergleich heranziehen, dann kann ich auch nicht mehr weiter helfen. Vor allem da die Radeon Pro Duo ja zeigt wie gut es funktioniert. Oder denkt wirklich jemand die 1TB SSD auf der Karte sind schneller angebunden als 16 GB/s?

Noch keine DX Version hat sich so schnell verbreitet - Rohrkrepierer?
In welcher Welt lebst du? DX12 ist im Großteil der Titel, die es unterstützt, gegenüber DX11 zweite Wahl, selbst auf Radeons.

Complicated

2017-01-19, 18:42:39

Nein meinte ich nicht...Wieso sollte ich? Wir stimmen darüber überein und ich habe darüber hier einige Beiträge zuvor eine Schaubild verlinkt das eben dies zeigt. Dein Argument macht keinen Sinn. Lies mal weiter oben im Thread.

Und nur weil Kyle einige Hasstiraden absondert gegen AMD, sind diese Analysen dennoch nachvollziehbar und gehaltvoll. Warum sollte ich eine Quelle die sauber arbeitet ignorieren nur weil er mit AMD was persönliches auszufechten hat?

Und ich lebe in der Welt, die zwischen DX11 mit enormen Optimierungsaufwand und DX12 mit schlanken Treibern ohne diesen Aufwand unterscheiden kann. DX12 ist eine Erleichterung für CPUs und für GPUs ein enormer Fortschritt. Asynch Compute ist nachweislich eine Beschleunigung, auch wenn du scheinbar nur Nvidia Messergebnise kennst, wo das nicht so ist.
Aber genug von dem Fanboy-Unsinn....

aufkrawall

2017-01-19, 18:44:29

Ich kenne u.a. meine eigenen Messergebnisse, sowohl mit AMD als auch Nvidia...

Complicated

2017-01-19, 18:55:44

Wenn du sie ebenso dokumentierst wie Kyle, können wir gerne darüber diskutieren hier. Ansonsten ist das wenig interessant und aussagekräftig für diesen Thread.

tm0975

2017-01-19, 18:56:25

DX12 ist im Großteil der Titel, die es unterstützt, gegenüber DX11 zweite Wahl, selbst auf Radeons.
die 2. wahl was die ordentliche umsetzung und die prio der entwickler betrifft (leider) ja, viele anwender bzw. spieler wünschen sich sicherlich eine ordentliche dx12 umsetzung mit prio 1. dafür hab ich das ... windows 10 angeschafft.

Nightspider

2017-01-19, 19:16:15

Genaue Daten über Größe der L1 und L2 Caches gab es seitens AMD noch nicht oder?

Es ließt sich aber fast so als würde AMD den HBM Speicher effizienter nutzen als noch bei Fiji.

Der der Diskussion ob 8 oder 16GB HBM2 dürfen wir aber auch nicht vergessen das die im HBM Speicher enthaltenen DDR Chips billig zu fertigen sind, zumal sie mit sehr niedrigem Takt fahren.
Nur das stapeln ist teuer aber 8GB DDR4 kosten auch gerade mal ~40$.
Wenn AMD also eine ~700€ Grafikkarte auf den Markt bringt wäre es doch blödsinnig dann am VRAM zu sparen.

Selbst wenn das Feature gut funktioniert das man VRAM einspart, so ist der Marketingeffekt negativ wenn AMDs Topdog nur 8GB besitzt während selbst die alte Titan X schon vor 2 Jahren, Anfang 2015, schon 12GB besaß.

Thomas Gräf

2017-01-19, 19:17:00

die 2. wahl was die ordentliche umsetzung und die prio der entwickler betrifft (leider) ja, viele anwender bzw. spieler wünschen sich sicherlich eine ordentliche dx12 umsetzung mit prio 1. dafür hab ich das ... windows 10 angeschafft.

Ja eben, welcher Titel ist denn rein in einem voll umfänglichen DX12 entwickelt worden?
Wo dann ein DX11 lediglich noch als "fallback" vorhanden ist. ;)
Sagt jetzt nicht dieses komische Forza wo eine Kinderstube dran gebastelt hat...sorry vorab dafür.

CompuJoe

2017-01-19, 19:27:03

Ashes ist doch eine native DX12 Entwicklung oder?

Bei den meisten ist DX12 doch nur nachträglich angeflanscht.

Achill

2017-01-19, 19:54:59

Genau das macht Vega mit dem HBCC eben nicht:

http://assets.hardwarezone.com/img/2016/11/vega_L2.jpg

https://www.extremetech.com/extreme/242122-amd-releases-new-details-new-gpu-architecture-codename-vega0

Wäre es möglich, dass HBC ggf. der HBM2 ist und alternativ zu einer SSD (wie schon mit Fiji demonstriert) normaler RAM wie GDDR5(X) auf der Karte angebunden werden könnte und dann als Puffer / Swap fungiert?

Der Vorteil einer solchen Lösung wäre meiner Meinung nach, dass man eben nicht über den PCIe Bus muss und in Konkurrenz zu Daten Bandbreite und/oder Protokoll- oder OS-Limitierungen (z.B. bedarf immer einer Treiber Koordination).

Wie ist das mit dem PCIe-Bus, ist der voll Multiplex fähig? Gehen parallele Streams oder wird Parallelität vorgetauscht indem Daten nur entsprechend gepackt werden? Kann eine GPU auf den System-Ram zugreifen ohne mit CPU/OS zu interagieren?
=> Wenn davon nur ein paar Sachen passen, kann ein entkoppelter Bus sehr wohl einen unterschied Machen, selbst wenn dieser nur die Bandbreite von PCIe 16x hätte.

---
Edit: Wenn ich https://en.wikipedia.org/wiki/PCI_Express richtig verstehe, dann:
- Ein Packet wird über alle Lanes verteilt übertragen -> keine parallelen Streams
- Full-Duplex

Loeschzwerg

2017-01-19, 20:03:26

Wäre es möglich, dass HBC ggf. der HBM2 ist und alternativ zu einer SSD (wie schon mit Fiji demonstriert) normaler RAM wie GDDR5(X) auf der Karte angebunden werden könnte und dann als Puffer / Swap fungiert?

Ja, deswegen "Cache" in der Bezeichnung :) Hatten wir schon auf Seite 72. Du kannst wie bei einem großen Enterprise-Storage einen gemeinsamen "Pool" anlegen, der auf Hardware Ebene verschiedene Übertragungsraten (Storage: RAM - SSD - 15k - 10k - 7.5k) aufweist.

Achill

2017-01-19, 20:26:26

Ja, deswegen "Cache" in der Bezeichnung :) Hatten wir schon auf Seite 72. Du kannst wie bei einem großen Enterprise-Storage einen gemeinsamen "Pool" anlegen, der auf Hardware Ebene verschiedene Übertragungsraten (Storage: RAM - SSD - 15k - 10k - 7.5k) aufweist.

Danke, war schon ein langer Tag für mich. Dann verstehe ich die Aussagen überhaupt nicht, dass "alles" immer über den PCIe-Bus muss und dies Langsam sein wäre (könnte). AMD kann also verschiedene Produkte mixen für jeweilige Anforderungen ...

Ich warte dann nur auf die News, dass jemand ein Linux auf seiner GPU gebootet hat - weil eigentlich hat man alles zusammen. Blades ganz neu definiert ... ;)

BlacKi

2017-01-19, 20:29:42

danke für den hinweiß.
wie müsste der hbc denn eurer meinung aussehen um fürs gaming optimal ausgestattet zu sein?

eine ssd wäre dazu wohl zu langsam, die schreibzugriffe wären vl auch ein problem.

ein gddr5 chip mit weiteren 8gb speicher mit 64bit/64GB/s ?

wenn das ganz ohne spielanpassungen läuft F4 und tw3 (sind wohl kaum extra angepasst), wäre das der hit. naja, ist ja noch zeit...

Botcruscher

2017-01-19, 20:42:59

das hat man von fiji anfang 2015 auch gesagt, 2016 kamen die ersten ernsthaften probleme. zumal man mit vega 8gb erst ca mitte des jahres kommt. gerade die speicherverwöhnten amd anhänger könnten damit hadern.
:confused:
Soll ich die Posts zu Speicherkrüppel und 4GB Gurke sowie dem angeblichen dual HBM noch mal suchen?

Ansonsten sollten 8GB wirklich bis zur nächsten Konsolengen reichen. An den Marketing-BS mit dem Speicher glaube ich aber trotzdem erst wenn das problemlos laufen sollte. Die Aussage vom dem Diagramm ist gleich null und das Ding eigentlich nicht neu. Der Algorithmus kann überhaupt nicht wissen was in 10 oder 100 Frames gebraucht wird. Jede Leseleistung von Platte über den Bus bis zum Speicher dürfte auch deutlich mehr Energie kosten als mehr Speicher Verbraucht.

Setsul

2017-01-19, 21:32:38

@Complicated:
Kleine Korrektur der Formulierung, das Problem ist nicht im Crossbar, sondern zwischen L2 und MC.
Ich wüsste nichts von L2 Flushes.
Gleichzeitiger Zugriff geht auch, den einen Abschnitt schreiben und den anderen lesen. Dank Marketing-Akrobatik hat die 970 damit 224GB/s. Das funktioniert wunderbar solange man bei 50% read/50% write ist. Praktisch wird aber der Zugriff auf die 0,5 GB solange wie möglich aufgeschoben, dann braucht der Teil auf einmal 100r/0w und die restlichen 3,5GB bekommen 0r/100w. Könnte leicht ruckeln, wenn man 7/8 des VRAMs nicht mehr lesen kann. :biggrin:

http://www.anandtech.com/show/8935/geforce-gtx-970-correcting-the-specs-exploring-memory-allocation/2
Oder liege ich da falsch?

@topic:
Ich nehme an der HBCC wird alles was nicht in den HBC passt, aber auf GDDR5 passen würde eher aus dem System RAM ziehen, bevor man dafür nochmal GDDR5 verbaut. GDDR5 mit gleicher/ähnlicher Bandbreite wie HBM wäre Schwachsinn, dann könnte man sich das alles sparen, und bei niedriger Bandbreite hat man DDR3/4 sowieso "kostenlos" herumliegen.
Der Punkt des HBCC ist doch, dass es egal ist woher die Daten kommen, solange sie schnell kommen. Ob von RAM, SSD oder woher auch immer, der erste Zugriff wird immer langsam sein, aber wenn der Cache alles richtig macht, ist es danach schnell. Man spart sich das manuelle kopieren in den VRAM und muss keine Vermutungen anstellen, was man tatsächlich braucht.

Ich denke auch nicht, dass "50% utilization blablabla" heißt, dass AMD ab sofort nur noch halb so viel VRAM verbaut wie nVidia.

Ich denke eher, dass zu der Zeit, als die ersten V10 zusammengesetzt wurden, AMD keine 8GB Stacks zur Hand hatte. Testen kann man auch mit 8GB problemlos. Die MI25 kommt mit 16GB, also wäre es am einfachsten bei V10 den Interposer generell mit 2x8GB zu bestücken. Die Kosten sollten bei einer High End GPU zu verschmerzen sein und V10 mit der gleichen Speichermenge wie V11 sieht bescheuert aus. V11 mit 4GB, falls nur ein Stack, klingt auch nicht gut, wenn man vorher die RX 480 mit 8GB angepriesen hat, HBCC hin oder her. Man wird sich die Blöße nicht geben, wenn es nicht unvermeidlich ist.
Am meisten Sorgen mache ich mir also um die Verfügbarkeit. Entweder suche ich falsch oder Hynix hat für 2017Q1 nur 4GB gelistet.

BlacKi

2017-01-19, 21:50:50

:confused:
Soll ich die Posts zu Speicherkrüppel und 4GB Gurke sowie dem angeblichen dual HBM noch mal suchen?

Ansonsten sollten 8GB wirklich bis zur nächsten Konsolengen reichen. An den Marketing-BS mit dem Speicher glaube ich aber trotzdem erst wenn das problemlos laufen sollte. Die Aussage vom dem Diagramm ist gleich null und das Ding eigentlich nicht neu. Der Algorithmus kann überhaupt nicht wissen was in 10 oder 100 Frames gebraucht wird. Jede Leseleistung von Platte über den Bus bis zum Speicher dürfte auch deutlich mehr Energie kosten als mehr Speicher Verbraucht.
tut mir leid, ich verstehe nicht. deus ex md ist mit 4gb ohne hand anzulegen mit nachladerucklern behaftet. mitte 2016. mitte 2017 kommt vega mit 8gb. 2018 spätestens 2019 gibts meiner meinung nach die ersten nachladeruckler bei reinen 8gb. 2018 erwarte ich meine 16gb karte, vl vega.

Complicated

2017-01-19, 21:53:43

@Setsul
Ja, doch das Problem zwischen L2 und MC entsteht wegen der Crossbar. Entweder wird aus 3,5 GB gelesen oder aus 0,5. Beides gleichzeitig geht nicht. Und wenn aus 3,5 GB gelesen wird, dann ist die schnellste und übliche Operation das lesen aus dem L2. Doch wenn dann der Switch kommt zu dem 0,5GB Speicher, ist das ein kompletter L2 miss und alles muss neu eingelesene werden. Der L2 wird mit Daten des 0,5 GB Speicherpools gefüllt und diese wiederum sind dann obsolet sobald wieder der 3,5 GB Speicher die Daten liefert. Das macht weniger aus wenn die 3,5 GB Speicher dran sind (1/7 des L2 Caches "missed"), doch es ist der gesamte L2 Cache der mit unnützen Daten gefüllt ist wenn auf den 0,5 GB Speicher zugegriffen wird.

Nakai

2017-01-19, 23:43:08

Thomas Gräf

2017-01-20, 00:27:04

Naah, vor 4-5 jahren konnte man mehr von der Software in Zukunft erwarten. Leider ist aber nach wie vor Stillstand angesagt.
Seit 10 jahren ist in im zb. Gaming Berreich nur Optimierung passiert.

Leonidas

2017-01-20, 04:32:40

AMD hat Technologien für Vega angekündigt, welche den Speicherbedarf drastisch reduzieren.
WCCF Tech, da sich bisher nur wenige scheinbar damit überhaupt beschäftigen:

Was sich aus dieser Folien lesen läßt, ist leider zu viel wenig griffig, um daraus einen großen Aufhänger zu machen.

Ailuros

2017-01-20, 08:25:18

Vega klingt ja wie ein Quantensprung gegenüber GCN. Für den Endanwender interessiert aber endgültig nur die nutzbare Leistung. Je nach Formfaktor sogar die Perf/Watt deutlich mehr.

Beide Projekte, also Vega und Zen sind vor 4~5 Jahren gestartet worden. Ich erwarte von beiden sehr viel.

Wenn man in der Lage ist, mit Vega an der derzeitigen Nvidia-Effizienz anzukratzen, dann kann man sich den absoluten BestCase vorstellen. Und die liegt eher in TXP-Regionen. Worst Case liegt eher auf GTX1080-Niveau.

Eins der klassischen Probleme bei AMD ist dass beim launch die Treiber zwar genug Stabilitaet liefern, es wird aber stets mit der Zeit noch einiges an Leistung nachgeliefert. AMD muss fuer VEGA den ersten Eindruck gewinnen koennen und das setzt einiges an Resources fuer Leistungs-optimierte Treiber voraus.

Es nutzt wenig bis gar nichts wenn sie sagen wir nach 6 Monaten nochmal z.B. 15% mit Treibern Schritt fuer Schritt nachladen.

M4xw0lf

2017-01-20, 08:32:36

Wenn sie wieder ein Nano-artiges Produkt bringen, dann sollten sie damit starten. Die neue Architektur von ihrer effizientesten Seite zeigen.

[MK2]Mythos

2017-01-20, 08:45:37

Wenn sie wieder ein Nano-artiges Produkt bringen, dann sollten sie damit starten. Die neue Architektur von ihrer effizientesten Seite zeigen.
Das ist auch meine Hoffnung. Viele, inklusive mir, bauen sich mit der kommenden Generation ein Mini ITX Gaming System zusammen und da wäre eine Vega Nano Karte wirklich optimal.

fondness

2017-01-20, 09:33:58

Vega klingt ja wie ein Quantensprung gegenüber GCN. Für den Endanwender interessiert aber endgültig nur die nutzbare Leistung. Je nach Formfaktor sogar die Perf/Watt deutlich mehr.

Genau hier sehe ich leider auch die größte Gefahr. NV hat es nach NV30 verstanden, Chips für aktuelle Spiele zu bauen. AMD verbaut leider immer wieder viele Transistoren, die erst in Zukunft einen Vorteil bringen, wenn meist schon der Nachfolger da ist. AMD treibt damit zwar die Entwicklung an, man verschenkt dadurch aber auch Leistung bzw. Perf/Watt in aktuellen Spielen. Vega klingt mir schon wieder sehr nach einen typischen neuen AMD Architektur: Viele interessante neue Features und Ansätze, aber vermutlich wird es wieder ewig keine Spieleuntersützung oder API geben, um diese Features überhaupt verwenden zu können.

Ailuros

2017-01-20, 09:41:01

Genau hier sehe ich leider auch die größte Gefahr. NV hat es nach NV30 verstanden, Chips für heutige Spiele zu bauen. AMD verbaut leider immer wieder viele Transistoren, die erst in Zukunft einen Vorteil bringen, wenn meist schon der Nachfolger da ist. AMD treibt damit zwar die Entwicklung an, man verschenkt dadurch aber auch Leistung bzw. Perf/Watt in heutigen Spielen.

Es gibt keinen einzigen IHV dort draussen der eine GPU fuer uebermorgen entwickelt. Es war schon immer so und das bei allen IHVs bei jeglicher neuen API zuerst die volle Funktionalitaet angezielt wurde und man mit Effizienz fuer diese in kommenden Generationen nachgeladen hat.

Ich weiss zwar nicht welche Maerchen Du Dir selber erzaehlen willst, aber so manche wichtige Aenderung in VEGA (betreffend Geometrie, blending/ROPs und tiled rasterizing u.a.) sind genau 2 Generation hinter NV und es sind eher DIESE Stellen wo sich heutige GeForces ihren Effizienz-Vorsprung holen koennen.

AMD soll lieber ihre Treiber besser optimieren fuer den launch.

Vega klingt mir schon wieder sehr nach einen typischen neuen AMD Architektur: Viele interessante neue Features und Ansätze, aber vermutlich wird es wieder ewig keine Spieleuntersützung oder API geben, um diese Features überhaupt verwenden zu können.

Die Zeiten sind fuer alle IHVs schon seit langem vorbei. Fuer solche Traeumereien verschwendet heutzutage keiner mehr Transistoren. Lies mal hier sebbi's Beitraege in dem thread: https://forum.beyond3d.com/posts/1962268/

deekey777

2017-01-20, 10:03:18

Ich verstehe die Aussage auch irgendwie nicht. Gerade DAAMIT hat damals mit dem R420 einen reinen Chip für heute entworfen, obwohl das SM 3 in greifbarer Reichweite war. Der R520 fehlte die FP16-Texturfilterung, dem R600 fehlte alles, der RV770 war erneut reiner Gamerchip mit Ausflug in GPGPU, Cypress war auch nicht der Überflieger, hat aber funktioniert. Und bei GCN blieben einige Flaschenhälse, was die "Spielbarkeit" angeht, trotzdem funktioniert es.

Meine Vermutung ist, dass AMD versucht, mit einem (skalierbaren) Chip bzw. einer skalierbaren Architektur und wenigen GPUs viele Bereiche abzudecken, wo Nvidia lieber mehrere Chips anbieten, die auf ihren speziellen Bereich abgestimmt sind. AMD wäre es bestimmt lieber 10000e Vega 10 als FirePro als 100.000e davon, aber nur für ein Zehntel des Preises. Spirch: Selbst wenn die Vega-Architektur aus Gamersicht unnötig fett ist, so kann diese Fettschicht im professionellen Bereich/GPGPU Entscheidungskriterium sein.

Ailuros

2017-01-20, 11:33:24

Es kann NIE jeglicher IHV ein zukuenftiges API zu 100% einschaetzen. In der Mehrzahl der Faelle kommt es zu leichtem Ueberfluss in ein paar Stellen, aber es kommt durchaus vor dass IHV A mit Faehigkeit X besser ankommt als IHV B und dann eben umgekehrt fuer Faehigkeit Y.

Ein frisches Beispiel fuer AMD ist async compute, fuer das sie sich deutlich besser eingeschaetzt hatten als NV.

Ich will hoffen dass er nicht irgendwelches TruForm Bumsfallera meinte.....

Armaq

2017-01-20, 11:49:42

y33H@

2017-01-20, 12:09:43

Das kommt massiv auf der Serie an, sowas wie 2900 XT oder X1800 waren schneller weg vom Fenster als zB 7970 oder 9700 Pro.

Der_Korken

2017-01-20, 13:10:45

Ich denke die Aussage, dass Nvidia-Chips weniger zukunftssicher sind, stammt noch von der damaligen Architektur der 5000er bis 7000er Serie von Nvidia. Ein Extrembeispiel war die 7900, die zum Release schneller und sparsamer als die X1900 von ATi war, während letztere ein, zwei Jahre später Kreise um die Nvidia-Karte gezogen hat. Auch die X1800 hat Jahre später noch erstaunlich gut abgeschnitten. Der G80 hat die Karten dann neu gemischt. Erst im Duell GTX680 vs 7970 kann man AMD etwas mehr Langlebigkeit ausstellen wegen mehr VRAM und mehr Rohleistung, die zum Release noch schlecht auf die Straße kam. Wer von beiden aus technologischer Sicht bzw. aus Chipdesign-Sicht fortschrittlicher war, kann ich nicht beurteilen.

robbitop

2017-01-20, 14:01:33

deekey777

2017-01-20, 14:23:59

OT, weil nichts anders gibt:
Das kommt massiv auf der Serie an, sowas wie 2900 XT oder X1800 waren schneller weg vom Fenster als zB 7970 oder 9700 Pro.

Der R600 war kaputt, die X1800 litt an der schwachen PS-ALU-Leistung, diese wurde beim R580 verdreifacht. RV670 war deutlich besser als der R600, aber auf längere Sicht wenig Leistung.

Der R300 und der R350 waren Overkill-Chips, aber spätestens mit dem Auftreten der UE3-Spiele, die mindestens PS 2.b voraussetzten, war Ende für den R300.

Die 7970 geht bspw auch ein wenig in die Richtung. Damals kam sie kaum gegen die GTX680 an. Heute hängt sie diese völlig ab (selbst die 4 GB Version). Extrembeispiel ist Doom, wo sie auf GK110 Niveau ist.

Tahiti war ja ein Neuanfang, weil Terascale doch nicht so überzeugt hat.

BlacKi

2017-01-20, 14:51:12

Die 7970 geht bspw auch ein wenig in die Richtung. Damals kam sie kaum gegen die GTX680 an. Heute hängt sie diese völlig ab (selbst die 4 GB Version). Extrembeispiel ist Doom, wo sie auf GK110 Niveau ist.
ist eigentlich ot. das liegt aber auch daran weil sie so lange verkauft, und nicht abgelöst wurden. die 680 war da schon lange bei den meisten aus dem rechner.

24p

2017-01-20, 14:51:25

Die 7970 geht bspw auch ein wenig in die Richtung. Damals kam sie kaum gegen die GTX680 an. Heute hängt sie diese völlig ab (selbst die 4 GB Version). Extrembeispiel ist Doom, wo sie auf GK110 Niveau ist.

Naja, der Vorgänger 58x0/69x0 sah aber dann wiederum auch langfristig eher mau aus gegen Fermi. Ansonsten muss AMD es einfach hinbekommen, dass die Treiber von Anfang an performen. In der Hoffnung darauf, dass Probleme nach dem Kauf schon gefixt werden kauft zurecht kaum einer, weil das im Schnitt auch eher nicht klappt. Da ändern auch die paar Fälle, bei denen das mal so gewesen ist nichts.

Ailuros

2017-01-20, 14:57:36

In den mir bekannten Langzeitbetrachtungen sind es aber genau diese Punkte. AMD hat über eine längere Laufzeit oft die bessere Performance, man könnte sagen ist zukunftsfähiger, immer im Vergleich mit dem Nvidia Pendant zu Release.

Ich bin gespannt wie ein Flitzebogen auf die Releases, kann mir aber kein rundes Bild machen.

https://www.computerbase.de/2017-01/geforce-treiber-test/2/

Die Benchmarks zeigen primär eine Sache: Während es bei AMD traditionell mit der Zeit größere – aber keine riesigen – Performance-Sprünge durch neue Treiber gibt, hat Nvidia die eigene Hardware bereits beim Start gut im Griff und auf maximale Leistung optimiert. Das zeigt sich auch bei der aktuellen Generation. Während AMD die Radeon RX 480 seit dem Erscheinen um etwa fünf Prozent beschleunigt hat, kann die GeForce GTX 1080 nur um ein Prozent zulegen – und hatte dazu noch einige Wochen mehr Zeit.

Was im ersten Augenblick vielleicht negativ klingen mag, ist aber absolut positiv. In den meisten Fällen quetscht der GeForce-Treiber bereits am ersten Tag die volle Leistung aus der eigenen Hardware. Die Leistungsverbesserungen durch neue Treiber fallen dementsprechend geringer als bei der Konkurrenz aus.

Als NV zuerst Kepler mit der GTX680 vorstellen wollte war anfangs ein relativ kleiner PCB, maessigere Leistung und MSRP geplant. Als sie die 7900-er von AMD sahen wurde ihnen klar dass sie mit etwas Zusatz es auch mit einer 7970 anlegen koennen und somit kam es auf ein groesseres PCB, hoehere und dynamische Frequenzen und einen pfiffigen Strassenpreis. NV engineering warnte damals deren Marketing-Abteilung dass noch einiges an Leistung in den AMD Treibern flach liegt, welches sie aber nicht von ihrer Entscheidung aufgehalten hat.

Es wuerde mich verdammt ueberraschen wenn ich das letzte vor ca. 5 Jahren nicht hier im Forum erwaehnt habe. Gibt es ein heutiges benchmark-parcour wo man mit heutigen Treibern eine 7970 mit einer 680 (oder sogar 780-wasauchimmer mit einer 290-wasauchimmer) direkt vergleichen kann?

robbitop

2017-01-20, 14:58:24

Ja naja - aber auch weil sie mehr Rohleistung hat. Damals wurde sie durch die Geometrieleistung oftmals abgebremst. Die Arithmetiklast ist aber angestiegen in Zwischenzeit, so dass sich der Bottleneck verschoben hat. Dadurch kann sie ihre Rohleistung besser ausfahren als früher. Ein Stück weit wird ihr sicherlich auch ihre nahe Verwandschaft zu den GPUs in den Konsolen helfen.

AMD verbaut seit den VLIW Architekturen weniger Kontrolllogik und kompensiert dies mit einer höheren Anzahl an Ausführungseinheiten. Die Rohleistung ist bis auf Ausnahmen schon recht lange deutlich höher. Bei NV holt man out of the box idR recht früh einen Großteil der maximalen Leistung. Bei AMD hat man aus o.g. häufig den Effekt, dass es noch einen 2. Frühling gibt. (wobei das viele nicht mehr betrifft, da sie dann längst eine neue Grafikkarte gekauft haben)

Naja, der Vorgänger 58x0/69x0 sah aber dann wiederum auch langfristig eher mau aus gegen Fermi. Ansonsten muss AMD es einfach hinbekommen, dass die Treiber von Anfang an performen. In der Hoffnung darauf, dass Probleme nach dem Kauf schon gefixt werden kauft zurecht kaum einer, weil das im Schnitt auch eher nicht klappt. Da ändern auch die paar Fälle, bei denen das mal so gewesen ist nichts.
Das hat mit dem Treiber nur z.T. etwas zu tun. Es liegt auch ein Großteil an den Bottlenecks und an der Ausnutzung über den Entwickler. Hohe Arithmetiklast und ein für die ALUs freundlicher Shadercode sind eben hier notwendig, damit die ALUs gut ausgelastet werden können.

Bezüglich Fermi und 58x0/69x0: keine Ahnung - mir liegen keine modernen Benchmarks vor - Insbesondere wo der VRAM nicht der Übeltäter ist. Hast du da etwas vorliegen? :)

Ailuros

2017-01-20, 15:00:29

Dass AMD mit Leistungsoptimierung druch die Treiber etwas hinterher hinkt ist eine Affaere der fehlenden Resources und kein merkwuerdiger Zufall.

Screemer

2017-01-20, 15:05:48

ist eigentlich ot. das liegt aber auch daran weil sie so lange verkauft, und nicht abgelöst wurden. die 680 war da schon lange bei den meisten aus dem rechner.
ähh whot? was soll denn das für ne logik sein?

Nightspider

2017-01-20, 15:23:51

Ich dachte das Software-Team bei AMD wurde letztes Jahr massiv aufgestockt?

Da darf man ja hoffen das aus Vega schon zum Release mehr herausgeholt wird als bei den vergangenen Generationen.

BlacKi

2017-01-20, 15:46:01

ähh whot? was soll denn das für ne logik sein?
umso länger eine karte verkauft wird, umso besser, umso länger wird der treiber gepflegt. das und das plus am speicher macht die amd karten so langlebig.

oder anders ausgedrückt, das nv schneller chips ablöst und rausbringt macht die nv karten kurzlebiger.

Felixxz2

2017-01-20, 16:10:54

Die gesamte GCN Reihe altert deutlich besser als die entsprechenden nV Pendants. Nicht nur aus VRAM Sicht.

Screemer

2017-01-20, 16:16:16

umso länger eine karte verkauft wird, umso besser, umso länger wird der treiber gepflegt. das und das plus am speicher macht die amd karten so langlebig.

oder anders ausgedrückt, das nv schneller chips ablöst und rausbringt macht die nv karten kurzlebiger.
770 und 760 basieren auf gk104. Letztere sind nur 4 monate vor den ersten maxwellkarten (gm107) erschienen. Du glaubst also die haben auch keine treiberpflege mehr bekommen?

BlacKi

2017-01-20, 16:27:58

Ailuros

2017-01-20, 18:24:17

weißt du noch als nv extra für die kepler karten in witcher 3 einen treiber nachgereicht hat, weil die leute sich beschwert haben das kepler dort unverhältnissmäßig schlecht abschneiden? ja, leider werden die alten chips etwas vernachlässigt. mit ordentlicher treiberpflege wäre kepler heute nicht so weit von pitcairn und tahiti entfernt, selbst wenn man den vram vorteil weglässt.

Der Computerbase writeup auf den ich verlinkt habe beweisst genau das Gegenteil. Kunterbunte Konspirations-thesen sind zwar schoen und gut, aber man muss sie auch dokumentieren koennen.

CompuJoe

2017-01-20, 18:36:47

Der Computerbase writeup auf den ich verlinkt habe beweisst genau das Gegenteil. Kunterbunte Konspirations-thesen sind zwar schoen und gut, aber man muss sie auch dokumentieren koennen.

Computerbase hat nicht den ersten Treiber für Kepler genommen sondern den ersten Windows 10 Treiber der etwas mehr als ein Jahr später erschien!

Kepler hatte zu Release von tw3 Performance Probleme.

Die haben mit 353.62 gestestet

Ailuros

2017-01-20, 18:48:29

Computerbase hat nicht den ersten Treiber für Kepler genommen sondern den ersten Windows 10 Treiber der etwas mehr als ein Jahr später erschien!

Kepler hatte zu Release von tw3 Performance Probleme.

Wobei die Leistung fuer Kepler verbessert wurde, besser spaet als nie. Jetzt frag mal die Herren im Treiberteam was fuer Kopfstaende sie anrichten mussten damit es zu einer Leistungsverbesserung in Witcher ueberhaupt kam.

Es ist nicht so dass bei jeglichem IHV die neueste hw nicht den staendigen Vorsprung hat, aber Kepler ist noch einige Meilen vom low level support entfernt. Ich will hoffen dass keiner erwartet dass egal fuer welchen IHV jedes zukuenftige Spiel und Treiber fuer antiquitierende hw zu 100% angepasst wird; noch schlimmer womoeglich noch ein getrenntes "build" fuer selbst >10 Jahre alte GPUs.

Calypso

2017-01-20, 19:58:56

und was haben die letzten 3 Seiten mit Spekulationen um VEGA zu tun? NICHTS!

Skysnake

2017-01-20, 21:32:06

zum HBCC könnte man spekulieren, das AMD es durch die HSA features endlich geschafft hat, das man die Daten aus dem Speicher asynchron holt. Also entweder auf Page oder gar auf Cacheline größe.

Wenn man sich die DX12 features anschaut zur Speicherreduzierung durch dynamisches Nachladen nur der Texturdetails, die man braucht, dann könnte das schon ziemlich viel bringen.

Wie sieht es denn eigentlich so wirklich real aus mit den Texturen usw. Wieviel Daten fasst man da wirklich innerhalb eines Frames oder von mir aus auch 10 an? Irgendwie habe ich da ein verdammt starkes Gefühl, dass das real an sich nicht wirklich mehr als ein paar hundert MB sind.

Screemer

2017-01-20, 21:45:02

Wenn folgende Werte und die AMD folie vergleicht, dann sind da das abgefasste vielleicht 15-20%:

http://imagescdn.tweaktown.com/tweakipedia/9/0/90_745_much-vram-need-1080p-1440p-4k-aa-enabled.png

http://cdn.wccftech.com/wp-content/uploads/2017/01/slides-19.jpg

Da kommt deine Schätzung mit wenigen 100mb schon hin.

uweskw

2017-01-20, 22:11:21

Genaue Daten über Größe der L1 und L2 Caches gab es seitens AMD noch nicht oder?

Es ließt sich aber fast so als würde AMD den HBM Speicher effizienter nutzen als noch bei Fiji.
........

Selbst wenn das Feature gut funktioniert das man VRAM einspart, so ist der Marketingeffekt negativ wenn AMDs Topdog nur 8GB besitzt während selbst die alte Titan X schon vor 2 Jahren, Anfang 2015, schon 12GB besaß.

Meines Wissens nach geht AMD durch HBM weit effizienter mit dem RAM um als NV.
Oder gibt es mittlerweile irgend ein Beispiel in dem die 4GB HBM der Fury eher limitieren als die 6GB der 980Ti ? Nein: Eher das Gegenteil.
Also wird man mit 8GB HBM bei AMD wohl auch weiter kommen als mit 12GB von NV.

greetz
US

24p

2017-01-20, 22:29:31

aufkrawall

2017-01-20, 22:33:26

Wobei die Leistung fuer Kepler verbessert wurde, besser spaet als nie. Jetzt frag mal die Herren im Treiberteam was fuer Kopfstaende sie anrichten mussten damit es zu einer Leistungsverbesserung in Witcher ueberhaupt kam.

Es wurde auch über Updates des Spiels selber die Leistung auf Kepler verbessert. Auch mit DX11 muss nicht alles der Treiber machen bzw. kann es nicht.
An vielen Stellen im Blood & Wine-DLC war die gute Leistung von GCN btw. wieder Geschichte.

Botcruscher

2017-01-20, 22:36:30

Natürlich limitieren die 4GB der Fury eher als die 6GB der TI. Da gibt es unendlich viel Beispiele, wobei erst die Frametimes wirklich interessant sind.

Keine Ahnung was ihr euch an der Werbefolie aufhängt aber selbst bei 50% Nutzung sind das im Moment 4GB oder respektive bald 8. Da wird auch nichts eingespart. AMDs Intention war eher die neuen Möglichkeiten anzudeuten. Da geht es vor allem um Verwaltung samt zusätzlichen Speicher außerhalb des HBM. Das Beispiel mit dem Echtzeit-Rendering war nicht von ungefähr. Ohne detaillierte Kenntnisse ist das Momentan nur Marketing und inwieweit Spieler profitieren komplett offen.

davidzo

2017-01-20, 23:48:48

Äh. Nö. Da gibt's genug. Wurde vor 2 Jahren mal mit Shadow of mordor getestet. Nur weil man das an den Balkenlängen nicht sehen kann, heisst es nicht, dass es keinen Einfluss gibt. Im Gegenteil, NV kommt mit zu wenig RAM besser zurecht aks AMD.

Nein, NV kommt mit weniger Bandbreite besser zurecht!

Bei dem absoluten Ramverbrauch tun die beiden sich nichts, höchstens die Art un weise wie aus dem Systemram geswapt wird unterscheidet sich ggf.
Der VRAM wird in erster Linie durch die Engine und API mit Texturen belegt. Das sind bei NV dieselben wie bei AMD, das ist keine Treibersache. Wie oft der Grafikchip dann darauf zugreift, was overdraw ist oder noch in caches liegt, das ist dann Sache der Chiparchitektur und der Treiber. Das ist aber eine Bandbeitenangelegenheit. Da hat NV im Moment klar die Nase vorn mit dem TBDR Ansatz...

Hübie

2017-01-21, 01:27:27

Die 7970 geht bspw auch ein wenig in die Richtung. Damals kam sie kaum gegen die GTX680 an. Heute hängt sie diese völlig ab (selbst die 4 GB Version). Extrembeispiel ist Doom, wo sie auf GK110 Niveau ist.

Hast du dazu valide Quellen? Vor allem Doom wurde ja seit Veröffentlichung nicht mehr getestet und gerade da tat sich viel seitens nVidia.

Und laut dem Artikel von BTR (http://www.babeltechreviews.com/hd-7970-vs-gtx-680-2013-revisited/view-all/) stimmt deine Aussage nicht. Die 7970 ist mal leicht schneller, mal leicht langsamer und nur dann signifikant schneller, wenn der 680 der VRAM ausgeht. Gehört zwar nicht zum Thema, aber steht im Kontext zukunftsorientierter Architekturlösungen. Denn ich hege ernste Zweifel dass AMD da allzuviel Resources drauf verwendet um spekulativ in fünf Jahren die Nase vorn zu haben. Es wird sicher jetzt schon Initiativen geben, die eine Einbindung entweder nach API Spec, wenigen Codezeilen oder Treibereingriff sicherstellen.

True Audio kennt ihr noch? Was ist eigentlich daraus geworden? Für VR auch nicht zu gebrauchen???

Locuza

2017-01-21, 06:13:13

Ab GCN Gen 4 verbaut AMD keine DSPs mehr, um Soundberechnungen per Fixed-Function-Hardware zu berechnen.
Der Nachfolger heißt TrueAudio Next und wird über die SIMD-Einheiten per Compute berechnet.
http://gpuopen.com/gaming-product/true-audio-next/

Es ist ein Teil der Liquid VR Initiative, aber von irgendwelchen Erfolgsgeschichten habe ich jedenfalls nichts mitbekommen.

Foobar2001

2017-01-21, 06:45:44

Fuer mich hat es auch nie Sinn gemacht irgendwelche DSPs zu verbauen wenn man daneben mit die effizienteste Compute-Kernel-Architektur mit Async-Compute hat. Schnappsidee.

uweskw

2017-01-21, 07:37:41

Natürlich limitieren die 4GB der Fury eher als die 6GB der TI. Da gibt es unendlich viel Beispiele, wobei erst die Frametimes wirklich interessant sind......

Richtig, es geht um Frametimes. Was irgend ein ein Programm als "belegter VRAM" anzeigt ist uninteressant. Außer dem kaputten SoM und GTA kenne ich kein Beispiel wo es wirklich am RAM liegt.
Kannst du mir mal eines der "unendlich vielen" geben?

greetz
US

robbitop

2017-01-21, 07:39:59

Entropy

2017-01-21, 07:48:30

die effizienteste Compute-Kernel-Architektur mit Async-Compute hat.ist das nicht paradox? erst weil die Compute Units nicht effizient laufen bringt Async-Compute soviel.
Wenn die effizient Ausgelastet wären wie bei NVidia, würde es auch kaum etwas bringen.

uweskw

2017-01-21, 08:18:44

@Hübie Getestet mit Vulkan
http://www.pcgameshardware.de/Doom-2016-Spiel-56369/Specials/Vulkan-Benchmarks-Frametimes-1202711/
Die 780ti ist hier langsamer als die 280X (Tahiti). Doom lastet GCN halt richtig aus.

Schade, nur fehlt bei den Frametimes wieder mal die 6GB 980Ti im Vergleich zur 4GB Fury unter 2160p .
Also ich hab echt noch keinen Bench gesehen wo die 4GB HBM der Fury eher limitieren als 6GB von NV. Außer beim kaputten SoM oder GTA.

greetz
US

Foobar2001

2017-01-21, 08:39:16

ist das nicht paradox? erst weil die Compute Units nicht effizient laufen bringt Async-Compute soviel.
Wenn die effizient Ausgelastet wären wie bei NVidia, würde es auch kaum etwas bringen.
Das ist ein Trugschluss. Es gibt genuegend Passes die prinzipiell fast keine ALU-Auslastung haben wie Depth-Pre-Pass und Schatten. Da hat auch NVIDIA keine magische Loesung um ihre ALUs voll zu bekommen.

Und ich glaube du hast meinen Satz falsch interpretiert. Auch ohne Async hat AMD immer noch eine sehr effiziente Architektur verglichen mit gaengigen DSP-Chips. Mit dem R&D aus dem Grafikbereich kann eigentlich nichts mithalten.

24p

2017-01-21, 10:08:21

Schade, nur fehlt bei den Frametimes wieder mal die 6GB 980Ti im Vergleich zur 4GB Fury unter 2160p .
Also ich hab echt noch keinen Bench gesehen wo die 4GB HBM der Fury eher limitieren als 6GB von NV. Außer beim kaputten SoM oder GTA.

greetz
US

Vor kurzem wurde hier von techpowerup ein Artikel gepostet, in dem erwähnt wurde, dass die fury x trotz guter fps schon Probleme hatte mit den Frametimes. Das war dort bei der 980ti nicht zu sehen.

Screemer

2017-01-21, 10:12:31

links please.

24p

2017-01-21, 10:19:46

Finde ich leider nicht mehr, da der Beitrag hier wg OT gelöscht wurde. Ich sehe hier aber auch weiterhin kein Diskussionsbedarf, da ich keinen Beweis dafür sehe, warum die fury x den RAM besser verwalten sollte als die 980ti. Das ist imo eine urban legend.

Screemer

2017-01-21, 10:25:54

und andere vielleicht anders rum. also put up or shut up wäre hier die devise. ;) aus dem lager der "fury verwaltet die 4gb besser" kam zumindest schon das doom beispiel.

24p

2017-01-21, 10:28:13

Äh. Nö. Die Beweispflicht liegt bei dir. Wer behauptet, dass eine secret sauce existiert, muss diese Nachweisen. Also put up or shut up. ;)

Und btw den Fehler aus Freundlichkeit mal einen kleinen Hinweis zu geben mache ich hier nicht mehr, da wird sofort versucht die Beweislast umzukehren.

Und btw:

https://www.computerbase.de/2016-11/call-of-duty-infinite-warfare-benchmark/2/#diagramm-speichermangel-in-infinite-warfare-auf-einer-4-gb-karte-amd

Hier mal ein Hinweis. Wo immer die 4 GB kritisch werden wird die fruy Probleme bekommen. Da kann schliesslich nicht gezaubert werden.

Isen

2017-01-21, 10:42:07

Naja... unnötige Einstellungen vornehmen um Probleme zu erzeugen ist was anderes...
Man tut so, als gäbe es das Problem, erwähnt aber zu keinem Zeitpunkt, dass mit Einstellung X diese nicht geben...( Ausnahmsweise in einem kleinen Satz ) kein Mensch spielt ein Spiel krampfhaft auf den höchsten Settings, damit es scheiße läuft. Und was die Praxisrelevanz betrifft, hat sich CB mit dem Kaby i3 auch keinen Gefallen getan.

Damit will ich das Problem aber nicht verteidigen, nur aufzeigen, dass man zu jedem Haar in der Suppe eine Tote Fliege machen kann, wenn man es so will.

iuno

2017-01-21, 11:02:49

Krampfhaft damit es scheiße läuft sicher nicht. Aber wer sich eine Karte für 600€ kauft, stellt einfach die höchsten settings ein und das wars. Ich kenne auch Leute die im Bereich 1060/480 kaufen, alles auf max. stellen (inkl. 8x AA) und sich dann wundern oder gar beschweren.

Verstehe die Diskussion eh wieder nicht. Dass Fiji zu wenig Speicher hat ist doch jedem klar.
Und bzgl. des hbcc, wodurch das Thema ja überhaupt aufkam: unfassbar wie man die Aussicht auf eine SSD oder lahmen extra Speicher auf der Karte begrüßen kann, die 970 aber gleichzeitig verteufelt. Man muss schon ehrlich bleiben, wenn man es so sieht dass es toll ist, lahmen Speicher extra zu haben, hatte Jensen recht. Es kann aber nicht bei AMD toll sein und bei nvidia böse.
Mit Vulkan/d3d12 liegt die Verantwortung beim Entwickler, mit dem Speicher umzugehen. Streaming macht eh schon jede engine. Man hat copy queues, um das parallel zu machen. Sofern kein langsamer zusätzlicher RAM auf der Karte ist, bleibt PCIe der Engpass. Und wer will schon ernsthaft die Alternative?

Isen

2017-01-21, 11:08:33

Tüllich ist das zu wenig. Ändert dennoch nichts daran, dass man aus einem Haar in der Suppe eine tote Fliege macht. ( Das Haar ist Symbolisch für den wenigen Speicher ^^ ;-) )

Was hat das noch mit der Realität zutun, wenn man so testet? Außer das man mit dem Finger drauf zeigen kann?
Wäre der PC eine Konsole wo man keinerlei Einstellungen vornehmen kann und als IST SO, wären diese Tests spitze.
Entsprechen aber nicht der Realität und sprechen nur die Deppen an die Planlos alles auf maximal stellen.

iuno

2017-01-21, 11:15:09

Es gab die Behauptung, Fiji hätte keine frametime Probleme bei zu wenig Speicher, wegen hbm und besserer Verwaltung und was weiß ich. Dann postet einer das Gegenbeispiel und gab heißt es, es sei realitätsfern? :facepalm:

Ist hatte auch oft in Foren gelesen, die 4 GiB HBM seien gegenüber den 6 GiB der Ti zu bevorzugen. Ist einfach Unsinn und unverantwortlich sowas zu verbreiten.

Isen

2017-01-21, 11:18:07

Es ist immer dann Realitätsfern, wenn durch das Anpassen der Settings das Problem zufriedenstellend abgemildert oder gar zu verhindern ist.
Tut es das nicht, ist es auch nicht Realitätsfern, doch solche Tests werden nicht vorrangig gemacht.
Ich verstehe auch nicht, wieso man jedesmal ein Roman schreiben muss, damit das kapiert wird.

Was ist so verdammt schwer daran?
Zeig mir ein Spiel wo die Krüppelkarte NICHT mit anepassten settings zufriedenstellend läuft.
Dass das zu dem damaligen Preis zwar ziemlich ätzend ist, das tun zu müssen, steht hier außer Frage. Aber man tut hier ständig so, als ob mit der Karte es zu keinem Zeitpunkt etwas läuft.

Hier mal ein Beispiel von dir:

Krampfhaft damit es scheiße läuft sicher nicht
In der selben Zeile dann:

Ich kenne auch Leute die im Bereich 1060/480 kaufen, alles auf max. stellen (inkl. 8x AA) und sich dann wundern oder gar beschweren.
Das ist eine Rechtfertigung jener Tests die genauso wie deine "Leute" Krampfhaft alles auf max stellen und sich wie die Redakteure und Leser dann beschweren.

Und dann schreibst du wieder eine Rechtfertigung die in der Vergangenheit liegt, die mit meiner Aussage aber nur wenig gemein hat.

iuno

2017-01-21, 11:24:27

Natürlich wird keiner so spielen und natürlich ist es daher realitätsfern, darum geht es aber nicht! Es geht darum, ob man mit mehr angefordertem als vorhandenen Speicher noch anständig zocken kann. Und das ist natürlich bei Fiji genauso wenig der Fall wie irgendwo sonst. Wäre es nämlich kein Problem, wäre es auch absolut realistisch. Es gibt aber keine secret sauce, die dieses Verhältnis verschiebt.

Da wird einfach behauptet, die Karte käme mit weniger Speicher verhältnismäßig besser (!) klar und dann meint man eigentlich damit, dass man die settings ja anpassen kann. Einfach unfassbar sowas

Hier mal ein Beispiel von dir:
[...]
Das ist eine Rechtfertigung jener Tests die genauso wie deine "Leute" Krampfhaft alles auf max stellen und sich wie die Redakteure und Leser dann beschweren.
Es ist nicht krampfhaft, wenn man es nicht besser weiß, nichts anderes sollte damit gesagt werden.

Isen

2017-01-21, 11:25:57

Mir geht es aber darum, und du machst daraus etwas, was du für richtig hältst und damit rennst du gegen eine Wand. Merkst du es nicht?
Renn ruhig weiter. Das ist Palaver der hier nicht hingehört. Ansonsten mach es per PN.

Da wird einfach behauptet, die Karte käme mit weniger Speicher verhältnismäßig besser

Was interessiert mich was die Typen da labern? Gehört nicht hier hin, hab damit nix am Hut!

Hast nun eh eine PN von mir.

Zergra

2017-01-21, 11:27:13

Ihr driftet schon wieder extrem Stark ins OT ab...

iuno

2017-01-21, 11:27:39

Mir geht es aber darum
In dem Fall ist es eh völlig OT. Verstehe nicht was du dann überhaupt damit hier willst. Es ging um den hbcc, also einfach mal beim Thema bleiben.
Was interessiert mich was die Typen da labern? Gehört nicht hier hin, hab damit nix am Hut!
Außer, dass das genau hier im Thread wieder passiert ist und du unmittelbar darauf antwortest halt.
Und noch eine Sache zum Abschluss: wenn wegen des hbcc in Werbung, in initialen Tests und in Foren suggeriert wird, dass 8 GiB sich wie 12 oder 16 verhalten, es am Ende aber eben nicht überall so der Fall ist, wird es sehr wohl wieder zu einem realistischen Problem.

Screemer

2017-01-21, 11:36:44

du hast überhaupt noch nicht gesehen ob und wie es funktioniert, beschwörst aber schon die nicht vermeidbaren probleme herauf. :ugly:

Skysnake

2017-01-21, 12:07:20

Kriton

2017-01-21, 12:24:27

Ich würde auch noch weiter gehen und behaupten, dass eine (mögliche) zusätzliche Anbindung langsameren Speichers als klassischer V-RAM bei AMD eine ganz andere (möglicherweise sinnvolle) Funktion erfüllt als die 0,5 GB bei Nvidia, die beim Speicherzugriff darauf die 3,5 GB "blockieren".

24p

2017-01-21, 12:51:34

Skysnake

2017-01-21, 13:28:11

Bei der 970 wird aber das komplette speicherinterface blockiert, wenn man auf die 0,5GB zugreift und dazu auch noch die Caches kaputt gemacht. Das kann schon durchaus sogar mehr Aufwand sein, als etwas aus dem RAM über PCI-E zu holen. Müsste man halt mal ausmessen, wobei das wohl nicht so einfach wird.

Achill

2017-01-21, 13:43:12

Darum geht es nicht. Klar ist was NV dort gemacht hat was anders. Hier ging es aber eher darum, dass man schlecht sagen kann, dass 50% mehr VRAM egal sind, während man bei der GTX970 klar sehen kann, dass selbst das Fehlen eine viel geringeren Menge schon Probleme bereitet ggü echten 4GB.

Nein, bei der GTX 970 ist es aben nicht nur das "fehlen" sondern auch das die Einschränkung wie der VRAM bzgl. lesen/schreiben verwendet werden kann.

Vega - nach unserer aktuellen Spekulation - kann hingegen immer voll auf die HBC zugreifen und darüber hinaus auf pot. verfügbaren VRAM / SSD und muss dafür auch nicht über PCIe.

Wir kennen darüber auch nicht die Bandbreite (oder hab ich etwas überlesen) zwischen HBCC und mit dem attached VRAM/SDD angebunden ist. Gibt es da schon Infos?

Eine ganz naive Frage: Könnte eine Abwandlung einer Ryzen-CPU anstatt eines "Speicherkontroller" an die HBCC "angeschlossen" werden um auf RAM zu zugreifen?

Dann könnten auch andere Produktfelder abgedeckt werden (Konsole, HPC, Automotive, ...)

BlacKi

2017-01-21, 14:18:54

Schade, nur fehlt bei den Frametimes wieder mal die 6GB 980Ti im Vergleich zur 4GB Fury unter 2160p .
Also ich hab echt noch keinen Bench gesehen wo die 4GB HBM der Fury eher limitieren als 6GB von NV. Außer beim kaputten SoM oder GTA.

greetz
US
https://youtu.be/n4UV9SmKfcA?t=237

springt heftig zwischen 10 und 32ms beim laufen.

dargo

2017-01-21, 16:21:21

Das muss nicht zwangsläufig an zu wenig Vram liegen. Kann genauso der miese D3D11 Treiber sein. Die ~10-15ms Fluktuationen gibts nämlich auch in deinem Video bei Szenen die sich nicht verändern.

BlacKi

2017-01-21, 18:18:25

dx12 https://youtu.be/afA9A88hP_M?t=197macht das ganze aber nicht besser^^

Hübie

2017-01-21, 18:21:51

@Hübie Getestet mit Vulkan
http://www.pcgameshardware.de/Doom-2016-Spiel-56369/Specials/Vulkan-Benchmarks-Frametimes-1202711/
Die 780ti ist hier langsamer als die 280X (Tahiti). Doom lastet GCN halt richtig aus.

Wie gesagt wurde seit Release viel getan. Ein neuer Test wäre da hilfreich. BTR hat da zumindest den umfangreicheren Artikel, der jedoch noch älter ist. Dort kann man jedenfalls entnehmen, dass Doom offenbar eine Ausnahmesituation ist (was sich mittlerweile geändert haben kann). Der Test neulich auf computerbase hat auch noch mal 4-5% Performancezuwachs für Kepler nachgewiesen. Ich halte es also nach wie vor für einen Irrglauben, AMDs Karten würden langsamer altern. Korreliert man die Zahlen unter Berücksichtigung, der schlechten Release-Zustände kommt ein üblicher Gewinn von 4-5% heraus. Kochen beide nur mit Wasser.

Nachweisen kann ich meine Behauptung zwar nicht (da ich nicht über die Mittel verfüge), aber das Gegenteil wurde mir ebenfalls nicht bewiesen. Wenn man ein Performancerating macht nimmt man ja eh einen Mittelwert und streicht Ausreißer bzw. betrachtet diese gesondert.

Ich finde Leo seine Auflistung von GPU-Bestandteilen immer ganz nützlich um zu sehen wo Stärken und Schwächen sind. Hawaii glänzte afair mit einer übermäßig starken blend-power (breites SI + viele ROPs), aber dann in Relation wenig Texel-power.

https://abload.de/img/amd_hawaii_comparisonx3s32.png (http://abload.de/image.php?img=amd_hawaii_comparisonx3s32.png)

Das deutet für mich einfach auf ein nicht optimal balanciertes System hin (erst mal unabhängig von der Flexibilität und den Features). Ich würde es begrüßen wenn Freiwillige mit Kepler & Tahiti hier vortreten und gegentesten. :biggrin:

dx12 https://youtu.be/afA9A88hP_M?t=197macht das ganze aber nicht besser^^

Interessant: Das was die Fury weniger im VRAM hat, hat diese mehr im DRAM und bei NV ist's im VRAM. Die Summe ist also bei beiden ziemlich gleich. Auf der Fury merkt man am Ende wo er durch die Gassen geht klare Ruckler (was jedoch auch am Video liegen kann - haben die NV-Karten jedoch nicht). Ich mein irgendwo muss ja so eine Textureupload herkommen. ;) Wie läuft das bei Fiji? Auch über eine dual DMA-Engine?? :confused:

BlacKi

2017-01-21, 18:37:36

Interessant: Das was die Fury weniger im VRAM hat, hat diese mehr im DRAM und bei NV ist's im VRAM. Die Summe ist also bei beiden ziemlich gleich. Auf der Fury merkt man am Ende wo er durch die Gassen geht klare Ruckler (was jedoch auch am Video liegen kann - haben die NV-Karten jedoch nicht). Ich mein irgendwo muss ja so eine Textureupload herkommen. ;) Wie läuft das bei Fiji? Auch über eine dual DMA-Engine?? :confused:
wenn man nun den sysram auf die grafikkarte baut, umgeht man den pci express und kann den teuren schnellen hbm speicher dafür nutzen wozu er gut ist und nicht um gerade nicht benötigte texturen vorzuhalten bis man sie wieder braucht.

am besten nachrüstbar:love2:

Hübie

2017-01-21, 18:46:20

Dann musst du irgendwas breit* angebundenes in der GPU haben, was auch vom DRAM profitieren kann. "Hinter" dem HBM würde ein IMC im baselayer des HBM voraussetzen.

*Breit in Relation zum PCIe-Bus.

aufkrawall

2017-01-21, 19:05:34

dx12 https://youtu.be/afA9A88hP_M?t=197macht das ganze aber nicht besser^^
Die Fury fängt ja schon an zu stocken, bevor der VRAM überhaupt ansatzweise voll ist. :freak:

BlacKi

2017-01-21, 19:19:26

meinst du jetzt im video oder generell im spiel, selbst wenn man den texturregler auf minimum stellt?

StefanV

2017-01-21, 21:50:20

wobei man hier auch nicht die Stromsparmechanismen nicht ausschließen kann/darf...

woodsdog

2017-01-22, 08:36:03

Seitenlang schon wieder der selbe OT Mist über Fiji, 970 und Frametimes... Es nervt!
Es geht hier um Vega!!! :P

Hübie

2017-01-22, 10:50:03

Hättest du gelesen, wäre dir aufgefallen, dass es auch um die Langzeitinvestition in eine Architektur geht. ;) Vega wird laut einigen Aussagen Anpassungen in der Software erfordern und da muss man nun hinterfragen wie aufwändig das ganze ist und wie breitflächig vergangene Engine diesbezüglich angepasst wurden. Denkbar wäre auch eine Realisierungen bestimmter Features (bzw. die Art diese zu implementieren / auszuführen) über die GPU-Open-Initiative gelöst werden und den Rest macht ein Treiber. Es ist ärgerlich wenn ältere Spiele schlechter mit moderner API laufen, als in Relation zu den Vorgängerprodukten.

BlacKi

2017-01-22, 10:56:07

Seitenlang schon wieder der selbe OT Mist über Fiji, 970 und Frametimes... Es nervt!
Es geht hier um Vega!!! :P
es ging darum ob 8gb hbm für vega reichen. und dann haben die leute ausreden gesucht, dafür kann ich nichts^^

johla

2017-01-22, 11:03:12

Ich habe jetzt nicht den ganzen Thread gelesen. Im Internet habe ich gelesen, dass der Vega die nVidia 1080 schlagen soll. Stimmt das?

BlacKi

2017-01-22, 11:08:46

der einzigste performance hinweis ist die vega demo von doom. die karte liegt in doom knapp über einer 1080, die karte ist aber noch nicht fertig und wird vermutlich schneller als dort gezeigt.

Zergra

2017-01-22, 11:13:02

Ich habe jetzt nicht den ganzen Thread gelesen. Im Internet habe ich gelesen, dass der Vega die nVidia 1080 schlagen soll. Stimmt das?
Das ist ja auch wohl das mindeste was die Karte bieten soll. Sonst könnte man es auch gleich lassen.

Monsta

2017-01-22, 11:23:04

Das ist ja auch wohl das mindeste was die Karte bieten soll. Sonst könnte man es auch gleich lassen.

Was für ein Quatsch, wenn sie langsamer aber dafür günstiger ist, ist doch alles in Ordnung,

dargo

2017-01-22, 11:45:12

es ging darum ob 8gb hbm für vega reichen.
Ja, wird reichen. Zumindest bis 1440p, für 2160p wird Vega eh zu langsam sein (max. Details). Ansonsten wäre auch eine GTX1080 obsolet.

BlacKi

2017-01-22, 11:57:46

Ja, wird reichen. Zumindest bis 1440p, für 2160p wird Vega eh zu langsam sein (max. Details). Ansonsten wäre auch eine GTX1080 obsolet.
eine 1080 wird 1 jahr früher aus dem markt gehen.

Entropy

2017-01-22, 12:06:32

Das ist ein Trugschluss. Es gibt genuegend Passes die prinzipiell fast keine ALU-Auslastung haben wie Depth-Pre-Pass und Schatten. NVidia hat eine bessere Auslastung in diesen Fällen, z.B. aufgrund von weitaus besserer Framebuffer Kompression, mehr Rasterizern, schnellerem Triangle-Setup usw.

Da hat auch NVIDIA keine magische Loesung um ihre ALUs voll zu bekommen.
NVidia hat Concurrency auf Taskebene.
http://images.hardwarecanucks.com/image//skymtl/GTC/GTC-21.jpg
Async Compute ist also implizit vorhanden.
Auf AMD hast du einen neuen Context sobald du einen neuen Schader hast, und das bedeutet, dass die 4095 "Kerne" warten bis der letztes zuenderotiert ist. (Es sei den ich intepretiere deren magere Dokumentation falsch).
Explizites Async-Compute hilft dann vermutlich, aber es wird weiterhin nicht genau so effizient sein.

Und ich glaube du hast meinen Satz falsch interpretiert. Auch ohne Async hat AMD immer noch eine sehr effiziente Architektur verglichen mit gaengigen DSP-Chips.
Custom DSP sind weit aus effizienter, die arbeiten mit simplen int16-ALUs (das ist noch einfacher als die half-ALUs). Wenn AMD das per Async Compute macht, dann nicht weil ihre Architektur effizient ist, sondern weil sie brach liegt, weil das Frontend und Backend nicht mithalten kann.

Aus der Sicht hast du recht, es macht nur Sinn brachliegendes auszunutzen. Sie könnten auch Video Encoding auf Async Compute verlagern. Es würde Ihre Transistoren besser auslasten, aber eben nicht weil Sie so effizient sind, sondern weil Sie die ALUs nicht versorgen können.
Jede andere Firma setzt auf sehr viel effizientere Custom bestandteile.

Entropy

2017-01-22, 12:17:12

Ich habe jetzt nicht den ganzen Thread gelesen. Im Internet habe ich gelesen, dass der Vega die nVidia 1080 schlagen soll. Stimmt das?Der einzige Test ist auf Doom-Vulkan. Das ist auf AMD optimiert und deswegen 30% schneller. Auf NVidia läuft es 1:1 wie die OpenGL Version.
Bezogen also auf normale Spiele die nicht nur auf eine Platform optimiert wurden, ist eine Leistung des Prototyps unter der 1080 zu erwarten. Vielleicht schafft AMD es mit verbesserten Treibern und besserer Fertigung/Taktung bis zur Erscheinung auf 1080 Niveau zu kommen.
Wenn Sie dann 50 Watt mehr verbrauchen, 50 Euro weniger kosten, ist es ein normales AMD Angebot.

dargo

2017-01-22, 12:19:44

eine 1080 wird 1 jahr früher aus dem markt gehen.
Und deshalb braucht Vega 16GB. :facepalm:

Setsul

2017-01-22, 12:33:30

Was für ein Quatsch, wenn sie langsamer aber dafür günstiger ist, ist doch alles in Ordnung,
314mm² + GDDR5X bei der 1080 vs ~500mm² + HBM2 bei Vega 10.
Welche Karte wird wohl billiger herzustellen sein?

Wenn sich V10 nicht mit GP102 anlegen kann wäre Vega ein Rückschritt im Vergleich zu Polaris.

Wenn V10 langsamer ist als eine 1080 dann kann man den Laden dicht machen.

koffeinjunkie

2017-01-22, 16:22:41

Stimmt es das der Release von Vega wieder verschoben wurde oder gibt es konkrete Details mittlerweile?

BlacKi

2017-01-22, 16:26:58

h1 steht wohl noch, aber es gibt spekulationen die sagen das es für consumer und custom karten herbst wird.

dargo

2017-01-22, 17:03:07

wer will 2018 noch 8gb kaufen?
Vega kommt 2017.

Gipsel

2017-01-22, 17:35:01

NVidia hat eine bessere Auslastung in diesen Fällen, z.B. aufgrund von weitaus besserer Framebuffer Kompression, mehr Rasterizern, schnellerem Triangle-Setup usw.Damit schließt Du maximal diese Abschnitte schneller ab, an der grundlegenden Sache ändert es nicht ganz so viel.
NVidia hat Concurrency auf Taskebene.
http://images.hardwarecanucks.com/image//skymtl/GTC/GTC-21.jpg
Async Compute ist also implizit vorhanden.
Auf AMD hast du einen neuen Context sobald du einen neuen Schader hast, und das bedeutet, dass die 4095 "Kerne" warten bis der letztes zuenderotiert ist. (Es sei den ich intepretiere deren magere Dokumentation falsch).Da bist Du aber kräftig auf dem Holzweg. Deine gezeigte Grafik gilt übrigens nur für Compute bei nV. Traditionell geht gleichzeitiges Ausführen von Shadern aus einem Grafik-Kontext und aus einem Compute-Kontext bei nV nicht. Und zwar GPU-weit. Erst mit Pascal können die SMs einzeln den Kontext switchen (Grafik und Compute auf einem SM mischen geht aber immer noch nicht). Vorher mußte die komplette GPU warten, bis jeder einzelne Thread eines Grafikshaders beendet war, um dann die ganze GPU auf Compute zu schalten. Andersrum genauso. Daher kommen die Performance-Einbrüche bei nV mit vielen Kontext-Switches.
Bei AMD können dagegen beliebige Shader und beliebige Kontexte gleichzeitig laufen. Nicht nur auf der GPU sondern auch in jeder einzelnen CU. Und das schon so lange es GCN gibt. Die einzige Beschränkung für die Ausführung eines Shaders bei AMD ergibt sich durch die verfügbaren Ressourcen (Register, LDS). Im Prinzip könnte eine CU 40 verschiedene Shader aus 40 verschiedenen Kontexten gleichzeitig laufen lassen. Da bietet die Hardware deutlich mehr als bei nV, nämlich maximale Flexibilität. Und dies erlaubt es eben besser als bei nV-GPUs, in bestimmten Abschnitten des Renderns des Bildes brachliegende Ressourcen für anderen Aufgaben zu nutzen. AMD-GPUs benötigen gar keinen Kontext-Switch, da man schlicht beliebige Kontexte simultan abarbeiten kann.

Zergra

2017-01-22, 17:39:54

h1 steht wohl noch, aber es gibt spekulationen die sagen das es für consumer und custom karten herbst wird.
Wäre schade, ich wollte eigentlich in H1 was kaufen. Am besten noch Q1.

Entropy

2017-01-22, 22:47:11

Da bist Du aber kräftig auf dem Holzweg. Deine gezeigte Grafik gilt übrigens nur für Compute bei nV. Traditionell geht gleichzeitiges Ausführen von Shadern aus einem Grafik-Kontext und aus einem Compute-Kontext bei nV nicht. ...
Die Grafik gilt auch für nur 3d Rendern, Aber darum ging es nicht. Die Darstellung gilt für einen einzigen Context (OpenGL) bzw Commandbuffer (Vulkan/D3D12).
Bei AMD läuft es wie in der linken Darstellung ab. Wenn du einen Shader wechselst, hast du intern neue Context die nicht simultan laufen. Das sorgt dafür, dass die GPU oft nicht ausgelastet ist, bei NVidia, wie du rechts siehst, kann ein Commandbuffer die GPU ausgelastet halten.

Du kannst auf Cuda mehrere(10) Commandbuffer laufen lassen, aber seit NVidia die Dispatches so zusammenfasst, macht das eigentlich niemand, weil du durch mehrere Commandbuffer mehr Schaden anrichtest (z.B. beim Caching) als du durch Auslastung bekommst.
Mag sein, dass der Depth-Pre-Pass die ALU nicht auslastet, aber dann ist es Fillrate limitiert. Dein Async-Compute Dispatch wird nicht mit 0 Daten auskommen, also hast du unkontrolliertes Trashing am L2.

Async Compute bringt nur etwas, wenn das Frontend schon die Einheiten nicht auslasten kann. Saturierst du an irgendwas vom Middle- bzw Backend, schadet es wenn du noch mehr Auslastung probierst.

Foobar2001

2017-01-22, 23:26:39

Es ist hanebüchener Unsinn, dass Radeons nicht mehrere Contexte in flight haben können. Es gibt ein Limit, aber das hat auch NV.

Im Übrigen muss die Tri-Order immer eingehalten werden und der Rasterizer arbeitet immer nur an einem Program, was die Parallelität bei beiden einschränkt. Overlap gibt es nur in der Zeit in der Wechsel stattfinden.

Entropy

2017-01-23, 00:18:14

Es ist hanebüchener Unsinn, dass Radeons nicht mehrere Contexte in flight haben können. Es gibt ein Limit, aber das hat auch NV.Laut Doku kann GCN 1 bis 7 Context haben, was von der GPU abgefragt werden kann. Das sind uU nur 7 Zeichenaufrufe.

Im Übrigen muss die Tri-Order immer eingehalten werden
Möchtest du, dass Tri-Order auch bei Fragments eingehalten wird, musst du ROVs nutzen. Andernfalls laufen Shader auch bei überlappenden Pixeln simultan. ROP order != Fragment Order.
und der Rasterizer arbeitet immer nur an einem Program, was die Parallelität bei beiden einschränkt. Overlap gibt es nur in der Zeit in der Wechsel stattfinden.Nein, es gibt 6 Rasterizer und die arbeiten voneinander unabhängig, da sie in einem Grid unterschiedliche Pixel bedienen. Das ist aber wirklich nicht relevant dazu, wie die Cores ausgelastet sind.
Was relevant ist, ist ob der Rasterizer, bzw sogar der Command Prozessor warten muss, bis vorherige "Context" fertig sind, um einen neuen zu setzen.

(läuft hier Nachts ein Backup oder so? Zig mal geht mein Post verloren beim Submit :( )

Gipsel

2017-01-23, 01:26:25

Die Grafik gilt auch für nur 3d Rendern, Aber darum ging es nicht.Mehrere Grafikshader zu überlappen (z.B. Vertex mit Pixelshader) können GPUs solange es unified Shader GPUs gibt. Das ist ja nicht das Problem. Das Problem von nV ist es, Grafik und Compute zu überlappen. Und genau dafür gilt Deine Grafik eben nicht (zumindest bei nV, bei AMD hat man da seit GCN sehr flexibel).
Die Darstellung gilt für einen einzigen Context (OpenGL) bzw Commandbuffer (Vulkan/D3D12).Hmm, ich schrieb davon, mehrere Kontexte parallel auszuführen. ;)
Bei AMD läuft es wie in der linken Darstellung ab. Wenn du einen Shader wechselst, hast du intern neue Context die nicht simultan laufen. Das sorgt dafür, dass die GPU oft nicht ausgelastet ist, bei NVidia, wie du rechts siehst, kann ein Commandbuffer die GPU ausgelastet halten.Das ist absoluter Bullshit. Sorry für die Wortwahl, ist aber einfach so.
Du kannst auf Cuda mehrere(10) Commandbuffer laufen lassen, aber seit NVidia die Dispatches so zusammenfasst, macht das eigentlich niemand, weil du durch mehrere Commandbuffer mehr Schaden anrichtest (z.B. beim Caching) als du durch Auslastung bekommst.GCN-GPUs handhaben mehrere Compute-Queues/Commandbuffer einfach so. Oder hast Du dich mal gefragt, was die ACEs so tun? Und die arbeiten parallel zum Grafik-Commandprocessor. Das geht also auch gleichzeitig mit Grafik (und die CUs können eben auch alles gleichzeitig ausführen).
Mag sein, dass der Depth-Pre-Pass die ALU nicht auslastet, aber dann ist es Fillrate limitiert. Dein Async-Compute Dispatch wird nicht mit 0 Daten auskommen, also hast du unkontrolliertes Trashing am L2.Wenn die ROPs das Limit sind, paart man es eben mit irgendwas, was nicht ROP-limitiert ist (Compute exportiert selten über die ROPs, man liest und schreibt meist über die TMUs, das ist ein komplett anderer Datenpfad in der GPU). Durch die parallele Ausführung sinkt die gesamte Ausführungszeit gegenüber der sequentiellen Ausführung.
Beispiel:
Shader A nutzt 10% der ALU Ressourcen und 100% der ROPs.
Shader B nutzt 100% ALU und 10% der ROPs. Beide laufen gleich lange, nämlich die Dauer T. Die sequentielle Ausführung dauert dann 2T. Die parallele Ausführung im Optimalfall nur 1.1T (praktisch vermutlich minimal länger, aber wohl so ziemlich immer unter 2T).
Und L2-Trashing ist auch kein Problem. Momentan bei AMD sowieso nicht (ROPs hängen gar nicht am L2, die haben ihre eigenen getrennten Caches). Und mit dem Tiled Binning Raster Ansatz sammelt man ja die Geometrie in ScreenTiles und rendert dann die Tiles nacheinander. Im L2 sitzt also erstmal immer nur eine Screentile des Framebuffers. Und die Tilegröße (und L2-Größe) wählt man natürlich hoffentlich so, daß noch genügend Platz im L2 für anderen Kram bleibt ;).
Async Compute bringt nur etwas, wenn das Frontend schon die Einheiten nicht auslasten kann. Saturierst du an irgendwas vom Middle- bzw Backend, schadet es wenn du noch mehr Auslastung probierst.Das ist schlicht falsch. Wie Foobar Dir schon gesagt hat, kannst Du eine GPU beim Rendern prinzipiell nicht mit nur einer einzigen Aufgabe immer voll auslasten (d.h. alle Komponenten wie z.B. ALUs, TMU, ROPs, Rasterizer laufen immer alle am Anschlag). Wenn Teile des Codes einen anderen Flaschenhals haben als andere Teile, dann hilft es, diese zu überlappen. Das gilt ganz generell, auch für nV.

=========================

Laut Doku kann GCN 1 bis 7 Context haben, was von der GPU abgefragt werden kann. Das sind uU nur 7 Zeichenaufrufe.Ich würde gerne mal diese Doku sehen. Also um zu wissen, auf was Du Dich da überhaupt beziehst.

PS:
Zu dem AA-Kram schreibe ich hier lieber nichts mehr, OT und so. Höchsten trumpiere ich noch eine kurzes "Wrong!"

Foobar2001

2017-01-23, 06:01:06

Laut Doku kann GCN 1 bis 7 Context haben, was von der GPU abgefragt werden kann. Das sind uU nur 7 Zeichenaufrufe.
Wie gesagt, es gibt ein Limit. Wenn zu viel in Flight ist muss der naechste Aufruf warten.

Das ist aber bei NVIDIA auch nicht anders, der Chip muss ja irgendwo Buch fuehren und hat dafuer nur endliche Resources. Ich weiss es nicht, aber ich denke das Limit ist hoeher.

AMD hat vor Vega auch das Problem dass bei Framebuffer Read after Write der L2 dran glauben muss, weil die ROPs nicht koeherent sind.

Gipsel

2017-01-23, 17:04:43

Die AA-, AF- und Auflösungsdiskussion kann in dem Thread (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11273095#post11273095) weitergeführt werden.

Der_Korken

2017-01-25, 12:53:32

Es spräche doch nichts dagegen, dass AMD eine zusätzliche 16GB-Version nachreicht für diejenigen, die Angst haben, dass ihnen der Speicher ausgeht. Eventuell wird das dann so wie bei der 290 gemacht: 2017 kommt V10 mit 8GB und 2018 ein kleiner Refresh/Rebrand mit 16GB. Bis dahin ist HBM2 vielleicht billig genug, um sowas anbieten zu können, denn wenn 2017 dann die 16GB-Version mit >200€ Aufpreis auf die 8GB-Version kommt, wird bestimmt auch wieder gemeckert. Man sollte auch bedenken, dass Nvidia bis heute eine 8GB-Performance-Karte (1080) für 600€+ verkauft.

Digidi

2017-01-25, 13:30:18

Die Speichermenge steigt immer an, auch ohne neue Konsolen, das war doch die letzten Jahre auch so.
Von daher sind 8GB für nen High End Chip mitte 2017 eigentlich unterstes Limit. Im Prinzip sehen wir wie bei der Fury einen V-ram Krüppel für diese Leistungsklasse.

Manchmal verstehe ich die AMD Befürworter nicht. Bei der Midrangekarte GTX 1060 vs RX480 wird sich ewig wegen der 2GB gestritten, die so wichtig sind und nun bei der hoffentlich doppelt so schnellen Karte sind 8GB wieder für die nächsten 2 Jahre dicke ausreichend. Also man kann immer wieder was neues lernen.

Koduri weiß genau warum sie mit der V-ram Senken Nummer um die Ecke kommen, womöglich weil 16GB HBM viel zu teuer sind und 8GB einfach zu schmal sind und sie das irgendwie kompensieren müssen, weil Nvidia wohl 10 oder 12GB anpreisen wird.

o.
AMD hat eine Technik integriert, die den Speicherbedarf um 50 Prozent senkt. Also sind 8GB AMD = 16 GB Nvidia. Wobei man das nicht 1 zu 1 vergleichen kann. Also warum mehr verbauen? Koduri und die AMD haben sich halt was einfallen lassen!

Natürlich hätte er da den HBM Preis im Kopf. Ich frag mich dann ob das SI auch doppelt so schnell ist, denn es muss ja nur die Hälfte der Daten schieben!

Agent117

2017-01-25, 13:33:48

Richtig. Vega 10 kann beides.
Viel interessanter finde ich den Punkt ob man bei Vega 11 auch auf HBM oder auf GDR5X setzt. An GDR5X haben AMD Mitarbeiter laut Linkedin Einträgen gearbeitet. Man wäre auch flexibler was die Bandbreite angeht. Bei HBM wäre man an 256 GB/s gebunden, außer man nutzt wie bei Vega 10 zwei Stacks. Mit GDR5X könnte man auch relativ günstig 288 oder 320GB/s liegern, was besser zur erwarteten Leistung von V11 zwischen P10 und V10 passen würde.

Ansonsten finde ich fraglich ob eine 1080 Ti überhaupt noch kommt, was ja immer als sicher angenommen wird. Sinn macht es mMn nicht , außer Nvidia weiß jetzt shcon wie schnell Vega 10 mit neuem Shader Compiler und den Front- und Backendverbesserungen wird. Eher wird auch Nvidia Richtung Sommer eine komplett neue Serie rausbringen.

Gipsel

2017-01-25, 13:40:30

AMD hat eine Technik integriert, die den Speicherbedarf um 50 Prozent senkt.Da würde ich erst mal abwarten, ob bzw. wie gut das überhaupt funktioniert. Das kann ein nettes Extra sein, aber verlassen würde ich mich auf sowas erstmal nicht.

=================================

@all:
Ansonsten würde ich mich auch erst mal wieder auf die Spekulationen bezüglich Vega konzentrieren und nicht irgendwas Sinnloses endlos wiederkäuen (8GB reichen nie und nimmer! Aber doch! Stimmt doch gar nicht! Außerdem gehen 16GB doch auch! Sind aber viel zu teuer! Blabla...).

=================================

Richtig. Vega 10 kann beides.
Viel interessanter finde ich den Punkt ob man bei Vega 11 auch auf HBM oder auf GDR5X setzt. An GDR5X haben AMD Mitarbeiter laut Linkedin Einträgen gearbeitet. Man wäre auch flexibler was die Bandbreite angeht. Bei HBM wäre man an 256 GB/s gebunden, außer man nutzt wie bei Vega 10 zwei Stacks. Mit GDR5X könnte man auch relativ günstig 288 oder 320GB/s liegern, was besser zur erwarteten Leistung von V11 zwischen P10 und V10 passen würde.Vega 11 könnte ein Stack mit 256GB/s reichen. Und das Salvage-Modell (oder eins der beiden) von Vega 10 kann auch kostengünstiger mit 1,6GT/s HBM2 ausgestattet werden, was 409GB/s ergibt.
Vega10 XT (2 Stacks HBM2 mit 8GB), Anfang 2018 dann eventuell Refresh mit 16GB
Vega10 Pro mit ein paar deakivierten CUs (56CUs aktiv?) und leicht geringerem Takt und nur 409GB/s Bandbreite mit preisgünstigerem 1,6GT/s HBM2
Vega 10 LE noch weniger CUs (48CUs aktiv?) aber ähnlicher Takt wie Pro mit etwas mehr Spannung (hat AMD in der Vergangenheit häufig gemacht, um die Gurken loszuwerden) und 8GB 1,6GT/s HBM2 getaktet auf nur 1,4GT/s (358GB/s).
Das sollte genug Staffelung in der Leistung geben, um die Lücke zu einem hypothetischem Vega11 mit sagen wir mal 36-40CUs und nur einem Stack mit 256GB/s zu überbrücken (so ein Vega11 sollte dann natürlich besser deutlich über Polaris 10 liegen).

Alles hypothetisch natürlich. Ich weiß nicht, was kommen wird.

Ailuros

2017-01-25, 13:51:11

@all:
Ansonsten würde ich mich auch erst mal wieder auf die Spekulationen bezüglich Vega konzentrieren und nicht irgendwas Sinnloses endlos wiederkäuen (8GB reichen nie und nimmer! Aber doch! Stimmt doch gar nicht! Außerdem gehen 16GB doch auch! Sind aber viel zu teuer! Blabla...).

Rache ist Blutwurst fuer alle im gegebenen Fall denn es wird wohl so oder so sowohl 8 und 16GB SKUs geben nur damit sich beide Seiten auch in der Zukunft darueber nerven koennen was zu viel und was zu wenig ist :freak:

Mangel76

2017-01-25, 13:57:36

Was ich meinte ist sowas hier:

http://www.golem.de/news/far-cry-primal-die-ultra-hd-texturen-lohnen-sich-selten-1604-120345.html

also deutlich höhere VRAM-Belegung bei kaum sichtbaren Vorteilen.

Außerdem war mein Ausgangspunkt ja gerade, dass wir heute noch gar nicht abschätzen können, wie a) sich die Anforderungen in den nächsten Jahren entwickeln werden (obwohl es aus der Vergangenheit einige Anhaltspunkte gibt) und b) welchen Effekt der HBCC bei VEGA auf den tatsächlichen VRAM-Bedarf hat und c) wie viel Speicher VEGA denn überhaupt haben wird. Einige andere scheinen aber aufgrund von Annahmen und Nichtwissen VEGA direkt schon wieder als FAIL abzutun. Warten wir es doch einfach mal ab.

Ailuros

2017-01-25, 14:33:02

AA/AF relatives OT wurde gerechtfertigt ausgeschlachtet in einen anderen thread. Wie waere es mit einer weiteren Ausschlachtung vom Speicher-Quark-OT damit der jugendliche Pinkel-Wettbewerb dort weitergefuehrt werden kann?

Gipsel

2017-01-25, 23:50:22

In diesem Sinne:
Für die eventuell fortzuführende Diskussion der historischen Entwicklung des VRAM-Bedarfs oder ob im Jahr 2017/2018 entsprechend 8/12/16GB/whatever noch ausreichend/zukunftssicher wären, bitte ich einen neuen Thread zu eröffnen. Hier ist das OT.
Wenn Bedarf an dieser Diskussion besteht (was ich daran festmache, ob ein neuer Thread dazu erstellt wird), werde ich die entsprechenden Posts auch dahin verschieben.

Link zur Diskussion über den VRAM-Bedarf (https://www.forum-3dcenter.org/vbulletin/showthread.php?t=578842)

Rabiata

2017-01-29, 15:14:31

Der_Korken

2017-01-29, 15:21:55

davidzo

2017-01-29, 15:29:41

Gipsel

2017-01-29, 15:31:36

256GB/s scheint mir etwas mager. Das hat schon die RX480, und laut diversen Aussagen hier und anderswo ist sie schon eher vom Speicherdurchsatz als von der Rechenleistung begrenzt.

Vega 11 wird vermutlich bei den Shader-Einheiten kräftig zulegen gegenüber der RX480, und passend dazu auch mehr Speicherdurchsatz brauchen. Zwei Stacks mit preisgünstigerem 1,6GT/s HBM2 erscheinen da gerade recht.Die 1070 hat auch nur 256GB/s und die ist wieviel schneller als die 480?
Vega bringt mit dem Tiling Rasterizer (zusammen mit den an den L2 angebundenen ROPs) eine Technik, die deutlich Bandbreite sparen kann (ist ja auch der Grund, warum nV mit weniger Bandbreite als AMD auskommt, nicht weil die DCC soviel besser wäre oder so ;)). Dort sind also deutliche Steigerungen gegenüber der 480 bei gleicher Bandbreite drin. Damit könnte man sich also zwischen die 480 (umgelabelt als 570?) und der größeren Vega10 setzen. Dessen Salvage-Modell (mit 56 CUs?) könnte aber gut mit 2 Stacks 1,6GT/s HBM (409GB/s) kommen (oder es gibt insgesamt 2 Salvage Modelle, 56CUs mit lediglich geringerem Kerntakt und 2GT/s sowie eine LE mit 48CUs und 1,6GT/s HBM, um den Bereich eng abzudecken).
Und für so eine Positionierung zwischen Polaris 10 und Vega 10 sind auch gar nicht soviel mehr Shadereinheiten als bei Polaris10 nötig (40, maximal 44CUs?), der Takt wird ja vermutlich merklich höher ausfallen als bei Polaris 10.
Das setzt natürlich voraus, daß AMD Vertrauen in die Verfügbarkeit von 8GB-Stacks hat. Aber mal sehen.

Nightspider

2017-01-31, 01:35:37

Waren die ACEs von Vega eigentlich schon mal ein (ausführlicheres) Thema hier?

Gab es Infos (hinter vorgehaltener Hand) ob diese stark aufgebohrt/verbessert/schneller geworden sind oder ob NCUs vllt noch stärker von diesen profitieren? Irgendwas in der Richtung?

iuno

2017-01-31, 02:51:25

Was soll man deiner Meinung nach machen? Da hat man eh Vorsprung, dann seit Fiji noch nachgelegt und ist all die Jahre nach Einfuehrung softwareseitig immer noch nicht in der Naehe, das Potenzial zu nutzen.
Ich denke, dass man sich da auf andere Baustellen fokussiert hat.

HOT

2017-01-31, 18:11:13

http://www.pcgameshardware.de/Vega-Codename-265481/News/HBM2-Verfuegbarkeit-SK-Hynix-Samsung-1219605/

Mal sehen, ob das V10 nochmal verschiebt, weil der 2GHz-Speicher so schlecht verfügbar ist. Aber da steht echt ne Menge BS drin. Die Instinct MI25 ist meiner Ansicht nach einfach eine DualChip-Karte, sonst wären die 16GB einfach nicht drin. Außerdem muss man die, wenn man die schon MI25 nennt auch 2x 12,5TFLOPs FP32-Leistung liefern, denn die kleineren Karten liefern das ja auch und das wird auch so sein. Das Ding besteht im Grunde aus 2 V10 "Nanos" mit je 2x 4GB 4er-Stacks (1,6 oder 2GHz mit Zendenz zum ersteren). Die Theorie, dass das nur ein Chip ist ist derart unwahrscheinlich aus dieser Sicht, da die 8er-HiStacks glaub ich nie geplant waren für V10 und schon früh klar war, dass das nicht so schnell was wird - es gibt jedenfalls keinerelei Indizien und das man sich glaube ich nicht die Blöße geben würde, ein Produkt MI25 zu nennen, wenn dieses Produkt nur 12,5TFLOPs überhaupt liefern kann. Zudem baut man nicht nur für die Instinct nen eigenen Interposer mit 4 Stacks, auch das ist vollkommender Quatsch meiner Ansicht nach. Man müsste das mal generell überdenken, was das für eine Produkt sein soll. Ich glaub, da V10 die consumer-Variante von Vega ist (V20 ist die Profivariante) sind auch nicht mehr als 2 Stacks überhaupt vorgesehen.

Also: MI25 besteht sehr wahrscheinlich aus 2 1,55GHz getakteten V10-Modulen mit je 2x 4GB 1,6GHz 4er HiStacks, die über CCIX miteinander verbunden sind (volle Kohärenz). Das würde auch die Länge der Karte erklären. Wie gesagt, die 16GB-Bestückung macht die 2x V10-Bestückung dann eigentlich unumgänglich für meine Begriffe. Einzige Alternative wäre ein V10 mit 4 Stacks und eigenem Interposer. Ich halte davon aber gar nichts, weil ich denke, dass das gar nicht geht, weil es nie vorgesehen war.

Pirx

2017-01-31, 18:20:05

glaubst du nie geplant waren? Ist ja nicht sehr überzeugend.

Gipsel

2017-01-31, 18:24:37

http://www.pcgameshardware.de/Vega-Codename-265481/News/HBM2-Verfuegbarkeit-SK-Hynix-Samsung-1219605/

Mal sehen, ob das V10 nochmal verschiebt, weil der 2GHz-Speicher so schlecht verfügbar ist. Aber da steht echt ne Menge BS drin. Die Instinct MI25 ist meiner Ansicht nach einfach eine DualChip-Karte, sonst wären die 16GB einfach nicht drin. Außerdem muss man die, wenn man die schon MI25 nennt auch 2x 12,5TFLOPs FP32-Leistung liefern, denn die kleineren Karten liefern das ja auch und das wird auch so sein. Das Ding besteht im Grunde aus 2 V10 "Nanos" mit je 2x 4GB 4er-Stacks (1,6 oder 2GHz mit Zendenz zum ersteren). Die Theorie, dass das nur ein Chip ist ist derart unwahrscheinlich aus dieser Sicht, da die 8er-HiStacks glaub ich nie geplant waren für V10 und schon früh klar war, dass das nicht so schnell was wird - es gibt jedenfalls keinerelei Indizien und das man sich glaube ich nicht die Blöße geben würde, ein Produkt MI25 zu nennen, wenn dieses Produkt nur 12,5TFLOPs überhaupt liefern kann. Zudem baut man nicht nur für die Instinct nen eigenen Interposer mit 4 Stacks, auch das ist vollkommender Quatsch meiner Ansicht nach. Man müsste das mal generell überdenken, was das für eine Produkt sein soll. Ich glaub, da V10 die consumer-Variante von Vega ist (V20 ist die Profivariante) sind auch nicht mehr als 2 Stacks überhaupt vorgesehen.

Also: MI25 besteht sehr wahrscheinlich aus 2 1,55GHz getakteten V10-Modulen mit je 2x 4GB 1,6GHz 4er HiStacks, die über CCIX miteinander verbunden sind (volle Kohärenz). Das würde auch die Länge der Karte erklären. Wie gesagt, die 16GB-Bestückung macht die 2x V10-Bestückung dann eigentlich unumgänglich für meine Begriffe.Schau Dir mal lieber die Präsentation an, wo AMD die Chips gezeigt hat (und auch einen Würfel mit vier Vega10-Chips mit zusammen 100 TFlop/s FP16), dann schreibst Du vielleicht auch was Sinnvolleres. ;)
AMD plant bei der MI25 mit einem Vega 10 mit 12,5 TFlop/s FP32 und 25 TFlop/s FP16 und zwei 8Hi-Stacks mit jeweils 8 GB (insgesamt dann 16GB).