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

[horn 12]

Somit sind die Preise der wohl kleinsten Vega Karte unter 400 bis 450 kaum realisierbar, nehme ich mal stark an ?

[Der_Korken]

Somit sind die Preise der wohl kleinsten Vega Karte unter 400 bis 450 kaum realisierbar, nehme ich mal stark an ?

Ein voller V10 sicher nicht. Ein Salvage vielleicht schon, da bei den 20$/GB nicht genannt wird, auf welche Geschwindigkeit sich das bezieht. Wenn das der Preis für 2Gbps-HBM ist, könnte 1.6er eine Ecke günstiger sein.

[Tamagothi]

Die 20$/GB könnten sich auch auf 8Hi Staks beziehen. 4Hi sollte dann auch wieder günstiger sein.

[Leonidas]

Die 20$/GB beziehen sich zweifelsfrei (lt. Quelle) auf 4Hi-Stacks. Ohne Frequenzangabe. 8Hi dürfte noch teurer werden.

[uweskw]

Mythos;11384978']Hatten wir das schon? 8 GB HBM2 Speicher kosten 160$.
http://www.fudzilla.com/news/graphics/43731-vega-hbm-2-8gb-memory-stack-cost-160

tja, da geht die Strategie von Nvidia wieder mal wieder zu 100% auf. Bei den homöopathischen Dosen die für ihre Profikarten gebraucht werden spielt der Preis für den Speicher praktisch keine Rolle.
AMD hat nicht die Marktmacht alleine genug Stückzahlen für vernünftige Preise zu erreichen.
Doppel win für die Technologie Bremse Nvidia.

Greetz
US

[Sven77]

Sorry, das was du schreibst macht so gar keinen Sinn..

[Hübie]

Technologie-Bremse :facepalm:

HBM ist und bleibt vorerst ein Kostentreiber und wenn ich mich so umsehe sind die meisten Kunden nicht bereit mehr als 200-250 € für ne Graka auszugeben. Auch hier muss die neue Architektur ankommen und durch schlagen, sonst ist der gewonnene Boden wieder verloren. Polaris hat ja markttechnischt einen recht guten Start hingelegt.

[Korvaun]

Und das sind nur die reinen Speicherpreise, dazu kommt noch der Zusammenbau des finalen Chips (GPU/Speicher/Interposer). Das einfachere PCB fällt da wohl überhaupt nicht ins Gewicht. Eine V10-Karte wird in der kompletten Produktion locker 50$ mehr kosten als eine vergleichbare nV-Karte. Preise werden daher keinesfalls "Schnäppchen" werden.

[Skysnake]

Man darf aber auch nicht vergessen das HBM auch kosten einspart! einfaches Board-Stromversorgung- Einfache kühler....

Und was vielleicht sogar noch besser ist das AMD am RAM jetzt mit verdient da sie CPU+HBM zusammen verkaufen.
Nvidia und such AMD verkaufen schon lange ihre GPUs als bundle Migration dem Speicher

[HOT]

Wir hatten uns mal über Preise unterhalten:
Jeweils auf 1 GB bezogen:

GDDR5 fängt bei ~6$ an und steigt auf knappe 10 (8 Gbps)
GDDR5X sehr wahrscheinlich so um die 12$ mit Tendenz darunter zu liegen
HBM2 ca. 18$ wobei AMD hier sicher mehr zahlen darf weil NV mehr herum heult ;D


Na ja nun hat man eine klarere Marschrichtung. Das es teuer ist war wohl schon jedem klar. Danke fürs Teilen. :up:

Ohne Quelle glaube ich nicht eine Sekunde, dass GDDR5X so günstig ist. Auch GDDR6 wird erheblich teurer sein. Eher so 15-17$ schätz ich.

[Mancko]

Man darf aber auch nicht vergessen das HBM auch kosten einspart! einfaches Board-Stromversorgung- Einfache kühler....

Und was vielleicht sogar noch besser ist das AMD am RAM jetzt mit verdient da sie CPU+HBM zusammen verkaufen.

Das letztere ist kein Argument. Das können sie heute schon mit normalen GDDR Ram. Nvidia macht das seit Jahren. GPUs gibt es dort im Paket in der Regel mit RAM. AMD macht es m.E. auch.

[Mancko]

tja, da geht die Strategie von Nvidia wieder mal wieder zu 100% auf. Bei den homöopathischen Dosen die für ihre Profikarten gebraucht werden spielt der Preis für den Speicher praktisch keine Rolle.


Der spielt auch bei den PReisen die da abgerufen werden keine Rolle. Bei 10.000 Dollar oder jetzt 7.000 Dollar pro Karte ist es egal ob der Speicher 50$, 100$ oder 200$ kostet. Geht natürlich gern auch immer günstiger aber die Margen sind dort so hoch, dass dies nicht wirklich ins Gewicht fällt. Da wird einfach der Preis des Produktes angepasst und gut ist.


AMD hat nicht die Marktmacht alleine genug Stückzahlen für vernünftige Preise zu erreichen.
Doppel win für die Technologie Bremse Nvidia.
Greetz
US

Das hat nichts mit Marktmacht zu tun und mit Technologiebremse schon gleich gar nicht. Das ist einfach pragmatisch und sinnvoll und AMD hat sich hier selbstverschuldet in eine Ecke mit hohem Risiko begeben. Das was Nvidia gemacht hat finde ich einfach pragmatisch richtig.

Nehmen wir mal an Nvidia wäre auch volle Granate auf den HBM2 Zug gegangen. Hätten wir dann heute eine umfassende Lieferbarkeit von diesem? Nein mit Sicherheit nicht. Die Technologie ist nach wie vor extrem neu und offensichtlich nicht ganz so simpel wie manche das gern hätten. Dann wäre auf Grund der schlechten Lieferbarkeit und der hohen Preise weder eine 1080 noch eine 1070 noch eine 1080Ti noch eine Titan auf Pascal Basis in den Markt gekommen. Die Titan vielleicht noch am ehesten aber der Rest auf gar keinen Fall. Ich finde es schon recht amüsant dass du dann von einer Technologiebremse sprichst. Aus Sicht des Consumer Marktes und der Kunden ist das eher AMD weil sie aufs falsche PFerd gesetzt haben und somit nichts adäquates liefern konnten und zwar für über 1 Jahr!

Zusätzlich dazu kann sich jeder ja mal ausmalen was passiert wäre, wenn Nvidia auch noch HBM bzw. HBM2 in großen Mengen hätte haben wollen. Die PReise dafür wären noch höher und die Verfügbarkeit noch geringer. Mit der größeren Marktmacht hätten die auch schön die Verfügbarkeit für AMD negativ beeinflusst. Am Ende ist da sich jeder selbst der nächste und Nvidia kann einfach mehr zahlen. Insofern bin ich überhaupt nicht überzeugt davon, dass dieses Szenario besser gewesen wäre. Da war die Entscheidung von Nvidia pragmatisch und für den Endkunden am Ende auch besser.

[tm0975]

HBM ist und bleibt vorerst ein Kostentreiber und wenn ich mich so umsehe sind die meisten Kunden nicht bereit mehr als 200-250 € für ne Graka auszugeben.

schau dir die verkaufszahlen der 1070 und 1080 an. es sind zumindest in den industrienationen sehr viele bereit, 400 bis 500 €/$ für eine grafikkarte auszugeben.

[Complicated]

Alsoo das mit dem Speicher ist wohl nicht so richtig angekommen. GDDR5 hat 2009 auf der AMD 4890 39.90$/GB gekostet. Das ist Doppelt soviel wie die 80/4GB. Klar es wurde auch nur 1 GB verbaut. Doch das macht den GB Speicher denoch nur halb so teuer wie GDDR bei Markteinführung.

[Cyphermaster]

HBM ist und bleibt vorerst ein KostentreiberDas ist ja der Punkt: Innovation ist anfangs IMMER teuer, und kostet Marge. Wenn man Innovation aber immer nur der Konkurrenz zur eigenen Kosteneinsparung überläßt, kommt man früher oder später ins technologische Hintertreffen. Wenn AMD also nennenswert Boden auf nVidia gutmachen will, wäre es mehr als fatal, kein Risiko zugunsten neuer Technologie einzugehen. Neue Technik kann natürlich auch grandios scheitern, ist aber eine der ganz wenigen Chancen gegenüber der Konkurrenz.
Ohne Quelle glaube ich nicht eine Sekunde, dass GDDR5X so günstig ist. Auch GDDR6 wird erheblich teurer sein. Eher so 15-17$ schätz ich.Ich schließe mich an, ganz so günstig werden v.a. die hoch taktbaren Modelle nicht sein.

[r-or]

Alsoo das mit dem Speicher ist wohl nicht so richtig angekommen. GDDR5 hat 2009 auf der AMD 4890 39.90$/GB gekostet. Das ist Doppelt soviel wie die 80/4GB. Klar es wurde auch nur 1 GB verbaut. Doch das macht den GB Speicher denoch nur halb so teuer wie GDDR bei Markteinführung.
Die Rechnung ist blödsinnig, dann hätten wir keinerlei Fortschritt. Genauso könntest du sagen, 8gb ddr4 ist wie geschenkt, hat ja dasselbe gekostet wie 256mb sdram in 2001.
Aber realistisch heutzutage. P/L-technisch hat sich bei Grafikkarten in den letzten 3 Jahren im 250 Euro Segment nur sehr wenig getan...
Wird aber in Zukunft noch schlimmer. Die tief hängenden Früchte sind alle weg.

[Complicated]

Die Rechnung ist überhaupt nicht Blödsinn. Die HD 4890 hat zu Release 240,- € gekostet mit 1 GB GDDR VRAM der 40 $ gekostet hat. Jetzt zu behaupten AMD hätte Preisprobleme weil 4 GB HBM2 80 $ kosten ist Blödsinn - diese HBM2 Karten werden nicht unter 400 $ kosten und AMD verdient am RAM mit. 20% des Kaufpreises dem RAM zuschreiben und alles ist auf dem selben wirtschaftlichen Level - ausser, dass AMDs Umsatz den RAM mit beinhaltet was früher nicht der Fall war. Das verkaufte Package an den OEM-Hersteller ist automatisch mit mit 20% mehr Umsatz in den Büchern.

Was das mit Fortschritt zu tun haben soll kannst du gerne erklären.

[StefanV]

Ohne Quelle glaube ich nicht eine Sekunde, dass GDDR5X so günstig ist. Auch GDDR6 wird erheblich teurer sein. Eher so 15-17$ schätz ich.
Schau doch mal bei Digikey!
https://www.digikey.de/product-detail/de/micron-technology-inc/MT51J256M32HF-70-A-TR/MT51J256M32HF-70-A-TR-ND/6135880

2.000 13,40864 26.817,27

Ein 8Gbit Chip kostet also 13€ für uns (ev. + Steuer??), 2k musst mindestens abnehmen...
Für AMD/nV könnts also bisserl billiger sein...

[Klevapalis]

Die Rechnung ist überhaupt nicht Blödsinn. Die HD 4890 hat zu Release 240,- € gekostet mit 1 GB GDDR VRAM der 40 $ gekostet hat. Jetzt zu behaupten AMD hätte Preisprobleme weil 4 GB HBM2 80 $ kosten ist Blödsinn - diese HBM2 Karten werden nicht unter 400 $ kosten
Ist schon ein massiver Unterschied, ob der Speicher nun 40US$ oder 160US$ kostet. Wenn man das mal linear rechnet, müsste die entsprechende Vegakarte also 4*230€ = 920€ kosten, um das gleiche Verhältnis Speicherkosten/Preis zu erhalten. Außerdem war der RV770 gerade mal 280mm² groß, während Vega10 ja bekanntermaßen knapp an den 500mm² kratzt.

Da kann man schon ganz gut sehen, wo Vega preislich raus kommen wird, selbst als Salvage. Unter 500€ halte ich da für unrealistisch. Außer AMD will sich einen richtigen Preiskampf liefern wie damals mit der HD4890 - aber im Q2/09 (Release HD4890) hatten sie nicht ohne Grund 330 Millionen Verlust bei 1,1 Milliarden Umsatz....

[Complicated]

Das bedeutet 8Gbit=1GB=>13 $
mal 4 => 4GB/52 $
HBM2 = 4GB/80 $
Das ist nicht mal 50% billiger als HBM2 - da wird GDDR5X noch irgendwo dazwischen liegen.

Ist schon ein massiver Unterschied, ob der Speicher nun 40US$ oder 160US$ kostet. Wenn man das mal linear rechnet, müsste die entsprechende Vegakarte also 4*230€ = 920€ kosten, um das gleiche Verhältnis Speicherkosten/Preis zu erhalten. Außerdem war der RV770 gerade mal 280mm² groß, während Vega10 ja bekanntermaßen knapp an den 500mm² kratzt.
Vielleicht rechnest du das ganz nochmal mit den richtigen Zahlen. 1GB GDDR5 hat 2009 40 $ gekostet. 4 GB HBM2 kosten 80 $, sprich 20$/GB. Das ist halb so teuer wie der GDDR5 damals.
Nur weil mehr RAM verbaut wird wird der Rest der Karte ja nicht teurer - im Gegenteil HBM reduziert die Größe des Dies und die Komplexität des PCB deutlich und macht dies alles drumherum billiger. Warum sollte man jetzt das vierfache veranschlagen wenn man den Speicher erhöht? Passiert weder bei den 4->8GB Versionen der RX 580 (es sind vielleicht 20-30 $ Unterschied) noch bei Nvidia in irgendeiner Form bei der GTX 1060 3/6 GB

[Klevapalis]

Vielleicht rechnest du das ganz nochmal mit den richtigen Zahlen. 1GB GDDR5 hat 2009 40 $ gekostet. 4 GB HBM2 kosten 80 $, sprich 20$/GB. Das ist halb so teuer wie der GDDR5 damals.
Ja, PRO GB halb so teuer. Nur leider wird die 8-fache Menge verbaut. Ergo 4x so teuer :rolleyes:

Du und deine völlig blödsinnigen Milchmädchenrechnungen.

Und da ist noch nicht die deutlich kompliziertere Herstellung des Chips mit kalkuliert!

Nur weil mehr RAM verbaut wird wird der Rest der Karte ja nicht teurer - im Gegenteil HBM reduziert die Größe des Dies und die Komplexität des PCB deutlich und macht dies alles drumherum billiger.
Inwiefern ist denn bitte der Vega10 Chip mit 500mm² billiger, als der von dir genannte RV790 Chip mit 280mm²? Ich wage eher zu behaupten, der Chip ist deutlich teurer.

Der Preisunterschied bei unterschiedlichen Speicherbestückungen ist übrigens deutlich geringer, weil man geheimhin die identische Anzahl Chips, aber unterschiedliche Kapazitäten verbaut. 3GB bei einer GTX1060 oder 4GB bei einer RX580 werden mitnichten nur die Hälfte von den normalerweise verbauten 6 oder 8GB kosten.

[Der_Korken]

Die Gesamtbestückung des Speichers von V10 ist 4x so teuer wie die vom RV770, dafür wird ersterer aber auch mindestens doppelt so teuer. Das relativiert den Unterschied etwas, auch wenn der Kostenanteil des VRAM vermutlich spürbar steigt.

Und natürlich wird V10 nicht billiger als RV770. Das ergibt allein schon wegen der Die-Größe, spätestens aber wegen des teureren Fertigungsprozesses keinen Sinn. Ich denke was Complicated meinte war, dass HBM indirekt Kosten einspart, weil die PHYs auf dem Die kleiner werden (ergo der Die kleiner wird, als wenn er ein GDDR-Interface mit gleicher Bandbreite hätte) und sehr viel Verdrahtung auf dem PCB eingespart wird.

[Complicated]

Inwiefern ist denn bitte der Vega10 Chip mit 500mm² billiger, als der von dir genannte RV790 Chip mit 280mm²? Ich wage eher zu behaupten, der Chip ist deutlich teurer.
Wer schrieb etwas vom Chip? Du weisst was ein PCB ist?

Zumal der Chip billiger wird verglichen mit GDDR5 Speicher und nicht verglichen mit einem 8 Jahre alten Chip - den Vergleich habe ich zu keinem Zeitpunkt gezogen. HBM nutzt ein deutlich kleineres SI (PHY) und spart Fläche.

Kostet eine GTX 1060 6GB doppelt so viel wie eine mit 3 GB?
Kostet eine RX 480 4GB doppelt so viel wie eine RX 480 8GB?

Wer hier Milch mit Mädchen zusammen rechnet ist ja offensichtlich.

[Kriton]

Wie genau sah eigentlich die Zusammenarbeit zwischen AMD und Hynix aus? Welche Vorteile hat AMD daraus gehabt?

Wo ist Ailuros wenn man ihn braucht?

[BlacKi]

Vielleicht rechnest du das ganz nochmal mit den richtigen Zahlen. 1GB GDDR5 hat 2009 40 $ gekostet. 4 GB HBM2 kosten 80 $, sprich 20$/GB. Das ist halb so teuer wie der GDDR5 damals.
quatsch das zu vergleichen...

was aber für hbm2, ggü. Gddr5, zumindest auf dem papier spricht ist, das die kosten zwar ca 50% steigen, aber die bandbreite der FE auch um 71% steigt. zusätzlich sinkt der stromverbrauch und die chipfläche ist geringer.

ich weiß nicht wie man gegen hbm2 sein kann. wenn die verfügbarkeit da ist, dann wird die technik auch bei anderen chips angewendet(mal Gddr6 ausgeklammert).

[Complicated]

quatsch das zu vergleichen...
Das ist nicht mein Vergleich, es ist der von Leonidas:
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-24-mai-2017
Und auch in diesem Fall ist die HBM2-Preislage natürlich ein Schocker für AMD: Auf einer Vega 10 Gaming-Lösung mit 8 GB gehen dann gleich 200 Dollar/Euro für den Speicherausbau weg – GDDR-Speicher kostet üblicherweise einen Bruchteil hiervon (https://www.3dcenter.org/artikel/herstellungspreise-aktueller-grafikkarten). Wirklich günstige Grafikkarten sind mit diesen HBM2-Preisen jedenfalls nicht machbar – was man ja auch schon bei den Fiji-basierten Grafikkarten gesehen hat, jene weigerten sich beharrlich, unter die 400-Euro-Marke zu fallen.
Und das ist eben Blödsinn. Denn auch GDDR5 wird 8 mal soviel verbaut wie es eben auch bei HBM der Fall ist. Nur kostet heute 1 GB HBM2 die Hälfte von dem was damals 1 GB GDDR5 zur Markteinführung gekostet hat. Das geht aus dem Link hervor den Leonidas selber in dem Zitat hinterlegt hat.

Damals hat die HD 4890 eben 240 € gekostet. Eine HBM2 basierende Vega mit 8 GB wird sicherlich deutlich über 480,- € kosten. Würde sie GDDR5 Speicher nutzen wäre das auch nicht um so vieles billiger - 1 GB kostet 13 $ wie wir hier im Thread festgestellt haben, was bei 4 GB auch auf 52 $ kommt - verglichen mit 4 GB HBM2 für 80 $. Jetzt spart man Chipfläche durch HBM und man spart Kosten für die Anbindung der GDDR5 chips auf dem GPU-PCB. Das sollte mehr als nur einen Ausgleich schaffen für den höheren Preis von HBM2. Diesen Ausgleich haben GDDR5X-Speicher nicht. Sie sind immer noch teurer als GDDR5 und senken die Kosten weder auf dem Chip noch auf dem PCB.

[dargo]

Diesen Ausgleich haben GDD5X-Speicher nicht. Sie sind immer noch teurer als GDDR5 und senken die Kosten weder auf dem Chip noch auf dem PCB.
Das ist nicht ganz richtig. Durch GDDR5x werden die Kosten auf dem Chip durchaus reduziert da man für die gleiche Bandbreite ein schmaleres SI benötigt. Ob das schmalere SI die Mehrkosten für den GDDR5x wieder aufwiegen steht auf einem anderen Blatt.

[Complicated]

Der GP104 nutzt für GDDR5 das selbe SI wie für GDDR5X - GTX1070+GTX1080
Wie kommst du auf ein schmaleres SI für GDDR5X?

http://cdn.wccftech.com/wp-content/uploads/2016/09/Nvidia-GP104-GPU-Die-WCCFtech-watermarked.jpg

Das GDDR5X Segment bedient 32-bit. Zwei davon sind so groß wie ein 1024-bit Segment bei HBM.

[dargo]

Lese nochmal was ich geschrieben habe. Falls es zu undeutlich ist.

GTX 1080 @256Bit SI = 320GB/s
GTX 1070 @256Bit SI = 256GB/s

Der Unterschied fällt aktuell natürlich nicht so gravierend aus da der volle GP104 nur 10Gbps Chips verwendet. Mit 12-14Gbps fällt es natürlich noch stärker ins Gewicht.

PS: die GTX1070 hätte @192Bit SI und 11Gbps GDDR5x bereits 264GB/s Bandbreite.

[Complicated]

Und wie reduziert das nun die Kosten des Chips wenn die selbe Fläche benötigt wird?
Erkläre das bitte? Wieso soll das SI schmaler sein wenn niedriger oder höher getaktet wird?

[dargo]

Meine Güte... denk doch mal nach. Dann nimm halt den vollen GP106 und projeziere diesen auf GDDR5x. Du würdest mit 96-128Bit SI auskommen.

[Der_Korken]

Und wie reduziert das nun die Kosten des Chips wenn die selbe Fläche benötigt wird?
Erkläre das bitte?

Wenn ich 8Gbps@384bit statt und 12Gbps@256bit verbauen müsste vergleiche, habe ich bei letzterem indirekt Fläche durch GDDR5X/6 eingespart, ohne Bandbreite zu verlieren.

[Complicated]

Nur benutzen beide GPUs doch den selben Die und das selbe SI - es sind 256 bit. Damit hat GDDR5X in bisherigen Produkten nicht einen mm² Platz eingespart.

Darüber nachzudenken macht doch nun wirklich keinen Sinn. Die kleineren GPUs wie die GTX 1060 nutzen gar kein GDDR5X, was dann eben nicht zum tragen kommt.

Edit:
Wäre jetzt der GP102 mit 256-bit SI erschienen hätte ich dem ja zugestimmt. Doch auch dort wurde 352-Bit SI (384-bit auf dem Chip) genutzt trotz GDDR5X.
Sicherlich erhält man mehr Bandbreite, doch nicht ausreichend um wirklich ein kleineres SI nutzen zu können.

Meine Güte... denk doch mal nach. Dann nimm halt den vollen GP106 und projeziere diesen auf GDDR5x. Du würdest mit 96-128Bit SI auskommen.
Und was du hierbei auch vergisst, ist dass du dann auch die Menge des Speichers reduzieren musst. Willst du gleich viel Speicher anbinden musst du das selbe SI auf den Chip bringen für GDDR5 und GDDR5X.

[OgrEGT]

Echt jetzt... hbm2 wird sicherlich zum Start teurer sein pro Gb als bereits etablierte Technologien... da muss man eigentlich nicht seitenweise darum streiten... am Ende werden die Vega Karten kosten was sich am Markt verkaufen lässt... da AMD Marktanteile benötigt möglicherweise etwas günstiger als vglbare NV Pendants...
Off topic on
Ist eigentlich schon mal jemand aufgefallen wie hoch das Interesse an AMD Produkten sein muss gemessen an der jeweiligen Threadgröße hier... in den NV und Intel Threads herrscht eigentlich im Vergleich tote Hose...
Off Topic off

[Menace]

Off topic on
Ist eigentlich schon mal jemand aufgefallen wie hoch das Interesse an AMD Produkten sein muss gemessen an der jeweiligen Threadgröße hier... in den NV und Intel Threads herrscht eigentlich im Vergleich tote Hose...
Off Topic off

Off topic continue
Was aber auch daran liegen könnte, dass in AMD-Threads bestimmte Leute immer wieder provozieren. :wink:

[vinacis_vivids]

Hm, wenn ich mir so recht überlege, braucht Vega vier unterschiedliche Varianten, um Pascal das ganze Wasser abzugraben.

Vega SE, 8/16GB, 4096SP, 1600Mhz ~ 13,1 TFlops >= Titan Xp
Vega X, 8GB, 4096SP, 1500Mhz ~ 12,3 TFlops >= 1080ti
Vega Nano, 4/8GB, 4096SP, 1400Mhz ~ 11,4 TFlops >= 1080
Vega, 4GB, 3584SP, 1500Mhz ~ 10,7 TFlops >= 1070

[Mancko]

Jetzt spart man Chipfläche durch HBM und man spart Kosten für die Anbindung der GDDR5 chips auf dem GPU-PCB. Das sollte mehr als nur einen Ausgleich schaffen für den höheren Preis von HBM2. Diesen Ausgleich haben GDDR5X-Speicher nicht. Sie sind immer noch teurer als GDDR5 und senken die Kosten weder auf dem Chip noch auf dem PCB.

Die PCB Kostenersparnis halte ich ehrlich gesagt eher für ein Ammenmärchen. OK das PCB wird billiger. Der Interposer wird aber nicht billig sein und PCBs mit klassischem Speicherinterface sind einfach Massenware. Jede Variante 64 Bit, 128 Bit, 256, Bit... bis hin zu 512 Bit mit unterschiedlicher Anzahl an PCB Layern wurden schon über die Jahre mehrfach von verschiedensten Herstellern verbaut. Manche mehr und andere weniger. Aber alleine von dem was da schon über die Jahre an Stückzahlen im Markt abgesetzt wurde dürfte hier die Kosten eher überschaubar halten weil die Produktionslinien und grundsätzliche Design Elemente schon zich fach in den letzten Jahren in verschiedensten Varianten verbaut wurden und der Industrialisierungsgrad hier erheblich höher sein wird. Bei HBM(2) ist das halt nicht der Fall.

Insofern würde ich hier von einem klaren Kostennachteil ausgehen. Wenn es den nicht gäbe und das alles auch so toll verfügbar ist, dann wäre Nvidia ebenfalls auf diese Technologie im Consumer Markt gegangen, denn sie nutzen HBM2 bereits seit 1 Jahr. Da ich Nvidia grundsätzlich was wirtschaftliche Belange angeht für das deutlich besser und auch gnadenloser geführte Unternehmen im Vergleich zu AMD halte, gehe ich davon aus dass die Kosten nicht ganz so vernachlässigbar sind. Niemand liebt gute Marge so sehr wie Nvidia und der CEO. In anderen Bereichen Intel und Apple natürlich. Das reicht mir schon als Indikator. Da muss ich jetzt nicht ewig darüber sinnieren oder fabulieren. Dazu brauche ich auch nicht den verlinkten Artikel.

[G3cko]

Vollkommen egal was HBM kostet. Für AMD ist es eine Schlüsseltechnologie für die nächsten Jahre. Deshalb war Fiji auch ein doppelter Tonga mit entsprechenden Problemen, aber eben der Startschuss für HBM.

Vega wird das erste sinnvolle oder besser gesagt im gesamten stimmige Produkt. Man hat schon angekündigt, dass die Margen klein ausfallen auf dem FAD. Hier geht es also auch um Marktanteile und vor allem um's Image.

Genauso wie Ryzen seinen Start im 200-1000€ Bereich hat so wird auch Vega mit Freesync2 hauptsächlich Enthusiasten ansprechen.

Mit Navi sehen wird dann Produkte die HBM vor allem wirtschaftlich ins Volk bringen. Und wenn das bei den GPUs Standard ist gibt anschließend HBM auch bei den CPUs.

Kann mir jemand folgende Fragen beantworten:
Wird Vega bereits Shader Model 6.0 unterstützen?
Wie sieht es mit PCIe 4.0 aus?
Displayport 1.4?

[OgrEGT]

Off topic continue
Was aber auch daran liegen könnte, dass in AMD-Threads bestimmte Leute immer wieder provozieren. :wink:




Vielleicht will bereits ein Teil ganz tief im inneren mal was neues ausprobieren... mal sehen wie es ausschaut wenn Vega die 1080ti abhängt wer dann wirklich widerstehen kann :D

[Complicated]

@OgrEGT
Das liegt daran, dass AMD interessierte User in Intel und Nvidia Threads keinen FUD verbreiten wie es hier augenscheinlich Nvidia-Jünger für nötig halten. Daran sieht man wo der Trollanteil größer ist. Warum sollten die Jungs dort was schreiben wenn sie es hier permanent als Offtopic unterbringen?

[Complicated]

Die PCB Kostenersparnis halte ich ehrlich gesagt eher für ein Ammenmärchen. OK das PCB wird billiger. Der Interposer wird aber nicht billig sein und PCBs mit klassischem Speicherinterface sind einfach Massenware. Jede Variante 64 Bit, 128 Bit, 256, Bit... bis hin zu 512 Bit mit unterschiedlicher Anzahl an PCB Layern wurden schon über die Jahre mehrfach von verschiedensten Herstellern verbaut. Manche mehr und andere weniger.
Jedes PCB wird vom jeweiligen Hersteller selber designed - da gibt es keine Massenware mit xy-Layern als Standard für alle. Sonst wären Custom-GPUs ja nicht sinnvoll, da das Custom PCB genau den Unterschied ausmacht.

Und natürlich ist es ein immenser Kosten Unterschied ob ich 8 Speicherbausteine auf dem PCB unterbringen muss inkl. elektrische Verdrahtung oder überhaupt keinen Speicher verbauen muss als Hersteller weil der schon auf dem GPU-Package sitzt - da entfällt ein kompletter Fertigungsvorgang!

Interposer kosten 1$/100mm² - bei Fiji waren dass dann ca. 10-15$ Mehrkosten. Das Assembling bringt zusätzliche Kosten, durch eine Yield von 98% (2% Mehrkosten)

[BlacKi]

Darüber nachzudenken macht doch nun wirklich keinen Sinn. Die kleineren GPUs wie die GTX 1060 nutzen gar kein GDDR5X, was dann eben nicht zum tragen kommt.

Edit:
Wäre jetzt der GP102 mit 256-bit SI erschienen hätte ich dem ja zugestimmt. Doch auch dort wurde 352-Bit SI (384-bit auf dem Chip) genutzt trotz GDDR5X.
Sicherlich erhält man mehr Bandbreite, doch nicht ausreichend um wirklich ein kleineres SI nutzen zu können.


Und was du hierbei auch vergisst, ist dass du dann auch die Menge des Speichers reduzieren musst. Willst du gleich viel Speicher anbinden musst du das selbe SI auf den Chip bringen für GDDR5 und GDDR5X.
mag sein das man bei dem neuen chip zwar nicht das SI verkleinert, aber man spart das vergrößern des SI. der effekt ist derselbe, nur die ausgangslage eine andere. man erspart sich hierbei das vergrößern des SI der nächsten generation, und den kostspieligen wechsel auf HBM.

[Troyan]

Er ignoriert einfach mal, dass die neue Titan-Karte 547GB/s an Bandbreite hat und dies eine Steigerung von mehr als 60% gegenüber der Maxwell-Karte darstellt.

Die GTX1080 mit 11Gb/s bietet leicht mehr Bandbreite als die GTX980TI. Mit GDDR5X ist nVidia also in der Lage das Interface um 33% zu verkleinern. Sie machen nichts anderes als AMD mit Vega und HBM2.

[uweskw]

.........Das hat nichts mit Marktmacht zu tun und mit Technologiebremse schon gleich gar nicht. Das ist einfach pragmatisch und sinnvoll und AMD hat sich hier selbstverschuldet in eine Ecke mit hohem Risiko begeben. Das was Nvidia gemacht hat finde ich einfach pragmatisch richtig.

Nehmen wir mal an Nvidia wäre auch volle Granate auf den HBM2 Zug gegangen. Hätten wir dann heute eine umfassende Lieferbarkeit von diesem? Nein mit Sicherheit nicht.... .............



Natürlich hat das etwas mit dem potentiell möglichen Absatz zu tun.
Wenn der Hersteller befürchtet, dass mit HBM2 auch nicht deutlich mehr Absatz generiert wird als mit HBM wird er seine Investitionen in dieser Hinsicht gering halten.
Das führt zu.... GENAU !!! geringen Stückzahlen, hohen Preisen und einer flachen Anlaufkurve.
Wenn die Hersteller nicht in Innovation investiert hätten, würden wir immer noch mit DDR3 rumwursteln. DDR4 war anfangs auch deutlich teurer als DDR3. Neue Technologien haber erstmal hohe Stückkosten, über hohe Stückzahlen gehen die dann runter

greetz
US

[dargo]

Darüber nachzudenken macht doch nun wirklich keinen Sinn. Die kleineren GPUs wie die GTX 1060 nutzen gar kein GDDR5X, was dann eben nicht zum tragen kommt.

Warum denn wohl? Weil man die Mehrkosten für GDDR5x in diesem Preissegment kaum unterbringen kann. Ganz einfach. Wäre GDDR5x genauso günstig wie GDDR5 hätte auch GP107 GDDR5x.


Edit:
Wäre jetzt der GP102 mit 256-bit SI erschienen hätte ich dem ja zugestimmt. Doch auch dort wurde 352-Bit SI (384-bit auf dem Chip) genutzt trotz GDDR5X.
Sicherlich erhält man mehr Bandbreite, doch nicht ausreichend um wirklich ein kleineres SI nutzen zu können.

Das ist auch falsch. Bei GDDR5x limitiert aktuell etwas noch die Frequenz. Hynix plante bis zu 16Gbps. Bereits 15Gbps hätten GP104 mit einem 256Bit SI gereicht (480GB/s).

[Complicated]

Er ignoriert einfach mal, dass die neue Titan-Karte 547GB/s an Bandbreite hat und dies eine Steigerung von mehr als 60% gegenüber der Maxwell-Karte darstellt.
Warum sollte ich das ignorieren? Es ändert nichts daran, dass trotz höherer Bandbreite das SI genaus so groß ist wie bei GM200: 384 bit. Und es den selben Platz auf dem Die benötigt bei selber Fertigung. Ersparnis auf dem Chip = 0 mm²

Nimmst du HBM ist die Ersparnis auf dem Chip direkt vorhanden. Bei Fiji waren es ca. 50 mm² was etwas 10 % des Chips entspricht.
Warum denn wohl? Weil man die Mehrkosten für GDDR5x in diesem Preissegment kaum unterbringen kann. Ganz einfach. Wäre GDDR5x genauso günstig wie GDDR5 hätte auch GP107 GDDR5x.
Und das gilt für HBM etwa nicht mit deutlich mehr Platzersparnis und niedrigerem Stromverbrauch? Man spart keinen Platz indem man kleinen Chips unnötig mehr Stromverbrauch verpasst durch höher taktende Speicher die dann ein kleineres SI benötigen - hier passt GDDR5X einfach nicht rein in das Design. Man muss da schon alle Eckdaten der Technik berücksichtigen. GDDR5X hat noch keinen mm² Platz auf dem Die gespart.

Ich nehme gerne eine Quelle die mich widerlegt und keine unausgegorene Phantasie ist, wie es denn vielleicht sein könnte wenn wir die Physik vor der Tür stehen lassen.

[dargo]

Und das gilt für HBM etwa nicht mit deutlich mehr Platzersparnis und niedrigerem Stromverbrauch?
Nvidia hat natürlich ähnliche Kostenprobleme im Performancesegment und drunter mit GDDR5x wie AMD mit HBM. Das liegt doch auf der Hand. Erst ein Massenprodukt lohnt sich in den unteren Segmenten.

[Troyan]

Warum sollte ich das ignorieren? Es ändert nichts daran, dass trotz höherer Bandbreite das SI genaus so groß ist wie bei GM200: 384 bit. Und es den selben Platz auf dem Die benötigt bei selber Fertigung. Ersparnis auf dem Chip = 0 mm²

Nimmst du HBM ist die Ersparnis auf dem Chip direkt vorhanden. Bei Fiji waren es ca. 50 mm² was etwas 10 % des Chips entspricht.

Du verstehst es anscheinend nicht: Statt mehr GDDR Speichercontroller und L2-Cache verbauen zu müssen, kann man nun die selbe Bandbreite der Vorgängergeneration mit 33% weniger Aufwand erreichen. Das spart Platz.

Die Ersparnis des HBM Controllers spielt kaum eine Rolle, da die Flexibilität mit HBM flöten geht.

[Complicated]

Der Unterschied bei der Platzersparnis, die nach wie vor keine GPU hatte bei Nvidia, ist ja um eine Größenordnung verschieden. 2048-Bit HBM SI nehmen den Platz von 128-bit GDDR5X ein auf dem Chip.

Flexibilität des HBM Controllers geht flöten wodurch? Du redest wirres Zeug.

[BlacKi]

Flexibilität des HBM Controllers geht flöten wodurch? Du redest wirres Zeug.
mit einem stack kommt man eben nicht weit, da sind max 4gb drinn derzeit und in naher zukunft. das ist zwar ausreichend für eine 150€ karte, aber wenn dann der speicher 80€ kostet, ähh XD deswegen wirds wohl die nächsten 2-3 jahre keinen hbm im unteren bereich geben. nicht mal im bereich bis zu 250€, da fehlt die flexibilität.

Edit: natürlich gehen 8gb pro stack, war quatsch von mir.

[dargo]

mit einem stack kommt man eben nicht weit, da sind max 4gb drinn derzeit und in naher zukunft.
Wie schafft AMD dann bei V10 16GB?

deswegen wirds wohl die nächsten 2-3 jahre keinen hbm im unteren bereich geben. nicht mal im bereich bis zu 250€, da fehlt die flexibilität.
Diese Flexibilität fehlt bei GDDR5x und sicherlich auch beim kommenden GDDR6 ebenso. Zumindest für deinen genannten Zeitraum.

[Peicy]

Das HBM2 erst mal teurer ist als GDDR5/X, ist klar und zu erwarten.

Ich sehe das Problem darin, dass der Konsument aktuell nichts von HBM2 hat und in Kombination mit dem höheren Preis und dem entsprechend entweder a.) höheren Marktpreis für Consumer-Vega oder b.) geringerem Gewinn für AMD schauts nicht so geil aus.

Letztendlich denke ich aber nicht, dass HBM in Sachen Vega make or break bedeutet. Da sind andere Faktoren wesentlich wichtiger, denn es gibt genug Nutzer, die bereit sind für mehr Performance mehr Geld auf dem Tisch zu legen. Nur in Sachen Performance...eehhhhhhh ich weiß nicht. Alle Demos waren bisher ernüchternd.
Klar ist es möglich, dass AMD absichtlich das beste für den Schluss aufhebt und die große Consumer-Vega Nvidias Flagschiffe deutlich schlagen kann (das wäre toll). Andererseits hat man bei Zen gesehen, dass AMD durchaus bereit ist ein gutes Produkt schon im voraus entsprechend zu bewerden, siehe Zen vs. 6900k usw...

Falls die Performance bei Vega allerdings "nur" im Bereich der 1070/1080/1080ti je nach Modell liegt, sieht das in Kombination mit dem höheren Preis von HBM2 nicht gut aus was die Möglichkeiten in Sachen Preis und Platzierung (darauß resultierend Gewinn aus einer Karte) angeht. Spannend wird es auf jedenfall :biggrin:

[Hübie]

Ohne Quelle glaube ich nicht eine Sekunde, dass GDDR5X so günstig ist. Auch GDDR6 wird erheblich teurer sein. Eher so 15-17$ schätz ich.

Glauben kannst du in der Kirche. Digikey ruft Preise für Mengen auf, die ein Bruchteil der abgenommenen Mengen bei AMD / NV entsprechen. 8 Gbps liegen bei 9$. GDDR5X etwas darüber aber unter 15, meiner Einschätzung nach - da bin ich mir irgendwie sicher. Quellen wirst du lange suchen können. ;)

schau dir die verkaufszahlen der 1070 und 1080 an. es sind zumindest in den industrienationen sehr viele bereit, 400 bis 500 €/$ für eine grafikkarte auszugeben.

Ich hoffe du hast in Statistik aufgepasst. :D

[gedi]

Ohne HBM auch kein HBCC. Wenn dies so funktioniert wie in der TR-Demo gezeigt, dann ist es imo ein Killerfeature und somit auch den Mehrpreis im Vgl. zu GDDR wert. Vielleicht ist es auch so, dass Vega nicht zwindend immer den längeren Balken generiert, aber min-FPS und Frametimes über jeden Zweifel erhaben sind.

[Complicated]

mit einem stack kommt man eben nicht weit, da sind max 4gb drinn derzeit und in naher zukunft. das ist zwar ausreichend für eine 150€ karte, aber wenn dann der speicher 80€ kostet, ähh XD deswegen wirds wohl die nächsten 2-3 jahre keinen hbm im unteren bereich geben. nicht mal im bereich bis zu 250€, da fehlt die flexibilität.

Edit: natürlich gehen 8gb pro stack, war quatsch von mir.
Also solche Schlussfolgerungen sind doch absurd. Zunächst einmal Flexibilität mit dem Preis zu begründen. Wenn etwas teuer ist, ist es einfach teuer und nicht unflexibel.

Dazu dann dieses Beispiel...also 4 GB HBM2 kosten derzeit 80 €. 1 GB GDDR5 kostete zur Markteinführung bei der HD 4xxx Serie 40 €. Schon in der nächsten Generation hatte die HD 5450 1 GB GDDR5 verbaut. Der Preis ist doch nicht auf alle Zeiten fest geschrieben. Heute geht die HD5450 mit 2 GB GDDR5 für besagte 40 € über den Tisch.

Alles was im Moment mit 4 GB GDDR5 gut läuft wird von der Leistungsklasse lange kein HBM benötigen. Weder muss man Chipgröße sparen dort, noch muss man hohe Bandbreiten etablieren und man muss auch keine 32 GB Speicherausbau machen. Es wird eine reine Kostenfrage sein wann es einfach günstiger sein wird HBM zu nutzen als GDDR5, falls es soweit kommt.

[Hübie]

Ohne HBM auch kein HBCC. Wenn dies so funktioniert wie in der TR-Demo gezeigt, dann ist es imo ein Killerfeature und somit auch den Mehrpreis im Vgl. zu GDDR wert. Vielleicht ist es auch so, dass Vega nicht zwindend immer den längeren Balken generiert, aber min-FPS und Frametimes über jeden Zweifel erhaben sind.

Für das Prinzip braucht es keinen HBM. Im Grunde ist HBC afair nix weiter als ein intelligentes Puffersystem mit geschicktem Preload und / oder prefetching von Daten. Das "nur" klingt allerdings nicht dem Gerecht wie es der Gewinn am Ende suggerieren mag. Das wissen wir nicht. Im Volta-"Whitepaper" gibt es eine Anspielung auf ein ähnliches Prinzip wobei ich da noch klären möchte ob es nur erweiterter Adressraum ist oder auch wirklich geschicktes Datenmanagement.

[gedi]

Ich dachte dies wäre bereits aufgrund verschiedener Ansätze generell nicht vergleichbar und somit auch nicht machbar. Auf jeden Fall gibt es bis Dato keine Grafikkarte, welche TR in 4k@Very High mit lediglich 2G Vram bei den min-FPS mit 47FPS stützt. Das Ergebnis ist imo mehr als beeindruckend, bleibt nur abzuwarten ob das Feature immer greift, oder ob es eines Profils im Treiber bedarf (was dann etwas meh wäre).

[dargo]

Für das Prinzip braucht es keinen HBM.
Bist du dir da ganz sicher? HBCC ist im Prinzip ein Cache wenn ich es richtig verstanden habe. Und hier sind besonders auch Latenzen wichtig. Kurze Signalwege = bessere Latenzen. So gesehen macht HBCC nur mit HBM Sinn. Oder bin ich komplett auf dem Holzweg?

[Troyan]

Ja, weil HBCC aus dem Systemspeicher lädt. Da spielt Latenz überhaupt keine Rolle.

[Complicated]

Na ja irgendwie sind alle LVDS Signalverarbeitungssysteme ähnlich / gleich. ;) Also dass man die untereinander koppeln kann ist irgendwie klar.
LVDS wird von Intel und AMD seit 2015 nicht mehr unterstützt. Es wird ausgemustert mit den analogen Anschlüßen VGA und DVI-I:
https://newsroom.intel.com/news-releases/leading-pc-companies-move-to-all-digital-display-technology-phasing-out-analog/

Mit der Umstellung auf Freesync sind AMD GPUs da konsequent raus. Die Monitor-Panel Hersteller sind auch auf eDP umgestiegen und haben LVDS in allen Monitoren die Freesync-fähig sind dadurch ersetzt.

[dargo]

Hmm... schreibt die PCGH auch.

Vega sieht einen High-Bandwidth Cache Controller, der in der GPU sitzt (On-Chip) und auf externen Speicher auf einem Interposer zugreift (On-Package), vor. Das kann HBM2 sein, ist jedoch nicht darauf limitiert. AMD könnte beispielsweise auch - rein theoretisch - den auf niedrige Latenzen optimierten Hybrid Memory Cube (HMC) nutzen, den Intel bei Knights Landing einsetzt.

http://www.pcgameshardware.de/Vega-Codename-265481/Specials/Architektur-NCU-HBCC-Vorstellung-1217460/

[Complicated]

HBCC bedeutet High Bandwidth Cache Conroller - dazu braucht es eine hohe Bandbreite aber nicht zwingend HBM. Wide-IO Memory oder HMC würden damit auch gehen. Der verwendete Cache muss nur genug Bandbreite haben.

[Gipsel]

Und wann geht es eigentlich mal in die Köpfe der Leute rein, daß jeglicher DRAM völlig unabhängig vom Interface (HBM, HMC, [G]DDR#, whatever) letzten Endes immer die gleichen absoluten Latenzen besitzt?
Und ja, der HBCC würde auch bei einer Karte mit GDDR5 funktionieren. Die lokal verfügbare Bandbreite muß nur angemessen sein, genau wie jetzt auch.

[Hübie]

Bist du dir da ganz sicher? HBCC ist im Prinzip ein Cache wenn ich es richtig verstanden habe. Und hier sind besonders auch Latenzen wichtig. Kurze Signalwege = bessere Latenzen. So gesehen macht HBCC nur mit HBM Sinn. Oder bin ich komplett auf dem Holzweg?

Na ja das Wort aus dem Marketing arbeitet natürlich mit HBM(2), aber das Prinzip kann selbst mit GDDR5X/6 umgesetzt werden.

LVDS wird von Intel und AMD seit 2015 nicht mehr unterstützt. Es wird ausgemustert mit den analogen Anschlüßen VGA und DVI-I:
https://newsroom.intel.com/news-releases/leading-pc-companies-move-to-all-digital-display-technology-phasing-out-analog/

Mit der Umstellung auf Freesync sind AMD GPUs da konsequent raus. Die Monitor-Panel Hersteller sind auch auf eDP umgestiegen und haben LVDS in allen Monitoren die Freesync-fähig sind dadurch ersetzt.

Nein, nein. Ich meinte nicht die Schnittstelle sondern die elektrische Beschreibung für das Funktionsprinzip:

At the electrical level, each lane consists of two unidirectional LVDS pairs operating at 2.5, 5, 8 or 16*Gbit/s, depending on the negotiated capabilities.

HBCC bedeutet High Bandwidth Cache Conroller - dazu braucht es eine hohe Bandbreite aber nicht zwingend HBM. Wide-IO Memory oder HMC würden damit auch gehen. Der verwendete Cache muss nur genug Bandbreite haben.

Lass uns doch mal hohe Bandbreite definieren. Busbreite finde ich ab 512 Bit groß, Bandbreite ab 512 GB/s. HBCC könnte man also im allgemeinen auch ohne HBM definieren. In diesem Thread und Kontext steht es ja mit Vega im Zusammenhang, klar.
Die Sinnhaftigkeit steigt und fällt mit der Controller Logik und ob es per App optimization erfordert oder eben per Treiber lösbar ist / wäre (ich tippe auf Treiber).

[Eldoran]

HBCC bedeutet High Bandwidth Cache Conroller - dazu braucht es eine hohe Bandbreite aber nicht zwingend HBM. Wide-IO Memory oder HMC würden damit auch gehen. Der verwendete Cache muss nur genug Bandbreite haben.
Der Cache muss genug Bandbreite haben, allerdings wenn der Cache eine zu hohe Latenz hat, hilft es auch nichts. Bei Speichertypen bei denen die Adressierung etc. spürbar Zeit kostet, ist die bei der Latenz zu berücksichtigen.
Ausserdem müssen auch tatsächlich die Daten aus dem Cache genutzt werden (etwa die Daten eine ausreichende Lokalität aufweisen und der Cache groß genug sein).

[Gipsel]

LVDS wird von Intel und AMD seit 2015 nicht mehr unterstützt. Es wird ausgemustert mit den analogen Anschlüßen VGA und DVI-I:
https://newsroom.intel.com/news-releases/leading-pc-companies-move-to-all-digital-display-technology-phasing-out-analog/

Mit der Umstellung auf Freesync sind AMD GPUs da konsequent raus. Die Monitor-Panel Hersteller sind auch auf eDP umgestiegen und haben LVDS in allen Monitoren die Freesync-fähig sind dadurch ersetzt.LVDS ist eine allgemeine Technik zur Signalübertragung. Daß die offiziell FPD-Links genannten Display-Interfaces oft auch nur als LVDS-Interface bezeichnet werden (sie nutzen dieses Verfahren, neuere wie DVI und HDMI benutzen das TMDS-Verfahren, Displayport wiederum LVDS), ändert nichts daran, daß z.B. PCIe (worum es Hübie ging) auch LVDS benutzt. ;)

Edit:
Zu lange dran rumeditiert.

[BlacKi]

entscheidet der HBCC nicht einfach nur was 1. in den HBM speicher muss, 2. nichtmehr benötigt wird und 3. was in den RAM ausgelagert werden kann (daten die keine große bandbreite benötigen)?
ob wir je erfahren werden wieviel chipfläche der HBCC kostet?

[Complicated]

Nein, nein. Ich meinte nicht die Schnittstelle sondern die elektrische Beschreibung für das Funktionsprinzip
Ich kann mich jetzt täuschen, doch ist das nicht ebenfalls das selbe?
eDP läuft nicht nach dem selben Funktionsprinzip wie LVDS - die Schnittstelle ist doch nach dem Funktionsprinzip benannt.

Siehe eDP Prinzip mit mehreren Datenleitungen. Digital:
https://kompendium.infotip.de/displayport.html#Prinzip
https://kompendium.infotip.de/files/wdb/GRAFIK/2400_SCHNITTSTELLEN/2430_DisplayPort/ABB_2430_01_03_DP_Channels.gif

LVDS Prinzip, analog:
https://kompendium.infotip.de/files/wdb/GRAFIK/2600_INFORMATIONTECHNIK/2600_GRUNDLAGEN_IT/ABB_2605_01_03_CML.gif

Als Implementation:

https://kompendium.infotip.de/files/wdb/GRAFIK/2600_INFORMATIONTECHNIK/2600_GRUNDLAGEN_IT/ABB_2605_01_04_SerDes.gif

http://www.planet3dnow.de/vbulletin/attachment.php?attachmentid=31833&d=1422750102

Edit:
@Gipsel.
Ja wenn es um PCIe geht so ist das LVDS, allerdings mit 128bit130bit Codierung ab der Version 3.0.

Edit2:
Das mit Displayport muss ich mir nochmal genauer anschauen in den docs.

[Troyan]

entscheidet der HBCC nicht einfach nur was 1. in den HBM speicher muss, 2. nichtmehr benötigt wird und 3. was in den RAM ausgelagert werden kann (daten die keine große bandbreite benötigen)?
ob wir je erfahren werden wieviel chipfläche der HBCC kostet?

Nein, das tut nicht der Controller, sondern der Treiber/Umgebung. Der Controller ist in der Lage zur Laufzeit direkt auf den Systemspeicher zu zugreifen.

[Gipsel]

Nein, das tut nicht der Controller, sondern der Treiber/Umgebung. Der Controller ist in der Lage zur Laufzeit direkt auf den Systemspeicher zu zugreifen.Dann wäre es keine Hardware-Lösung mittels eines HBC-Controllers. Der Controller steuert dem Namen nach schon, was gemacht wird. ;)
Durch den Treiber initiierte Page-Migration kann wohl auch P100(?) und Volta. Bei Vega sollte das aber darüber hinaus gehen.

[Troyan]

nVidias Page Migration Engine ist auch Hardware. Der Controller hat keine Ahnung darüber, wann Daten eines Spiels im Speicher sein müssen.

[Complicated]

Woher weiss der Cache eine CPU wann die Daten eines Spiels im Speicher sein müssen?

[Gipsel]

nVidias Page Migration Engine ist auch Hardware. Der Controller hat keine Ahnung darüber, wann Daten eines Spiels im Speicher sein müssen.Bei nV stimmt das eventuell (die schweigen sich über Details aus, vielleicht hat es ja mal wer getestet). Die Software muß da vielleicht sagen, was wo hin kommt. Oder die Page Migration Engine des P100 kann nur Page Faults handhaben, wenn noch Platz im VRAM ist, ansonsten muß Software eingreifen. Vielleicht geht es aber auch völlig automatisch ohne Softwareeingriff. Keine Ahnung.
Bei AMDs HBCC ist es den Präsentationen zufolge eher klar. Der fährt einen Caching-Algorithmus in Hardware (vermutlich irgendwelche Zugriffscounter und dann eine Art LRU-Strategie, weswegen er eben auch Cache-Controller heißt). Er kann durch Software konfiguriert oder auch abgeschaltet werden (Complicateds Analogie zu den Cache-Controllern von CPUs ist da recht passend), aber er sollte auch erstmal ohne Software-Interaktion auf GPU-Seite laufen (je nach dem wo eine angeforderte Adresse genau liegt, wird eventuell auf CPU-Seite ein Page-Miss-Interrupt ausgelöst und das OS muß die entsprechende Seite bereitstellen, falls die nicht im Speicher liegt [Auslagerungsdatei, memory mapped File auf der Festplatte oder sowas]).

Ob bei AMD die "Cachelines" des HBC jetzt 4kB Pages sind und das im Prinzip vielleicht sogar äquivalent zur Page Migration Engine des P100 ist, kümmert mich jetzt nicht sonderlich. Die kleineren nV-GPUs können es offenbar nicht, es ist nur unter CUDA verfügbar und für Consumer ist das sowieso deaktiviert. AMD bietet die Funktionalität offenbar unter den typischen Grafik-APIs an, ohne daß die Entwickler sich drum kümmern müssen.
=> Mehrwert für die Masse

@Complicated:
DisplayPort benutzt genau wie PCIe auch LVDS. Und digital ist sowieso alles nach VGA. Jede Display-Port-Lane (oder jede PCIe-Lane) ist ein mit LVDS betriebener Link. Die Bezeichnung der FPD-Links als LVDS war damals einfach nur Faulheit. LVDS bezeichnet das viel allgemeinere Prinzip der Datenübertragung über die (geringe) Spannungsdifferenz zweier Leitungen. Mehr nicht.

[Rincewind]

als Laie ist also der HBCC nichts anderes als ein "Türvorsteher" für den HBM-Speicher?

[Gipsel]

als Laie ist also der HBCC nichts anderes als ein "Türvorsteher" für den HBM-Speicher?In etwa so kommt das schon hin:
entscheidet der HBCC nicht einfach nur was 1. in den HBM speicher muss, 2. nichtmehr benötigt wird und 3. was in den RAM ausgelagert werden kann (daten die keine große bandbreite benötigen)?
Das wird so laufen, daß wenn ein Spiel z.B. 12GB VRAM belegen will (aber nur 8GB da sind), die vorhandenen 8GB belegt werden und eine Statistik geführt wird, auf was wie häufig zugegriffen wird. Benötigt dann ein Spiel etwas aus den 4GB Daten, die nicht mehr in den VRAM gepaßt haben, wird es automatisch aus dem Systemspeicher geladen und gegen etwas ausgetauscht, was in letzter Zeit nicht benötigt wurde. Und das Alles on-the-fly, ohne das die GPU dafür mit der Berechnung des Frames anhalten muß.

[dargo]

Das wird so laufen, daß wenn ein Spiel z.B. 12GB VRAM belegen will (aber nur 8GB da sind), die vorhandenen 8GB belegt werden und eine Statistik geführt wird, auf was wie häufig zugegriffen wird. Benötigt dann ein Spiel etwas aus den 4GB Daten, die nicht mehr in den VRAM gepaßt haben, wird es automatisch aus dem Systemspeicher geladen und gegen etwas ausgetauscht, was in letzter Zeit nicht benötigt wurde. Und das Alles on-the-fly, ohne das die GPU dafür mit der Berechnung des Frames anhalten muß.
Ich kann mir die Funktionsweise immer noch nicht so recht vorstellen. Das klingt ja so, als ob der HBCC nun die "Faulheit" der Spieleentwickler gerade biegen muss. Normalerweise sollte es doch die Aufgabe der Entwickler sein möglichst ressourcenschonend mit dem Speicher zu arbeiten. Ich muss das wohl erst in der Praxis sehen um es verstehen zu können. :freak:

[iuno]

Das ist ja auch Sinn der Sache. Wozu soll er denn sonst gut sein?
Natuerlich kann er weder Latenzen verbessern noch nicht vorhandenen Speicher herzaubern. Er wird halt besser als bisher sortieren was rein und was raus kommt. Auf den Systemspeicher zugreifen geht schon ewig, wenn mehr gebraucht wird als VRAM vorhanden wird es eh dort reingeschrieben. Insofern hat es natuerlich auch rein gar nichts mit der verwendeten Speichertechnologie (HBM oder GDDRx) zu tun

[dargo]

Du hast mich glaube ich nicht verstanden. An dem gezeigten Beispiel mit RotTR und Deus Ex mit den simulierten 2GB Vram. Dort ist die Framerate ohne HBCC komplett eingebrochen. Mit HBCC war die Framerate hoch. Wieso schafft das der Spieleentwickler nicht? Was macht also HBCC anders?

Edit:
Oder liegts einfach nur an der Vielfalt der PC-Hardware im Gegensatz zur Konsole? Und sich deshalb AMD entschieden hat eine Optimierung in Hardware zu implementieren?

[StefanV]

Das HBM2 erst mal teurer ist als GDDR5/X, ist klar und zu erwarten.

Ich sehe das Problem darin, dass der Konsument aktuell nichts von HBM2 hat und in Kombination mit dem höheren Preis und dem entsprechend entweder a.) höheren Marktpreis für Consumer-Vega oder b.) geringerem Gewinn für AMD schauts nicht so geil aus.

Lies bitte noch mal genau, worum hier gerade Diskutiert wird.

Danach bietet HBM durchaus einige Vorteile zu GDDR5/6 nämlich weniger Stromverbrauch. Das heißt auch, dass ein Schreib-/lese Zyklus deutlich weniger Energie verbraucht und man den Speicher dadurch öfter nutzen kann. Auch der HBCC wird dadurch erst möglich., Bei GDDR würde der Stromverbrauch ev. durch die Decke gehen. Und hier ist der nächste Vorteil:
Man kommt mit (deutlich?) weniger Grafikspeicher aus. UNd Zugriffe auf den PC-Hauptspeicher sind wohl deutlich billiger...

Und wann geht es eigentlich mal in die Köpfe der Leute rein, daß jeglicher DRAM völlig unabhängig vom Interface (HBM, HMC, [G]DDR#, whatever) letzten Endes immer die gleichen absoluten Latenzen besitzt?
Und ja, der HBCC würde auch bei einer Karte mit GDDR5 funktionieren. Die lokal verfügbare Bandbreite muß nur angemessen sein, genau wie jetzt auch.
1. Naja, du hast ja noch 'nen paar Pico/Nano Sekunden Verzögerung durch die Länge der Leiterbahnen. Da die Wege bei HBM deutlich kürzer sind, spart man hier durchaus 'nen bisserl ein.

2. Ja, es wäre prinzipiell möglich, aber wäre es auch sinnvoll? Erhöht man nicht mit dem HBCC die Zugriffe auf den Speicher, so dass hier der Verbrauch ev. explodieren könnte??

Das ist ja auch Sinn der Sache. Wozu soll er denn sonst gut sein?
Natuerlich kann er weder Latenzen verbessern noch nicht vorhandenen Speicher herzaubern. Er wird halt besser als bisher sortieren was rein und was raus kommt. Auf den Systemspeicher zugreifen geht schon ewig, wenn mehr gebraucht wird als VRAM vorhanden wird es eh dort reingeschrieben. Insofern hat es natuerlich auch rein gar nichts mit der verwendeten Speichertechnologie (HBM oder GDDRx) zu tun
Ja, es geht prinzipiell, ist aber verdammt lahm und muss über die CPU bzw den Treiber erledigt werden.
Mit dem HBCC geht das ganze 'flutschiger'.

Das hat den Vorteil, dass die Latenzen sich verringern.
Das hat den Nachteil, dass man damit auch das System kompromittieren könnte...

[Skysnake]

Bei nV stimmt das eventuell (die schweigen sich über Details aus, vielleicht hat es ja mal wer getestet). Die Software muß da vielleicht sagen, was wo hin kommt. Oder die Page Migration Engine des P100 kann nur Page Faults handhaben, wenn noch Platz im VRAM ist, ansonsten muß Software eingreifen. Vielleicht geht es aber auch völlig automatisch ohne Softwareeingriff. Keine Ahnung.

Ja, das ist leider wirklich ein Problem, das nVidia da die Klappe zu hält. Und da die Dinger halt teuer und nicht sonderlich verbreitet sind, hat sich das scheinbar auch noch keiner genauer angeschaut. Die Leute werden da von nVidia leider schon ziemlich eingelullt....


Bei AMDs HBCC ist es den Präsentationen zufolge eher klar. Der fährt einen Caching-Algorithmus in Hardware (vermutlich irgendwelche Zugriffscounter und dann eine Art LRU-Strategie, weswegen er eben auch Cache-Controller heißt). Er kann durch Software konfiguriert oder auch abgeschaltet werden (Complicateds Analogie zu den Cache-Controllern von CPUs ist da recht passend), aber er sollte auch erstmal ohne Software-Interaktion auf GPU-Seite laufen (je nach dem wo eine angeforderte Adresse genau liegt, wird eventuell auf CPU-Seite ein Page-Miss-Interrupt ausgelöst und das OS muß die entsprechende Seite bereitstellen, falls die nicht im Speicher liegt [Auslagerungsdatei, memory mapped File auf der Festplatte oder sowas]).

Jup, so sollte es an sich funktionieren. Im Prinzip ist das halt die Funktionalität, die CPUs schon ewig beherrschen nur eben auf GPUs erweitert.


Ob bei AMD die Cachelines jetzt 4kB Pages sind und das im Prinzip vielleicht sogar äquivalent zur Page Migration Engine des P100 ist, kümmert mich jetzt nicht sonderlich. Die kleineren nV-GPUs können es offenbar nicht, es ist nur unter CUDA verfügbar und für Consumer ist das sowieso deaktiviert. AMD bietet die Funktionalität offenbar unter den typischen Grafik-APIs an, ohne daß die Entwickler sich drum kümmern müssen.
=> Mehrwert für die Masse

Also da möchte ich klar widersprechen!

Es macht einen gewaltigen Unterschied, ob man 4kB oder z.B. 64 Byte übertragen muss bezüglich der Latenzen. Genauso auch beim Speicherverbrauch. Wenn man nur ein 4 Byte Datum braucht, aber einmal 64 und einmal 4096Byte vorhalten muss, dann ist das schon etwas anderes.

Gut für Grafikanwendungen wird das eventuell nicht sooo schlimm sein, da man meist nur liest, aber wenn man morphende Texturen hat, dann kann das schon scheise sein, wenn man immer ganze Pages hin und her schieben muss...

Vor allem aber für GPGPU ist das echt scheise, wenn man mehr als eine GPU verwenden will. Klar, oft ist es egal, da man die Domain decomposition schön machen kann, aber für die Fälle ist das ja auch eher weniger interessant, weil man die paar Zeilen Code auch von Hand hinschreiben könnte und die Transfers eben explizit handhaben könnte, was bei nVidia wohl noch immer effizienter ist als den virtual unified Addressspace zu verwenden.

Wenn man es aber wirklich richtig gut brauchen kann, weil man die Zugriffsmuster eben NICHT! kennt zur Laufzeit, dann tun die 4k Pages schon richtig weh -.-

Ich kann mir die Funktionsweise immer noch nicht so recht vorstellen. Das klingt ja so, als ob der HBCC nun die "Faulheit" der Spieleentwickler gerade biegen muss. Normalerweise sollte es doch die Aufgabe der Entwickler sein möglichst ressourcenschonend mit dem Speicher zu arbeiten. Ich muss das wohl erst in der Praxis sehen um es verstehen zu können. :freak:
Na es ist genau das gleiche Verhalten wie der Cache in den CPUs, bzw eben auch der Systemspeicher + Pageing mit der Auslagerungsdatei.

Man kann mehr Speicher allocieren und auch verwenden als man physikalisch hat. Alles kein Problem, so lange man an sich kleiner bleibt als physisch vorhanden. Wenn man halt mehr verwendet, dann müssen halt Daten auf einem Massenspeicher (bei Vega wäre das erstmal der MainMemory von der CPU und danach die HDD/SSD) ausgelagert werden und wenn man diese braucht, gibt es einem major PageFault und die Daten werden wieder in den RAM geladen, dafür halt etwas anderes ausgelagert.

Die Alternative wäre halt, dass das Programm abschmiert.

Mit der Faulheit der Entwickler hat das auch nicht zwingend etwas zu tun. Man kann oft vorhersagen, was man braucht, aber eben nicht immer, bzw nur mit einer schlechten Qualität. Also muss man sehr sehr viel mehr Daten im RAM halten, als eigentlich nötig ist. Und das kostet natürlich auch Zeit die hin und her zu schieben. Insbesondere wenn der VRAM schon zu klein ist um alles zu halten, und die Erfahrung zeigt, das man meist zum genau falschen Zeitpunkt etwas auslagert....

Der HBCC kann da viel bringen gerade auch bezüglich Latenzen im Vergleich zu einer händischen Bearbeitung durch den Entwickler/Treiber in Software, weil man eben nur die DAten holt, die man braucht und es eben dazu auch noch eine Hardware und keine Softwarelösung ist.

Unter Linux kann man davon ausgehen, das ein Trab in den Kernelspace um die 20µs dauert, wenn ich es richtig im Kopf habe. Das wären also schon mal über 0.1% der Zeit eines 60FPS Frames die nur für nen beschissenen Trab ins OS drauf gehen um etwas über Softwar anzustoßen....

Ich hoffe ihr seht, das man da ziemlich schnell einen relevanten Teil der zur Verfügung stehenden Zeit für völligen Bullshit verbrät, während der im schlimmsten Fall die GPU einfach nur dumm rum steht und nichts macht.

Der HBCC hat daher je nachdem, wie das genau implementiert wurde, einen großen Vorteil zu generieren.

[gedi]

Verändert sich durch HBCC eigentlich der Bedarf an Bandbreite?

[Skysnake]

Kann sein.

Kommt halt darauf an, wie gut der Entwickler vorhersagen kann, was wann wo wie gebraucht wird und mit welcher Granularität er die Daten hin und her schiebt.

Je nachdem, kann der Entwickler halt viele Daten hin und her schieben, die er NIE braucht, es aber eben nicht besser weiß oder sonstige Limitierungen ihn dazu zwingen das eben genau so zu machen.

Bisher geht man halt den einfahen Weg und fordert einfach, dass der RAM so groß ist, das man alles laden kann. Das ist halt die Holzhammer-Methode, bei der man einfach mehr Hardware auf ein Problem schmeist, um es zu umgehen...

[BlacKi]

In etwa so kommt das schon hin:

Das wird so laufen, daß wenn ein Spiel z.B. 12GB VRAM belegen will (aber nur 8GB da sind), die vorhandenen 8GB belegt werden und eine Statistik geführt wird, auf was wie häufig zugegriffen wird. Benötigt dann ein Spiel etwas aus den 4GB Daten, die nicht mehr in den VRAM gepaßt haben, wird es automatisch aus dem Systemspeicher geladen und gegen etwas ausgetauscht, was in letzter Zeit nicht benötigt wurde. Und das Alles on-the-fly, ohne das die GPU dafür mit der Berechnung des Frames anhalten muß.
ich glaube wir haben noch garnicht alles gesehen. zb. das nachladen aus dem systemspeicher. es wird sich zeigen müssten wie gut das klappen wird.

[Der_Korken]

Woher weiß eigentlich der HBCC ob eine angefragte Speicheradresse im VRAM liegt oder nicht? Müsste man dazu nicht wie bei einem CPU-Cache für jede Cacheline noch einen Tag speichern? Das käme ja ziemlich was zusammen, selbst wenn man 4KB ansetzt: 2 Mio. Cachelines bei 8GB VRAM, macht bei 32bit Tag schon 8 MB Overhead. Wo speichert man den? Im VRAM selbst würde das ja ständig Doppelzugriffe bedeuten und in der GPU ein großen Haufen Die-Fläche, die man verbraten muss (und der größer wird, je mehr VRAM man verbaut ...).

[-=Popeye=-]

Ich dachte dies wäre bereits aufgrund verschiedener Ansätze generell nicht vergleichbar und somit auch nicht machbar. Auf jeden Fall gibt es bis Dato keine Grafikkarte, welche TR in 4k@Very High mit lediglich 2G Vram bei den min-FPS mit 47FPS stützt. Das Ergebnis ist imo mehr als beeindruckend, bleibt nur abzuwarten ob das Feature immer greift, oder ob es eines Profils im Treiber bedarf (was dann etwas meh wäre).

Wer es glaubt wird seelig, aktuelle Karten verballern deutlich mehr.


https://www.youtube.com/watch?v=KexQ9ZgIrC4&feature=youtu.be

https://www.youtube.com/watch?v=qt1KgBGDphM&feature=youtu.be

edit: nicht ohne Grund sind 16GB im Consumer-Gespräch

[StefanV]

wie bei einem CPU-Cache für jede Cacheline noch einen Tag speichern?
joa, sowas in der Art soll doch HBCC sein...

Ein DRAM Cache für Grafik...

[Skysnake]

Woher weiß eigentlich der HBCC ob eine angefragte Speicheradresse im VRAM liegt oder nicht? Müsste man dazu nicht wie bei einem CPU-Cache für jede Cacheline noch einen Tag speichern? Das käme ja ziemlich was zusammen, selbst wenn man 4KB ansetzt: 2 Mio. Cachelines bei 8GB VRAM, macht bei 32bit Tag schon 8 MB Overhead. Wo speichert man den? Im VRAM selbst würde das ja ständig Doppelzugriffe bedeuten und in der GPU ein großen Haufen Die-Fläche, die man verbraten muss (und der größer wird, je mehr VRAM man verbaut ...).
hmmm du sprichst da gerade einen wichtigen Punkt an!

An sich wollte ich gerade sagen, genau dafür ist der TLB gut, nur eben auf der Basis davon, ob die Daten im VRAM liegen oder nicht. Und dann kam der Ohhhh FUUUUU Moment.

Du hast nämlich den Hacken erfasst! Das ist mir durchgegangen, weil auf CPUs ist es erstmal kein Problem auf Cacheline Ebene zu arbeiten (Ok man ist nicht NUMA aware in diesem Fall, darf also nicht zu oft wechseln)

Das PRoblem ist, die Cacheline liegt nur im Cache der anderen CPU, der vergleichsweise riesig ist. Man hofft also dass der Wert lange im Cache bleibt.

Und ja, da braucht man die Tags.

Die Caches bei GPUs sind aber klein und die Daten bleiben eher kurz in den Caches....

Man muss also den HBM als "Cache" missbrauchen. Da wird es aber mit den Tags wahrscheinlich doch doof, wegen den Latenzen.

Ganze Pages zu laden würde die Sache da sehr viel einfacher machen.... :wall:

FuckFuckFuck..... Das ist mir bisher wirklich noch nicht bewusst geworden....

Man müsste sich da echt mal durchrechnen ob das auf Cacheline basis überhaupt geht. Nach deinem Einwurf/Frage würde ich nämlich jetzt ein riesen fragezeichen dahinter machen...

Da war wohl der Wunsch, dass das geht zu groß und hat mich das von dir genannte Problem übersehen lassen... :down::redface:

[AffenJack]

Das wird so laufen, daß wenn ein Spiel z.B. 12GB VRAM belegen will (aber nur 8GB da sind), die vorhandenen 8GB belegt werden und eine Statistik geführt wird, auf was wie häufig zugegriffen wird. Benötigt dann ein Spiel etwas aus den 4GB Daten, die nicht mehr in den VRAM gepaßt haben, wird es automatisch aus dem Systemspeicher geladen und gegen etwas ausgetauscht, was in letzter Zeit nicht benötigt wurde. Und das Alles on-the-fly, ohne das die GPU dafür mit der Berechnung des Frames anhalten muß.

Solange man in einer Spielregion bleibt, wo die Texturen ähnlich sind macht das für mich auch Sinn. Aber sobald sich mehr gleichzeitig ändert, muss das alles über den PciE Slot drüber. Bei mehr VRam war das verschwendend, aber wurde vielleicht schon mal im VRam vorgehalten. Aber so müsste es dann doch viel eher zu Rucklern kommen?

[tm0975]

Solange man in einer Spielregion bleibt, wo die Texturen ähnlich sind macht das für mich auch Sinn. Aber sobald sich mehr gleichzeitig ändert, muss das alles über den PciE Slot drüber. wahrscheinlich wird heutzutage alles mögliche gleich in den vram geladen. aber wer schafft es schon bis zum endboss? ;D

[Eldoran]

Woher weiß eigentlich der HBCC ob eine angefragte Speicheradresse im VRAM liegt oder nicht?
Eine sehr gute Frage. Ich weiss zwar, wie Cache oder Virtual Memory normalerweise funktioniert, das scheint aber nicht ganz zu passen.
Da lag es einmal nahe zu vergleichen, wie das bei Intel (Crystalwell) funktioniert. Ich finde aber auch keine wirklich Erklärungen der Details dazu. Anandtech war da noch eine der bessernen Erklärungen (http://www.anandtech.com/show/6993/intel-iris-pro-5200-graphics-review-core-i74950hq-tested/3). Intel hat da auch diverse Varianten gebaut (https://en.wikichip.org/wiki/intel/microarchitectures/skylake#eDRAM_architectural_changes), es dürfte also schwierig sein.
AMD hat zu diesem Thema Patente angemeldet (http://semiaccurate.com/forums/showthread.php?t=8125).
Diesem Patent (https://www.google.com/patents/US20130138892) nach scheint es tatsächlich mit tags zu laufen. Das Patent spricht von 4KB Lines, wobei die dann weiter in 64 Byte Lines unterteilt werden, der Rest ist dann sehr variabel. Möglicherweise ist das auch bei Vega variabel (könnte auch vom HBCC per Firmware/Treiber auf den jeweiligen Einsatzzweck optimiert werden).
Allgemein gilt normalerweise dass Assoziativität und kleine Cache Lines zwar eine höhere Hitrate bringen, aber mehr Daten auf Metadaten verbraten. Weiters sinkt aber der Nutzen mit der Größe des gesamten Cache (https://courses.cs.washington.edu/courses/cse378/09au/lectures/cse378au09-20.pdf).
Hinzukommt, dass bei HBM(2) auf die Daten in 256 bit Blöcken zugegriffen wird (http://monitorinsider.com/HBM.html). Es ist somit effizient, die Tags auf diese Größe auszurichten (bzw. Teiler davon).
Was jetzt da die sich ergebenden sinnvollen/effizienten Strategien bei welchen Workloads und welchen HBM Größen ist, kann ich Ad Hoc nicht sagen.

[reaperrr]

Was ich mal an dieser Stelle in den Raum werfen möchte: Vega10 scheint gemessen an den 64 (N)CUs doch ziemlich groß zu sein, dafür dass er kein 1:2 DP und nur ein 2048-bit HBM-SI hat.
Wäre es nicht möglich, dass V10 einfach einen riesigen L2 von 16 MB hat? In 14LPP sollte das gegenüber normal zu erwartenden 4MB, wenn ich nach Zen's L2 Fläche gehe, höchstens ~40mm² mehr bedeuten, würde aber einiges mehr an Speicherzugriffen abfangen.

[Hübie]

Wo genau liegt denn jetzt der "Hacken" (:D) Skysnake? Die Tags könnten in einen eigenen Cache bzw Register von wo aus bei Zugriffen gelesen wird.

ps: Haken passt besser. SCNR

Edit: Ich mein: Das Ding heißt High Bandwidth Cache Controller...

[Eldoran]

wahrscheinlich wird heutzutage alles mögliche gleich in den vram geladen. aber wer schafft es schon bis zum endboss? ;D
Das dürfte der Fall sein. Allerdings ist ja bei normalen GPUs das ganze nicht wie bei Vega organisiert, dort sollte der gesamte Virtual Memory für die Application nutzbar sein, was davon gerade im VRAM ist, entscheidet der HBCC. Änderungen sind da lediglich der Latenz und Bandbreite des Speichersystems unterworfen und müssen nicht zumindest auch durch den Treiber. Bei Servern bringen derartige Hardware unterstützte Controller Karten teilweise dramatische Leistungssteigerungen/Lastreduktion bei der CPU.
Wobei, weiß vielleicht Jemand hier im Forum Details, was aktuelle Consumer GPUs können, wie das dort genau funktioniert (vor allem wenn der ganze Level eben nicht im VRAM Platz hat) - Latenz, etc. Wie sieht das für einen Programmierer in DX9/11/12 OpenGL/Vulcan aus?

[HOT]

Ganz nur Cache kann HBM ja nicht sein, dass muss also eine Hybridlösung sein. Der Framebuffer nutzt ganz sicher stets den HBM als Speicher, während der Rest der Daten den Hauptspeicher als Speicher nutzt und den HBM nur noch als Cache. So wird auch klar, warum AMD 2GB gewählt hat für die Demonstation, der Framebuffer passte da komplett rein und man hatte noch etwas platz für das Caching. Das war sicher nicht optimal, zeigt aber wie mächtig eine richtig angesetzte Cache-Organisation ist, da der HBM die hohe Latenz, die durch den Zugriff auf den Hauptspeicher entsteht, ganz gut abfedern konnte. Mit 8GB sieht das Ergebnis sicherlich noch viel besser aus, aber das unterliegt selbstredend dem abnehmenden Ertrag. Schon zwischen 4 und 8GB könnte es sein, dass man bei bisherigen Titeln einfach keinen Unterschied mehr merkt. Kann natürlich sein, dass einem der Hauptspeicher ausgeht, da könnte Vega generell mehr Speicherverbauch mitbringen. Und nein, das geht sicher nicht mit GDDR, da man für das Caching sicherlich eine deutlich niedrigere Latenz braucht als GDDR liefern kann.


Und es heißt Vulkan! Entweder Vulkan oder Volcano, aber alles dazwischen gibts nicht :D. Es ist tatsächlich die deutsche Schreibweise, die da gewählt wurde.

[Complicated]

Vielleicht hilft hier folgendes beim Verständnis. Zunähst einmal arbeiten ja auch GPUs schon mit L2 Cache. Polaris hat davon 2 MB verbaut.

https://static.gamespot.com/uploads/original/823/8237367/3219275-polaris10+ipc+gains.png

AMD hat einiges an HSA Technik in die Speicherverwaltung bei dGPUs einfließen lassen:
http://www.extremetech.com/wp-content/uploads/2013/04/AMD-HSA2.jpg

Hier nochmal das Schaubild des HBCC:
http://www.heise.de/imgs/18/2/1/1/1/0/7/8/GPU-76f6e980cfc7a64f.png

Im mittleren Schaubild bei der HSA Speicherarchitektur ist ein entscheidender Satz enthalten:
"The GPU can seamlessy access virtual memory addresses that are not (yet) present in physical memory" - Also die GPU kann auf Adressen zugreifen, die noch gar nicht in den physischen Speicher geladen sind. Das bedeutet, dass Daten, welche im System-RAM liegen und selbst auf der SSD oder dem Netzlaufwerk schon komplett mit einer Speicheradresse versehen sind. Erläutert wurde das hier mal etwas genauer:
https://www.pcper.com/reviews/Graphics-Cards/AMD-Vega-GPU-Architecture-Preview-Redesigned-Memory-Architecture
If you think back to what AMD announced in the middle of last year with the SSG product line, it was a graphics card with an SSD on-board, increasing the memory capacity of the platform. At the time the implementation was crude, requiring the applications to access the SSD storage through the Windows storage layers despite being on-board with the GPU itself. With Vega 10 this won’t be necessary – the HBC itself will can communicate with flash memory through PCIe, according to one conversation I’ve had with NVMe and a full x16 lanes of PCI Express 3.0. (There is lots to debate along this: will AMD have its own SSD controller as part of the HBC or will they use a third party? If they go their own route, what expertise do they have to outperform the current NVMe options on the market that are limited to PCIe 3.0 x4? What if AMD utilized something like Intel 3D XPoint / Optane?) A high-end consumer Vega 10 GPU with 8-16GB of HBM2 and a 128GB SSD on it opens a totally new set of doors for how games and applications can be written and optimized for.

The controller is built to have very fine grained data movement capabilities, allowing it to move memory between the different layers (cache and other storage options) in small chunks, improving the efficiency of the movement. Though AMD isn’t talking about performance advantages they did show a couple of examples of current generation games that allocate a lot of memory on high end graphics cards (8GB+) but rarely access more than half of that through any reasonable portion of time. The implication is that with a HBC and controller managing this memory through hardware dynamically, it could effectively offer a perceived infinite memory allocation area and handle movement from the SSD and HBC behind the scenes.

Ich meine schaut man sich Hybrid Festplatten an, die eine Beschleuniger-SSD beinhalten oder aktuell Intels Optane-Memory, so ist das eigentlich gar nicht so ein Hexenwerk. Wichtig ist, dass so wenig wie möglich herum kopiert wird beim Zugriff auf bestimmte Daten. Im Prinzip kann das jeder SSD Controller. Hier natürlich noch weiter ausgearbeitet und clever integriert.

[Digidi]

Ich bin ja mal gespannt. Ich könnte mir auch vorstellen das Texturen jetzt komprimiert werden und dann abgelegt werden. Es gibt ja schon 4k Texturen. Nur wer schaut die sich wirklich an? In Spielen krächze ich ja nicht am Fußboden rum und bewundere den schön strukturierten Marmor in 4k.

Wahrscheinlich wird dann eine Analyse der Texturen gemacht, in welcher Auflösung sie wirklich noch aufgelöst werden, und dann diese Ergebniss gespeichert.

[Eldoran]

@Complicated: Ja Vega hört sich in vielem nach HSA an. Gerade das HW Coherecny im 2. Bild (HSA) klingt sehr nach IF. Es sieht zumindest so aus, als ob das der Plan dahinter war. Allerdings ob die Geräte wirklich alle notwendigen Teile bereits enthalten, ob diese auch alle korrekt funktionieren und ob diese in allen Modellen auch nutzbar sind, ist eine gute Frage (und ein sehr heißes Streitthema). Wenn das nicht spätestens beim Launch von Vega FE groß angekündigt wird, gibt es entweder noch unüberwindbare Bugs in der Hardware, oder es stellt erst eine frühere Ausbaustufe dar (es fehlt also planmäßig irgend ein Teil).

[Hübie]

Ich bin ja mal gespannt. Ich könnte mir auch vorstellen das Texturen jetzt komprimiert werden und dann abgelegt werden. Es gibt ja schon 4k Texturen. Nur wer schaut die sich wirklich an? In Spielen krächze ich ja nicht am Fußboden rum und bewundere den schön strukturierten Marmor in 4k.

Wahrscheinlich wird dann eine Analyse der Texturen gemacht, in welcher Auflösung sie wirklich noch aufgelöst werden, und dann diese Ergebniss gespeichert.

Ich denke dass die meisten Spiele schon gängige Kompressionsverfahren nutzen um so weniger VRAM zu belegen. Das ist bis zu einem Gewissen Grad Verlustarm bzw. Verlustfrei. Hat mit HBCC jedoch wenig bis gar nix zu tun so lang es keine Hardwareimplementierung mit eigenen Lösungen gibt (was ich für wenig wahrscheinlich und wenig sinnvoll halte).

[iuno]

Natuerlich werden Texturen komprimiert und "4k Texturen" sind ueberhaupt ein bloeder Begriff, weil es keine Info dazu gibt, auf welche Flaeche sie gemappt werden. Da koennen sie schon 4096x4096 px gross sein, wenn es eine Megatextur ist, die eine ganze Welt abdeckt ist es halt trotzdem nur Matsch.

[aceCrasher]

Ich bin ja mal gespannt. Ich könnte mir auch vorstellen das Texturen jetzt komprimiert werden und dann abgelegt werden. Es gibt ja schon 4k Texturen. Nur wer schaut die sich wirklich an? In Spielen krächze ich ja nicht am Fußboden rum und bewundere den schön strukturierten Marmor in 4k.

Wahrscheinlich wird dann eine Analyse der Texturen gemacht, in welcher Auflösung sie wirklich noch aufgelöst werden, und dann diese Ergebniss gespeichert.

Soweit ich weiß sind Spieltexturen generell bereits komprimiert, sieht man schön bei so Hobbys wie Skyrim modding, dort gibt es n Haufen von verschiedenen Moddern verwendete Kompressionsverfahren, die mehr oder weniger gut funktionieren.

Bei den aktuellsten Verfahren is die Ersparnis schon ziemlich ordentlich und der Unterschied ist selbst beim hin- und herschalten aufm Desktop extrem gering, geschweige denn im Spiel selbst.

Und 4096x4096 Texturen können durchaus sinn machen - kommt völlig auf die Größe der Objekte an auf die sie aufgetragen werden, bei - wieder mal Skyrim als Beispiel - Objekten wie Drachen, die durchaus mal fast den ganzen Bildschirm ausfüllen sehe ich auch noch einen deutlichen Vorteil durch die 8192x8192 Textur die ich benutze. Ganz im Gegensatz zu einem winzigen Holzscheit, da sehe ich zwischen 1024x1024 und 2048x2048 schon keinen Unterschied mehr.

[Digidi]

Natuerlich werden Texturen komprimiert und "4k Texturen" sind ueberhaupt ein bloeder Begriff, weil es keine Info dazu gibt, auf welche Flaeche sie gemappt werden. Da koennen sie schon 4096x4096 px gross sein, wenn es eine Megatextur ist, die eine ganze Welt abdeckt ist es halt trotzdem nur Matsch.

Das Problem ist ja das sämtliche Texturen zurzeit in normaler Größe Abgelegt werden. Auch wenn es dann nur eine kleine Kachel am Fußboden ist wofür sie verwendet wird. Natürlich kannst du dich auf den Fußboden legen wodurch die Kachel wieder mega groß wird, aber wann passiert das schon? Deshalb wird die nominale Größe der Textur der realen Größe angepasst.

Das würde übrigens noch zusätzlich zur Kompression oben drauf kommen, da hab ich mich falsch ausgedrückt.

Was mich interessiert, was ist denn wenn doch mal alle großen Daten benötigt werden. Dann wird es doch schönes stottern geben, bis das nachgeladen ist? So ganz verstehe ich nicht wie der HBCC das Risiko frei handeln will.

[Setsul]

Woher weiß eigentlich der HBCC ob eine angefragte Speicheradresse im VRAM liegt oder nicht? Müsste man dazu nicht wie bei einem CPU-Cache für jede Cacheline noch einen Tag speichern? Das käme ja ziemlich was zusammen, selbst wenn man 4KB ansetzt: 2 Mio. Cachelines bei 8GB VRAM, macht bei 32bit Tag schon 8 MB Overhead. Wo speichert man den? Im VRAM selbst würde das ja ständig Doppelzugriffe bedeuten und in der GPU ein großen Haufen Die-Fläche, die man verbraten muss (und der größer wird, je mehr VRAM man verbaut ...).
https://videocardz.com/69475/amd-radeon-vega-spotted-with-16gb-memory-and-1600-mhz-clock
Da fehlen 192 MB, wäre also eine Möglichkeit.

HBM an sich ist ja auch kein Cache, hat also weder Sets noch Lines.
Es hindert einen also eigentlich niemand daran z.B. die Hälfte des VRAM nur in 128 MB Blöcke zu unterteilen. Klar, man braucht vielleicht nicht alles in den 128 MB, aber besser als nur die Möglichkeit zu haben, dass etwas entweder im VRAM ist oder nicht. Wären 32 Blöcke, mal 22 bit Tag (für vollen 49 bit Raum) + 5 bit Offset, das lässt sich gut auf der GPU behalten. Ist zwar nicht ganz so speichereffizient, aber man muss nicht jedesmal 8 MB (geteilt durch Anzahl der Sets, falls HBC tatsächlich so organisiert wird) an Tags durchsuchen nur um die physische Adresse im HBM zu bekommen. Cache Line State bez. Coherency Protocol muss vollständig gespeichert werden, aber das eine MB stört nicht so sehr und wenn man darauf zugreifen muss sind die beteiligten Latenzen sowieso höher.

[Gipsel]

@Skysnake: Deswegen hatte ich ja Pages als "Cachelines" ins Spiel gebracht ;). Ist erstmal einfacher. Für Algorithmen, die halbwegs Kontrolle über ihre Zugriffe haben und z.B. mit Cacheblocking-Strategien Datenlokalität auszunutzen versuchen, sind die Pages perfekt (deutlich geringerer Overhead). Später kommt dann vielleicht mal mehr.

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

Woher weiß eigentlich der HBCC ob eine angefragte Speicheradresse im VRAM liegt oder nicht? Müsste man dazu nicht wie bei einem CPU-Cache für jede Cacheline noch einen Tag speichern? Das käme ja ziemlich was zusammen, selbst wenn man 4KB ansetzt: 2 Mio. Cachelines bei 8GB VRAM, macht bei 32bit Tag schon 8 MB Overhead. Wo speichert man den? Im VRAM selbst würde das ja ständig Doppelzugriffe bedeuten und in der GPU ein großen Haufen Die-Fläche, die man verbraten muss (und der größer wird, je mehr VRAM man verbaut ...).Schon die heutigen AMD-GPUs legen Pagetables im VRAM an. Und 8 oder auch 16MB für Pagetables bei 8GB VRAM sind gerade mal 0,1-0,2%, also ziemlich irrelevant.
Und das mit den mehrfachen Zugriffen (es bleibt ja nicht bei doppelt, schau Dir mal an, wie Pagetables heute meist organisiert sind ;)) mindert man bei CPUs seit recht langer Zeit durch die spezialisierten TLB-Caches (die sind nur für die Address-Translation da und Cachen die Pagetables), nur bei TLB-Misses kommt es zum "page table walk".

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

Solange man in einer Spielregion bleibt, wo die Texturen ähnlich sind macht das für mich auch Sinn. Aber sobald sich mehr gleichzeitig ändert, muss das alles über den PciE Slot drüber. Bei mehr VRam war das verschwendend, aber wurde vielleicht schon mal im VRam vorgehalten. Aber so müsste es dann doch viel eher zu Rucklern kommen?Wenn Du eine 8GB Karte ohne HBCC mit einer 8GB-Karte mit HBCC vergleichst, natürlich nicht.
Und PCIe 3.0 hat 16GB/s Bandbreite. Wieviele neue Texturen und Buffer müssen denn da bei einem Szenenwechsel transferiert werden? Die Übertragung von z.B. 160MB würde nur 10ms dauern. Und das ist der worst Case, da ja vermutlich ein Page Miss nur die betroffenen Wavefront anhält, alles Andere auf dem Chip aber weiterläuft. Der Transfer und die Berechnung des Frames laufen also überlappend ab (was heute nicht geht, man kann mit der Berechnung gar nicht anfangen, solange nicht alle benötigten Buffer gemappt sind). Die zusätzliche Verzögerung dürfte im Normalfall deutlich niedriger liegen (im Optimalfall nahe Null, weil die angehaltenen Wavefronts das später wieder aufholen und die Auslastung des Chips nicht/kaum einbricht).

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

Hinzukommt, dass bei HBM(2) auf die Daten in 256 bit Blöcken zugegriffen wird (http://monitorinsider.com/HBM.html). Es ist somit effizient, die Tags auf diese Größe auszurichten (bzw. Teiler davon).Vielfache, nicht Teiler. Eine Cacheline sollte möglichst immer (mindestens) so groß sein wie die Granularität eines Speicherzugriffs. Und die Cachelinegröße von x86er-CPUs (P4 hatte glaube ich eine eigenartige Organisation mit 128Byte-Lines bestehend aus zwei 64Byte-Segmenten) und AMD-GPUs liegt schon seit ewigen Zeiten bei 64 Byte.

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

Ganz nur Cache kann HBM ja nicht sein, dass muss also eine Hybridlösung sein. Der Framebuffer nutzt ganz sicher stets den HBM als Speicher, während der Rest der Daten den Hauptspeicher als Speicher nutzt und den HBM nur noch als Cache.Oder man vertraut darauf, daß der Framebuffer durch die regelmäßigen Zugriffe ganz von alleine sowieso im lokalen RAM der Karte verbleiben. Aber der Treiber kann sicherlich über Spielprofile einzelne Buffer im VRAM locken, also das Auslagern per Paging unterbinden (das geht bei CPUs ja auch, ist einfach ein Bit im Pagetable-Eintrag für den Speicherbereich), falls das irgendwo mal nicht automatisch klappen sollte.
Und nein, das geht sicher nicht mit GDDR, da man für das Caching sicherlich eine deutlich niedrigere Latenz braucht als GDDR liefern kann.Nur haben GDDRx und HBM praktisch identische Latenzen, nämlich die wie jeglicher DRAM (das ist praktisch unabhängig vom Interface). ;)

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

Ich bin ja mal gespannt. Ich könnte mir auch vorstellen das Texturen jetzt komprimiert werden und dann abgelegt werden. Es gibt ja schon 4k Texturen. Nur wer schaut die sich wirklich an? In Spielen krächze ich ja nicht am Fußboden rum und bewundere den schön strukturierten Marmor in 4k.Fast alle Texturen eines Spiels eines Spielentwicklers, der etwas auf sich hält und nicht sinnlos VRAM verschleudern will, benutzen (von Spezialfällen abgesehen) eine Art der Blockkompression, was von den GPUs seit sehr langer Zeit bereits in Hardware unterstützt wird und auch standardisiert ist (BC1 bis BC7). Demnächst dürfte breiterer ASTC-Support (Adaptive Scalable Texture Compression) anstehen. Die Auflösung wird dabei übrigens nicht geändert.

[Hübie]

Das gute alte preloading von Texturen ab bestimmten Größen macht ebenfalls Sinn, da man so lange Ladezeiten beim fetchen mindert oder gar vermeidet. Wäre mal schön zu wissen welche Engine da welche Strategie benutzt, denn afaik sind alle modernen Engines Streaming Engines. In naher Zukunft sehe ich aber für Gamer noch keine Notwendigkeit eines HBC. Schaden kann es aber sicher nicht. ;)

[Complicated]

Ich denke die Notwendigkeit ist schon lange da. Wenn ich mir die Demo anschaue mit dem reduzierten VRAM auf 2 GB dann könnte sein dass man sich 8 GB komplett sparen kann mit HBCC. Wenn das so kommt und dann 4 GB völlig ausreichen, ist der HBCC sogar zu spät da. Es spart Kosten und wenn man sieht wie spät 8-Hi HBM Stacks sind, wäre der HBCC mit Fiji schön nötig gewesen.

[Hübie]

Na ja ich meinte aus der Praxis heraus. ;) Das Was-wäre-wenn-Spielchen könnten wir bis in die Unendlichkeit und noch viel weiter spielen. Ergibt nur keinen Sinn.

[Complicated]

Ist doch kein "was wäre wenn" wenn ich sage ich sehe die Notwendigkeit schon 1 Generation zuvor und nicht erst in ferner Zukunft. Und ich meine ganz konkret aus der Praxis heraus. Fiji hatte dynamischen VRAM den es bei RoTR nutzen konnte. Die nächste Iteration mit dem HBCC hätte Fiji in keinem Spiel am Speicher verhungern lassen, wie es nun in der Praxis das eine oder andere mal der Fall war. Auch würde jetzt kein Hahn mehr nach 8GB krähen - das wären konkret in der Praxis 80,- € billigere Grafikarten alleine durch 4 GB weniger HBM Speicher.

[Hübie]

Ach so, dann habe ich eine andere Vorstellung von "schon lange". Ich war da eher so bei Kepler und Tahiti. :D

[BoMbY]

Nur mal so am Rande: CCIX Tech Demo Proves 25Gbps Performance over PCIe (https://forums.xilinx.com/t5/Xcell-Daily-Blog/CCIX-Tech-Demo-Proves-25Gbps-Performance-over-PCIe/ba-p/767484)

Edit: 25 Gbps = ~3215 MB/s über PCIe x1. Das heißt mit PCIe x16 sollten ca. 50 GB/s drin sein.

[Complicated]

Huch - hör doch mit den Fakten auf ;)
Schöner Link zur Bestätigung, dass sogar die 25 Gbps über eine 16x PCIe Schnittstelle erreichbar sind. Sie reden da von dreifachem Durchsatz gegenüber PCIe 3.0 (8 Gbps bei 16x lanes an Durchsatz Vollduplex). Die 25 Gbps entsprechen 50 GB/s über 16 PCIe 3.0 lanes.

[Screemer]

Ach was. Kann doch gar nicht sein. Völlig unmöglich der Screemer ist doch ein Klugscheißer.

[Hübie]

Wer sagt so etwas? Es ist im Grunde alles eine serielle Ende-zu-Ende Übertragung mit LVDS. Wie du dein Kind nennst und am Ende einstellst ist doch ne andere Geschichte. Ob man das auf engem Raum mit so vielen Leiterbahnen nebeneinander umsetzen kann wird sich dann auch zeigen. Grundsätzlich ausschließen würde ich es ja schon mal nicht. ;)

[Eldoran]

Nur mal so am Rande: CCIX Tech Demo Proves 25Gbps Performance over PCIe (https://forums.xilinx.com/t5/Xcell-Daily-Blog/CCIX-Tech-Demo-Proves-25Gbps-Performance-over-PCIe/ba-p/767484)

Edit: 25 Gbps = ~3215 MB/s über PCIe x1. Das heißt mit PCIe x16 sollten ca. 50 GB/s drin sein.
Bitte korrigiert mich wenn ich mich irre, aber technisch gesehen beweist diese Demo nur, dass der PCIe slot Connector auch einen dreifachen Durchsatz ermöglichen könnte. Es ist auch nicht klar wie die Bandbreite vergrößert wurde. Es könnte etwa die Frequenz verdoppelt worden sein. Nebenbei bemerkt irgendwie muss auch PCIe 4.0 die Bandbreite verdoppeln - und neue Steckverbindungen sind bisher nicht angekündigt oder?
Weiters irritiert mich, dass das ganze auf Laborequipment basiert, das spricht somit eher gegen die Überlegung dass Vega zu Ryzen(Epyc) per CCIX (in der Form IF) kommunizieren kann (zumindest bei der Bandbreite wird damit wohl kaum dramatisch etwas ändern).

[Complicated]

Hier geht es um die 25 Gbps - bisher wurden lediglich 16 Gbps implementiert und das entspricht 32 GB/s bei 16x PCIe 3.0. Die 50 GB/s wurden noch nirgendwo implementiert. Das ging aus den Links hervor die ich schon gepostet habe hier im Thread. Dies war das erste Demo mit 25 Gbps. Was AMD genau implementiert hat ist noch nicht veröffentlicht worden.

[Screemer]

Wer sagt so etwas?
Du kannst die Diskussion ab hier ja mal verfolgen: https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11383758#post11383758 klevapalis ist seit dem auf meiner ignorlist und der link von Bomby zeigt auch, dass Troyan mal wieder was behauptet hat was nicht zutrifft.

[StefanV]

Es spart Kosten und wenn man sieht wie spät 8-Hi HBM Stacks sind, wäre der HBCC mit Fiji schön nötig gewesen.
Ev. ist er das ja auch, nur leider kaputt..

[G3cko]

Angenommen Vega und Ryzen können über eine IF kommunizieren. Auch dank des HBCC sollten doch beide wie eine Konsole mit Unified Speicher arbeiten können. Würde sich dies bereits positiv in Konsolenports bemerkbar machen, oder müssten die weit größer angepasst werden?

[Hübie]

Seit wann haben die neuen Konsolen zwei Speicher?

@StefanV: Eher nicht. Wo soll der Controller sitzen? Die Packdichte bei Fiji im Vergleich zu anderen ist ja nicht abnormal und für 4096 ALUs passt die Größe gut.

[Skysnake]

@Skysnake: Deswegen hatte ich ja Pages als "Cachelines" ins Spiel gebracht ;). Ist erstmal einfacher. Für Algorithmen, die halbwegs Kontrolle über ihre Zugriffe haben und z.B. mit Cacheblocking-Strategien Datenlokalität auszunutzen versuchen, sind die Pages perfekt (deutlich geringerer Overhead). Später kommt dann vielleicht mal mehr.

Ja das stimmt schon, aber so große "Cachelines" sind halt echt doof, weil damit die Gefahr von false Sharing steigt...

Wie gesagt für Graphics ist das sicherlich kein Problem, aber für Compute schon, und da meine ich nicht nur HPC, sondern auch für den normalen Zocker relevantes. Ich denke da nämlich an die Linked lists für die Haarsimulation von AMD.

Wenn man vom BestCase ausgeht, dann brüchte man für 64kB /64 Byte/Thread(DP) 64 Threads pro Wavefront. Das würde wie ich gerade sehe, sogar passen. Ist dann halt mit der Einschränkung eines Unitstride Accesses. hmmm...

Vielleicht ist das gar nicht sooo dumm/schlimm mit den 4kB Pages, wenn man einigermaßen struckturierte Daten hat.

Wos halt Probleme gibt sind Listen oder dünnbesetzte Matrizen.

hm.... Man müsste sich das mal mit einer deutlich breiteren Anzahl an Algorithmen mal anschauen, wie oft es bei GPU Codes vorkommt, das man false Sharing auf Basis von Pages macht. Das nVidia "nur" 32er Warps hat, ist das ein bischen ein Nachteil, weil es nicht aufgeht mit den 4kB pages. Man verliert also etwas von der eigentlich vorhandenen Flexibilität.

Wenn es nur nicht immer gleich so abartig viel Zeit fressen würde, sich da etwas an zu schauen -.-

Nur mal so am Rande: CCIX Tech Demo Proves 25Gbps Performance over PCIe (https://forums.xilinx.com/t5/Xcell-Daily-Blog/CCIX-Tech-Demo-Proves-25Gbps-Performance-over-PCIe/ba-p/767484)

Edit: 25 Gbps = ~3215 MB/s über PCIe x1. Das heißt mit PCIe x16 sollten ca. 50 GB/s drin sein.
Danke für den Link :up:

Huch - hör doch mit den Fakten auf ;)
Schöner Link zur Bestätigung, dass sogar die 25 Gbps über eine 16x PCIe Schnittstelle erreichbar sind. Sie reden da von dreifachem Durchsatz gegenüber PCIe 3.0 (8 Gbps bei 16x lanes an Durchsatz Vollduplex). Die 25 Gbps entsprechen 50 GB/s über 16 PCIe 3.0 lanes.
NAja, die Frage ist halt, auf welche Entfernung das funktioniert... Bei PCI-E 4.0 ist ja schon klar, das man nur die ersten Slots ohne Repeater versorgen kann, und auch keine passiven PCI-E Brücken mehr verwenden kann um den Anschluss um 90° zu drehen...

Dennoch ist es schön zu sehen, das es prinzipiell funktioniert, denn 25 vs 16 GBit sind schon nochmal was anderes. Sind halt quasi 37,5 vs 24 GHz Signale, die man treiben muss.

Ich geh auch leider erstmal stark davon aus, das man die 25GBit nur auf Serverboards erstmal sehen wird, weil man schon gescheite Boards mit vielen Layern wohl brauchen wird, damit da am Ende auch noch ein vernünftiges Signal ankommt, wenn man mehr als einen Slot unterstützen will.

[Hübie]

Und ich glaube dass du die 25 Gbps nur für FPGA/ASICs sehen wirst und dass die 4x maximal belegen können. :P

[Kriton]

Seit wann haben die neuen Konsolen zwei Speicher?

Natürlich nicht, darum ging es ihm doch gerade. Dass das in einem solchen AMD System das für das Programm auch nur noch wie ein Speicher wirkt.

[Complicated]

@Skysnake
Ein berechtigter Einwand. Das hat mich etwas recherchieren lassen und ich bin auf ein paar Details bei Cadence gestossen. Hier ist deren CCIX IP für den TSMC 7nm Prozess beschrieben:
https://ip.cadence.com/uploads/1205/cdn-dsd-int-ser-25-gbps-multi-link-and-multi-protocol-phy-ip-for-tsmc-7nm-pdf
Die 25 Gbps sind im Medium Reach mit 25db insertion loss definiert. Die 16 Gbps sind sogar für den Long Raech (entspricht GB-LAN und 100m Leitungslänge) mit 30db insertion loss definiert.

Also ist hier keinerlei Problematik oder Einschränkung zu erwarten bei den Leitungslängen innerhalb eines Systems/Boards/Chips. Bemerkenswert ist, dass Cadence CCIX integriert in einem Multi-Protokoll PHY. Also es ist automatisch mit dabei mit PCIe 1/2/3/4, SATA 1/2/3, USB 3.1 Gen1 und Gen2 und ein paar anderen Protokollen. Alle über den selben PHY konfigurierbar.
The PHY IP is designed for handling multi-protocols on one single PHY macro (see table below).
Hier auch eine Schematik des Controllers:
https://ip.cadence.com/ipportfolio/ip-portfolio-overview/interface-ip/ccix-ip/controller-ip-for-ccix
https://ip.cadence.com/uploads/images/dip-staging-wiki/CCIX-v1.0-system-block-diagram2.png

[Hübie]

Natürlich nicht, darum ging es ihm doch gerade. Dass das in einem solchen AMD System das für das Programm auch nur noch wie ein Speicher wirkt.

Die Konsole hat nur einen Speicherpool. Da musst du nix zusammen führen. Der hat auch keine unterschiedlichen Geschwindigkeiten und noch PCIE dazwischen. Schlechter Vergleich, sorry.

Edit: Oder anders gesagt: Warum sollte man bei einer Konsole wissen wo welche Daten lokal liegen? Beim PC ist es wegen der Geschwindigkeit wichtig ob etwas im HBC oder DRAM ist, aber auf Konsole eben nicht. Caches mal Außen vor. Die liegen nicht im gemeinsamen Adressraum.

@Complicated: Nice find. :up: Auf die Längen wird man dennoch immer wieder Repeater benötigen. Das hast du selbst bei 3.0 schon nötig. ;)

[Kriton]

Die Konsole hat nur einen Speicherpool. Da musst du nix zusammen führen. Der hat auch keine unterschiedlichen Geschwindigkeiten und noch PCIE dazwischen. Schlechter Vergleich, sorry.

Edit: Oder anders gesagt: Warum sollte man bei einer Konsole wissen wo welche Daten lokal liegen? Beim PC ist es wegen der Geschwindigkeit wichtig ob etwas im HBC oder DRAM ist, aber auf Konsole eben nicht. Caches mal Außen vor. Die liegen nicht im gemeinsamen Adressraum.


Die Frage zielt ja in die Richtung, ob der HBCC die Steuerung übernimmt (so dass das Programm auch nicht wissen muss wo welche Daten lokal liegen). Also ob in dem beschriebenen System aus Programmsicht nur ein gemeinsamer Gesamtspeicher vorhanden ist und damit die Portierung von Konsole einfacher/besser wird.

[Skysnake]

@Skysnake
Ein berechtigter Einwand. Das hat mich etwas recherchieren lassen und ich bin auf ein paar Details bei Cadence gestossen. Hier ist deren CCIX IP für den TSMC 7nm Prozess beschrieben:
https://ip.cadence.com/uploads/1205/cdn-dsd-int-ser-25-gbps-multi-link-and-multi-protocol-phy-ip-for-tsmc-7nm-pdf
Die 25 Gbps sind im Medium Reach mit 25db insertion loss definiert. Die 16 Gbps sind sogar für den Long Raech (entspricht GB-LAN und 100m Leitungslänge) mit 30db insertion loss definiert.

Also ist hier keinerlei Problematik oder Einschränkung zu erwarten bei den Leitungslängen innerhalb eines Systems/Boards/Chips. Bemerkenswert ist, dass Cadence CCIX integriert in einem Multi-Protokoll PHY. Also es ist automatisch mit dabei mit PCIe 1/2/3/4, SATA 1/2/3, USB 3.1 Gen1 und Gen2 und ein paar anderen Protokollen. Alle über den selben PHY konfigurierbar.

Hier auch eine Schematik des Controllers:
https://ip.cadence.com/ipportfolio/ip-portfolio-overview/interface-ip/ccix-ip/controller-ip-for-ccix
https://ip.cadence.com/uploads/images/dip-staging-wiki/CCIX-v1.0-system-block-diagram2.png
Naja, das sagt erstmal nicht viel aus. Die Insertionloss ist da definiert, und nicht, wie man diese erreicht. Am Ende kann das eben auch sein, das man Hohlleiter verwendet, oder halt im Allgemeinen Kabel, die bei solchen Frequenzen deutlich weniger loss haben als FR4.

[Hübie]

Die Frage zielt ja in die Richtung, ob der HBCC die Steuerung übernimmt (so dass das Programm auch nicht wissen muss wo welche Daten lokal liegen). Also ob in dem beschriebenen System aus Programmsicht nur ein gemeinsamer Gesamtspeicher vorhanden ist und damit die Portierung von Konsole einfacher/besser wird.

Es liegt einfach noch zu viel im Nebel, um mal ganz ehrlich zu sein. ;) Bei NV über CUDA ist es ne Softwaregeschichte wobei der Treiber da glaub ich auch nicht zwischen funkt (weiß ich jedoch nicht genau). Könnte beim HBCC allerdings eben ne Treibergeschichte werden was den Vorteil hat überall anwendbar zu sein, aber den Nachteil mit sich bringt den Entwicklern Kontrolle zu entreißen (was wiederum gegen das low-level-Prinzip spricht. Auch müssen Enduser stets auf Treiberfixes warten wenn es denn nicht oder nicht richtig funktioniert.
Daher vermute ich dass Entwickler es explizit implementieren müssen. Dann ist es eigentlich schon wieder nur ein Checklisten-Feature.

[Complicated]

Du meinst Cadenca definiert einen PHY der sowohl SATA, LAN, USB, PCIe und CCIX kombiniert nutzen kann um das dann nur per speziellem Kabel funktionieren zu lassen? Verstehe ich da etwas falsch?

[G3cko]

Die Frage zielt ja in die Richtung, ob der HBCC die Steuerung übernimmt (so dass das Programm auch nicht wissen muss wo welche Daten lokal liegen). Also ob in dem beschriebenen System aus Programmsicht nur ein gemeinsamer Gesamtspeicher vorhanden ist und damit die Portierung von Konsole einfacher/besser wird.

Genau. Mir ist schon klar, dass ein gemeinsamer Speicherpool auf welchen CPU und GPU zugreifen können das Optimum darstellt. Zwei komplett getrennte Bereiche wie bisher sind der WorstCase. IF mit HBCC sollte wohl dazwischen liegen. Wenn es denn so stimmt sehen dann ja auch GPU und CPU was die jeweils andere Partei macht. Auch wird der Grafikspeicher nahtlos auf den VRAM erweitert.

Einige KonsolenPort verhalten sich ja bereits jetzt wie man das erwarten würde.
http://techbuyersguru.com/sites/default/files/pictures/TheGamersBench/RoTRDX12/RoTR%20VRAM%20fix.jpg
http://techbuyersguru.com/sites/default/files/pictures/TheGamersBench/RoTRDX12/RoTR%20RAM%20Fix.jpg


Die Frage ist halt, profitieren die Spiele von IF + HBCC. Ich meine Abseits von VRAM-Mangel sondern in extra fps. Muss hier etwas in der Software noch angepasst werden? Ich bin leider kein Softwareentwickler um das beurteilen zu können.

Das ist ja auch das große Ziel von AMD. Ein CPU + GPU Konstrukt, welches extrem eng miteinander verzahnt ist. Egal ob das nun eine Konsole ist oder im HPC Bereich.

[Hübie]

Na was heißt speziell? Leitungsdurchmesser, Reflektion und Störanfälligkeit unterliegen eben den physikalischen Bedingungen bzw. erfordern bestimmte physikalische Größen. So verstehe ich das.

[Complicated]

Genau. Mir ist schon klar, dass ein gemeinsamer Speicherpool auf welchen CPU und GPU zugreifen können das Optimum darstellt. Zwei komplett getrennte Bereiche wie bisher sind der WorstCase. IF mit HBCC sollte wohl dazwischen liegen.
HBCC hat einen gemeinsam adressierbaren Speicher bis zu 512 TB. Da kann sogar Netzwerkspeicher eingebunden sein - wie liegt dann HBCC und IF dazwischen? Es ist die nächste Stufe von gemeinsamen adressierbarem CPU+GPU Speicher (unified memory).

Wenn du das auf Datacenter überträgst, so kann nun nicht nur der verbaute VRAM und System-RAM (DDR) direkt beschrieben und gelesen werden, sondern auch NVM sowie SSD/HDD und SAN.

Wie HBCC bei Spielen wirkt, denen der Grafikspeicher ausgeht wurde ja hier schon verlinkt. Nochmals für diejenigen die es verpasst haben:
https://www.computerbase.de/2017-02/amd-radeon-rx-vega/
Anhand des Spiels Deus Ex: Mankind Divided hat AMD die Wirksamkeit des High Bandwidth Cache Controller (HBCC) von Vega demonstriert. Mit HBCC lief die Demo deutlich flüssiger: Nach AMDs Angaben stieg bei Aktivierung von HBCC die durchschnittliche Bildrate (Average FPS) um über 50 Prozent. Die ebenso relevanten Minimum-FPS seien sogar um 100 Prozent erhöht worden. Ohne HBCC sei dem System der für die Demo 2 GByte große Speicher im regulären VRAM-Modus ausgegangen. Die Demo-Szene erfordere eigentlich 4 GByte Speicher, erklärte Koduri. Man wolle damit demonstrieren, dass dank HBCC mit nur 2 GByte Speicher eine mindestens ähnliche Leistung wie mit 4 GByte möglich wird.

[Gipsel]

@Skysnake
Ein berechtigter Einwand. Das hat mich etwas recherchieren lassen und ich bin auf ein paar Details bei Cadence gestossen. Hier ist deren CCIX IP für den TSMC 7nm Prozess beschrieben:
https://ip.cadence.com/uploads/1205/cdn-dsd-int-ser-25-gbps-multi-link-and-multi-protocol-phy-ip-for-tsmc-7nm-pdf
Die 25 Gbps sind im Medium Reach mit 25db insertion loss definiert. Die 16 Gbps sind sogar für den Long Raech (entspricht GB-LAN und 100m Leitungslänge) mit 30db insertion loss definiert.
Das vorher verlinkte 25Gbps-Demo arbeitete übrigens mit einer Dämpfung von 35dB zwischen den Chips (also Summe aus Traces auf dem Board und dem Connector, die Angabe war sogar "The total insertion loss in the demo is greater than 35dB, die pad to die pad, which allows flexibility in system design."). Die haben also offenbar nochmals bessere PHYs dafür integriert. Der dort erwähnte Punkt war, daß das sogar mit einem Großteil der existierenden Infrastruktur (die vermutlich recht hohe Dämpfung für hohe Frequenzen hat) funktionieren soll. Steckverbindungen über eine Backplane haben angeblich typischerweise 30-35db insertion loss bei den Frequenzen.

[Kriton]

Es liegt einfach noch zu viel im Nebel, um mal ganz ehrlich zu sein. ;) Bei NV über CUDA ist es ne Softwaregeschichte wobei der Treiber da glaub ich auch nicht zwischen funkt (weiß ich jedoch nicht genau). Könnte beim HBCC allerdings eben ne Treibergeschichte werden was den Vorteil hat überall anwendbar zu sein, aber den Nachteil mit sich bringt den Entwicklern Kontrolle zu entreißen (was wiederum gegen das low-level-Prinzip spricht. Auch müssen Enduser stets auf Treiberfixes warten wenn es denn nicht oder nicht richtig funktioniert.
Daher vermute ich dass Entwickler es explizit implementieren müssen. Dann ist es eigentlich schon wieder nur ein Checklisten-Feature.

Dass jedenfalls der HBCC auf HW-Ebene die entsprechenden Arbeiten vornimmt hat Raja schon bestätigt. Dafür, dass Du immer wieder sagst, dass Du keine Vendor-Präferenzen hast, suchst Du aber scheinbar bei AMD doch immer ein Haar in der Suppe.

Im Übrigen sind wir inzwischen weit weg von der ursprünglichen (noch unbeantworteten) Frage.

[StefanV]

@StefanV: Eher nicht. Wo soll der Controller sitzen? Die Packdichte bei Fiji im Vergleich zu anderen ist ja nicht abnormal und für 4096 ALUs passt die Größe gut.
Wir wissen ja nicht einmal bei VEGA, wo der Controller sitzt. Wie kannst du das bei FIJI ausschließen?
Es ist doch eben NICHT unwahrscheinlich, dass es auch bei Fiji implementiert/geplant war, aber (noch) nicht so funktioniert, wie es eigentlich sollte. Und VEGA dann quasi HBCC V2.0 bekommen hat.

ggF ist das bei Fiji nur für interne Tests aktiv...

IM Prinzip kann dieser HBCC an jeder Stelle implementiert sein. Im HBM Block, im PCIe Block, Main Chip Controller/Setup Engine.
Es macht mehr Sinn, wenn man dieses schon bei Fiji versucht hat, es aber aus diversen Gründen deaktiviert als dass man aus heiterem Himmel damit ankommt...

[Hübie]

Ja genau. Nun spielen wir wieder BIAS-Bullshit-Bingo. :rolleyes:

Das Raja so etwas gesagt hat ist mir entgangen oder ich hab's vergessen. Hast du da ein Zitat parat?
Welche Frage meinst du nun genau? Das man möglicherweise mit IF zwischen den Speichern arbeiten könnte?

@StefanV: Dann guck dir die Dieshots an. So ein Controller wäre wahrscheinlich aufgefallen. Es wäre auch unüblich so etwas fundamental Neues zu implementieren und dann nicht zu nutzen. Da geht deine Fantasie wohl etwas mit dir durch. ;)

[Skysnake]

Du meinst Cadenca definiert einen PHY der sowohl SATA, LAN, USB, PCIe und CCIX kombiniert nutzen kann um das dann nur per speziellem Kabel funktionieren zu lassen? Verstehe ich da etwas falsch?
Nein das sagt nur, das man aufgrund dieser Daten keine Aussage treffen kann, welche Distanzen man überbrücken kann. Das hängt halt von der jeweiligen Implementierung der Signalwege ab....

Nicht mehr und nicht weniger. Wobei ich 35dB loss schon ganz schön stramm finde rein vom Gefühl her, kenne mich aber ehrlich gesagt nicht damit aus, was man so typischerweise an loss hat auf den Signalwegen.

Ich würde aber sagen, das man das heutzutage auch etwa hat. Ich meine mich zumindest an Graphen zu erinnern, bei denen das so typische Größen waren. Allerdings nicht für 25GBit signale, sondern für vielleicht 5-10 GBit Signale. Darüber würde ich sagen war die Dämpfung allgemein höher.

Bei allem >2-5 GHz an Signalen wird es halt schon echt hässlich. Knapp 40 GHz sinds dann aber wirklich. FR4 ist da wie gesagt kein tolles Material mehr. Selbst mit so viel Shielding wie du willst.

[Complicated]

@Hübie
Wie kommt man auf die hirnrissige Idee HBCC sei ein Treiber oder Software-Feature?
Auch scheinst du das low-level-Prinzip nicht so richtig zu verstehen. Es bedeutet nicht, dass der Entwickler alles selber tun muss. Auch entreißt der HBCC nichts den Entwicklern. Was soll da denn entrissen werden? Das liest sich wie FUD vom feinsten.

HBCC ist der Speichercontroller des HBM -Speichers. Daher ist durchaus schon etwas davon in Fiji vorhanden und es wurde auch genutzt, z.B. bei RoTR.
Siehe: https://www.hardocp.com/article/2016/02/29/rise_tomb_raider_graphics_features_performance/13
https://images.hardocp.com/images/articles/1456505100AQVrwEp3px_13_1.gif
The AMD Radeon R9 Fury X VRAM behavior does make sense though if you look toward the dynamic VRAM. It seems the onboard dedicated VRAM was mostly pegged at or near its 4GB of capacity. Then it seems the video card is able to shift its memory load out to system RAM, by as much as almost 4GB at 4K with 4X SSAA. If you combine the dynamic VRAM plus the on board 4GB of VRAM the numbers come out to equal numbers much higher than the AMD Radeon R9 390X and closer to what the GeForce GTX 980 Ti achieved in terms of dedicated VRAM.

Der HBCC auf Vega erhält eine andere Anbindung an die Pixel Engine, was wiederum das ganze noch effektiver macht und es wird die Funktion erweitert auf NVM, SSD/HDD und SAN.
http://assets.hardwarezone.com/img/2016/11/vega_L2.jpg

Und jetzt willst du nach dem HBCC suchen auf dem Die? Du scheinst nach wie vor nicht zu begreifen dass es sich um den Memory Controller handelt. Bei dir habe ich das Gefühl, dass du nicht mal begreifst worum es da eigentlich geht.

[Screemer]

@StefanV: Dann guck dir die Dieshots an. So ein Controller wäre wahrscheinlich aufgefallen. Es wäre auch unüblich so etwas fundamental Neues zu implementieren und dann nicht zu nutzen. Da geht deine Fantasie wohl etwas mit dir durch. ;)
So wie die ganzen deaktivierten features in excavator? AMD ist da nicht geizig mit diespace. Siehe auch Tonga.

[Digidi]

Interessant. Hat Radeon Pro eigentlich auch schon so einen HBCC, oder wie wird da die SSD angebunden?

[Hübie]

"Vermute" und "könnte" sind für euch also Fremdwörter? Also echt mal. Was ist das schon wieder für eine Diskussionsgrundlage die sich hier wieder auf tut? Ist das Textverständnis so weit nach unten gerutscht, dass man nicht mal mehr konjungiv spekulieren kann?

[Screemer]

Wir sind hier im spukuthread da erübrigt sich dein "könnte" oder "vermute". Hier ist alles könnte oder vermute.

[Hübie]

Erzähl das Mr. Complicated der das gekonnt ignioriert. Ich erinne da mal an die GTX 970 die stets ohne einen dedizierten Controller unter 3,5 GB liegen will. Aber bei Fiji ist der dann drin. Genau. Auch wieso er schlussfolgert ich würde nicht begreifen worum es geht weiß ich nicht. Man stellt eine Vermutung aufgrund bekannter Lösungen an und schon bekommen einige Herrschaften Schaum vor dem Mund. :rolleyes:

Noch mal extra für Mr. Complicated: Ich vermute dass der HBCC (der in Hardware vorhanden ist) mit Software gesteuert wird. Entweder muss die App das explizit können (Edit: das wäre fatal) oder der Treiber (eleganter und flexibler als alles in Hardware, aber eben mit den genannten Nachteilen). Nun kapiert oder muss ich es noch mal ausführen? Wie kommst du auf die Idee ich sehe den nur aus Softwarebestandteilen? Was liest du eigentlich wenn du liest? :|

@Screemer: Ok das mit den Features ist ein gutes Argument. AMD kann es sich ja offenbar immer wieder leisten. X-D SCNR! Dennoch: So ein Controller würde sicher auffallen, oder meint ihr nicht? Entweder jedes PHY hat seinen eigenen HBCC oder (und das halte ich für wahrscheinlicher) der sitzt irgendwo zentral gelegen in der GPU (nein nicht die Mitte). Der Controller bräuchte Registerspace und eine Menge Leitungen (PHYs).

[Screemer]

Und mit deiner Vermutung bist du halt alleine. Warum du das nicht verstehen willst ist mir wiederum nicht klar. Es ist teil des memory controllers. Der ist für hbm eh komplett anders und bestwht nicht nur aus den phys. Was soll da auffallen?

[Complicated]

Also Hübie es ist ja ok zu spekulieren, doch zu spekulieren der Himmel sei grün wenn er eindeutig blau ist, ist keine Spekulation. Du schreibst der HBCC sei auf dem Die nicht auffindbar - was hat das mit Spekulation zu tun? Das ist FUD. Man muss doch keine Unsicherheiten hinzu dichten.

Du vermutest, dass der Speichercontroller mit Software gesteuert wird? HBCC=Speichercontroller. Was gibt es denn an der grundlegenden Funktionsweise eines Speichercontrollers zu spekulieren?
Ich spekuliere dass das ganze mit Strom funktioniert? :freak:

Welche Hardware läuft denn ohne Software? Ob das BIOS/UEFI/Treiber/Firmware oder wie auch immer heisst.

Der Cache=HBM
HBM=VRAM
Speichercontroller der GPU=HBCC

Danach kannst du suchen auf dem Die von Vega

[Hübie]

Im Grunde ist einiges vom "alten" GDDR Interface in den Baselayer gewandert, aber HBM selbst ist ja keine neue Speichertechnologie (die Zellen sind ja genau so organisiert). Also ist das PHY nicht großartig anders, wenn man es so betrachtet.

Ich kann auch damit Leben dass ich mit meiner Vermutung allein bin, das heißt nicht dass es nicht richtig ist. Massen irren sich gerne (Hitler, VW, RTL, Bild...). Kein gutes Argument. Wir werden es ja bald wissen. Ganz ohne Treiber ist halt schwer für mich zu glauben, weil man da einiges riskiert.

@Complicated: AUF FIJI IST DER NICHT AUFFINDBAR! Das war meine Antwort auf StefanV seine Vermutung dieser könnte schon in Fiji drin sein. Lies bitte alles oder frage nach, aber rede doch nicht dazwischen.

Edit: Und ob dieser grundsätzlich genutzt wird oder nicht macht doch einen Unterschied. Wenn ein Spiel da extra Codezeilen braucht ist es im Grunde nutzlos. Wenn der Treiber das lenkt ist es in so weit gut, so lang es keine schwerwiegenden Bugs gibt. Bei der 970 mussten auch User mal auf Treiber warten damit ein Spiel runder läuft (wegen der Speichergeschichte).

[Complicated]

Auf Fiji ist der Memory Controller nicht auffindbar? Dann schau doch nochmal nach. Würde gerne wissen wie der HBM dann dort angesteuert wird.
Ich habe sogar ausführliche Artikel dazu mit Bilder verlinkt um dir das zu zeigen - einfach mal anschauen anstatt ignorieren.

[Hübie]

Man sag mal bist du so schlecht im Lesen? Zeige mir mal bitte den HBCC auf Fiji. Einrahmen und Beschriften. Bitte. :rolleyes:

[Complicated]

HBCC ist der Speichercontroller des HBM -Speichers. Daher ist durchaus schon etwas davon in Fiji vorhanden und es wurde auch genutzt, z.B. bei RoTR.
Damit du direkt drauf klicken kannst und zu dem Beitrag kommst wo ich das schon mal erklärt habe!

Der Cache=HBM
HBM=VRAM
Speichercontroller der GPU=HBCC
Nur nochmal zum kapieren!

[Screemer]

Noch mal für dich hübie: ER KÖNNTE TEIL DES IMC SEIN! Vielleicht nur Teile oder eine einfachere Implementierung, oder,oder, oder.

Du wirfst laufend anderen fehlendes leseverständniss vor. Komisch.

[Hübie]

Mit ie. Wie oft denn noch? Complicated schreibt nicht könnte. Da steht "ist". Und ja natürlich ist der HBM-IMC Teil des HBCC. Was soll denn das nun für ne Aussage sein? :| Darum geht es doch nun gar nicht. Aber danke Complicated für diese tolel Aufklärung der Dinge die schon bekannt sind. :uclap:

Noch mal Wort für Wort: Ich stelle die Frage wie das Feature, für theoretisch 150 TB unified memory, nutzbar gemacht wird. Da gibt es zwei grundlegende Möglichkeiten bzw. noch die Dritte. Bei CUDA nutzt man es per Software, muss also explizit von der App angesprochen werden. Beim HBC könnte man es per Treiber ansprechen. Es ginge sogar ohne Treiber und nur per Firmware (im weiten Sinne ist das auch Software, aber gängig ist es nicht eine Firmware als Software zu bezeichnen :rolleyes:).
Die Lösung für welche man sich bei AMD entscheidet ist wichtig für den Nutzen und letzten Endes auch für Produktivität und Zukunftstauglichkeit. Wer das nun nicht verstanden hat: EOD!

Eine andere Frage ist auch wie man zwischen den Speicherpools unterscheidet (z.B. durch tagging und counter für priorities).

[vinacis_vivids]

Man sag mal bist du so schlecht im Lesen? Zeige mir mal bitte den HBCC auf Fiji. Einrahmen und Beschriften. Bitte. :rolleyes:
:freak:

HBCC ist eine Neuentwicklung, die jetzt mit Vega eingeführt werden wird.
Bei Fiji ist das eine Vorstufe davon und heißt einfach MC=Memory Controler, welcher mit HBM angebunden wurde.

[Hübie]

Really? You don't say! :eek: Hast du die Diskussion überhaupt verfolgt? Nein? Dann bitte ich darum es nachzuholen.

[Screemer]

Mir kommt es so vor als hättest du die Beiträge von gipsel und skysnake vor einigen seiten auch nicht gelesen. Solltest du vielleicht nachholen.

[Hübie]

Welche genau (Nummer reicht mir) und inwiefern widerspricht sich da etwas mit meinen Vermutungen? :| Kann durchaus sein, dass ein Beitrag nach einem Seitenumbruch mal nicht gelesen wird, ja.
Kannst auch gerne mal Argumente bringen wie du so einen Controller ansprechen würdest und wo du Vor- und Nachteile der einzelnen Methoden siehst. Oder ist das sogar schon bekannt wie es genau gelöst ist?

[Complicated]

HBCC ist eine Umbenennung des MC, weil er nun weitere Funktionen in der von Grund auf neu gestalteten Speicher/Cache-Struktur bekommen hat. AMDs Speicherverwaltung ist in Hardware und benötigt keine Anpassung der Software, was daran zu erkennen ist, dass man das Hardware-Feature bei der Demo mit Deus Ex ein- und ausgeschaltet hat. Es wurden weder ein angepasstes Spiel, noch ein anderer Treiber verwendet. Aus diesem Grund ist dies
Bei CUDA nutzt man es per Software, muss also explizit von der App angesprochen werden. Schon nur dann wert zu spekulieren wenn wir einfach mal ignorieren was AMD demonstriert hat. Ebenso wie dies:Beim HBC könnte man es per Treiber ansprechen.
Da es KEINE Speicherpools gibt, sondern lediglich verschiedenen Cache-Ebenen ist auch diese Frage unsinnig weil einfach nicht zutreffend:

Eine andere Frage ist auch wie man zwischen den Speicherpools unterscheidet (z.B. durch tagging und counter für priorities).

Eine Diskussion ist das schon lange nicht mehr ^^ Dazu müsstest du verstehen was dir hier mehrere Leute versuchen zu erläutern. Dass du es nicht verstanden hast ergibt sich aus deinen Fragen/Spekulationen.

https://www.pcper.com/reviews/Graphics-Cards/AMD-Vega-GPU-Architecture-Preview-Redesigned-Memory-Architecture
Vega 10 will feature a HBM2 based high bandwidth cache (HBC) along with a new memory hierarchy to call it into play. This HBC will be a collection of memory on the GPU package just like we saw on Fiji with the first HBM implementation and will be measured in gigabytes.

[Hübie]

Dann erkläre es doch :P

Die Software muss wissen in welchem Cache das liegt. Ob du es nun memory pool oder cache level nennst ist mal zweitrangig. Wenn du jede Cache-Stufe abklapperst und erst in der letzten kein miss sondern deinen hit hast, dauert das vermutlich ne ganze Weile. Also wie ist es gelöst? Hau raus!

[vinacis_vivids]

Really? You don't say! :eek: Hast du die Diskussion überhaupt verfolgt? Nein? Dann bitte ich darum es nachzuholen.

Der HBCC (hardwareseitig) von Vega kann mehr ansteuern, ist flexibler und besser skalierbar. Weiß nicht was es da zu diskutieren gibt.

[Complicated]

Dann erkläre es doch :P

Die Software muss wissen in welchem Cache das liegt.
Nein muss sie nicht - verstehe es endlich. Oder sagt die Software einer CPU in wessen L2-Cache die Daten liegen? Schau dir Intels Architektur mit LLC (Last Level Cache) an.
Ob du es nun memory pool oder cache level nennst ist mal zweitrangig.
Ist es nicht weil es zwei völlig andere Dinge sind - daher wird wohl auch dein Unverständnis kommen.
Den Unterschied siehst du in der Praxis beim Problem der GTX 970, wo zwei Memory Pools (3,5+0,5) genutzt wurden und der Switch zu Performance Einbrüchen führte, weil dies Cache-flushes bedingte. Cache-Kohärente Speicher sind etwas anderes.

Ich empfehle diesen Link zu CCIX zur Verständnis des grundlegenden Aufbaus:
https://www.nextplatform.com/2016/07/13/drilling-ccix-coherence-standard/
Und diesen 2. Teil zum Verständnis warum das was AMD macht so wichtig und anders ist:
https://www.nextplatform.com/2016/07/14/weaving-accelerators-memory-complex/
Die Bilder sind animiert, bitte drauf klicken, es erleichtert das geschriebene dort zu verstehen.

[Eldoran]

Es ist klar, ganz ohne Software/Treiber Interaktion kann es nicht funktionieren. Zuerst muss zumindest einmal definiert/freigegeben werden, welcher Speicher benutzt werden darf. Und gerade Network Storage ist ohne Setup wohl kaum nutzbar - teilweise ist das auch nur hardware unterstützt implementiert, braucht also ebenfalls einen Treiber.
Aber ab diesem Punkt sollte der Zugriff auf den Speicher weitgehend in der GPU ablaufen. Etwa mit DMA (bei crossfire schon seit Jahren im Einsatz). Der HBCC wird eben ein Embedded System sein. Programmierbar muss das Ding ja ohnehin sein.
Lange kann es aber nicht mehr dauern bis die Details bekannt werden.

[Hübie]

Ein Cache benötigt genau so Adressen wie DRAM, Flash usw. also sind es memory pools.

Aber stimmt dem Spiel (oder wem auch immer) sollte es egal sein wo Daten liegen. Nur der Controller sollte das schon wissen um rechtzeitig zu prefetchen; wie regelt man das?

[vinacis_vivids]

Ein Cache benötigt genau so Adressen wie DRAM, Flash usw. also sind es memory pools.

Aber stimmt dem Spiel (oder wem auch immer) sollte es egal sein wo Daten liegen. Nur der Controller sollte das schon wissen um rechtzeitig zu prefetchen; wie regelt man das?

async-compute

[Skysnake]

Register haben Namen bzw Adressen, aber nicht Caches. Die sind transparent für sie Software.

Wenn überhaupt gibt ex nur spezielle Befehle um Prefetching in bestimmte cache Stufen zu machen oder halt Streaming stores/loads um sich die Caches nicht zu trashen. Das muss es aber NICHT geben

[Complicated]

Ein Cache benötigt genau so Adressen wie DRAM, Flash usw. also sind es memory pools.
Nein das ist einfach falsch memory pools bezeichnet etwas anderes. Du verwirrst dich nur selber damit dass du auf die falschen Bezeichnungen bestehst. Ich finde es schade dass du die Links nicht liest wo das erklärt wird - du hast danach gefragt, ich habe geliefert. Nun wäre es an der Zeit diesem Thread zuliebe diese Dinge zu lesen. Ansonsten sehe ich kein wirkliches Interesse bei dir außer FUD zu streuen.
Es ist klar, ganz ohne Software/Treiber Interaktion kann es nicht funktionieren. Doch genau das tut es mit CCIX:
Zitat aus dem verlinkten Artikel:
Completely unbeknownst to the application doing the data store, the hardware finds the current version of the data. This is part of keeping the cache coherent. The cache controller wanting the data may well need to ask every other cache and DRAM in the system “Who has the current version of the real-addressed data block that I’m looking for?”

async-compute
Nein - das ist etwas völlig anderes und geschieht auf anderer Ebene

[Hübie]

Und wie willst du das bei theoretischen 512 TB ohne Adressierung lösen? Versteh ich nicht. :confused: Sorry vielleicht steh ich da echt auf dem Schlauch aber mich dann für blöd verkaufen ist sicher nicht zielführend. Man kann es ja gerne erklären. ;)

Edit: Ok complicated. Werds mir noch mal durchlesen.

[Eldoran]

Nein muss sie nicht - verstehe es endlich. Oder sagt die Software einer CPU in wessen L2-Cache die Daten liegen? Schau dir Intels Architektur mit LLC (Last Level Cache) an.

Ist es nicht weil es zwei völlig andere Dinge sind - daher wird wohl auch dein Unverständnis kommen.
Genau. Aus Sicht der CPU/Programme ist der Cache weitgehend unsichtbar, nur jeder Zugriff auf das RAM wird hoffentlich schon im Cache abgehandelt, weil es einfach viel schneller ist. Siehe auch Wikipedia... (https://de.wikipedia.org/wiki/Cache)
Bei Vega wird vermutlich nicht automatisch der gesamte Virtual Memory Space freigegeben sein, schließlich muss es ja auch irgendwo einen Speicher geben, wo in letzter Konsequenz die Daten auch gespeichert sind (sofern nicht gerade auch im Cache). Allerdings ist wird eben der gesamte so freigegebene Speicher (!= HBM2) so verwendet als wäre es der VRAM der GPU. Die eigentlichen Zugriffe wiederum werden soweit möglich im Cache abgehandelt.

[Gipsel]

Und wie willst du das bei theoretischen 150 TB ohne Adressierung lösen? Versteh ich nicht. :confused:Schau Dir einfach an, wie Speicherzugriffe mit virtuellen Adressen (wo es für die Adresstranslation spezialisierte TLB-Caches gibt) und Caches mit ihren Tags funktionieren.
Caches z.B. haben Tags, in denen (unter anderem) vermerkt wird, welche Speicheradresse in einer Cacheline jetzt gerade gecached wird. Bei einem Speicherzugriff (das Programm sieht nur einen Speicher, die Caches sind wie schon von anderen gesagt transparent) überprüft die Hardware im Cachecontroller, ob die angeforderte Speicheradresse im Cache steht oder nicht und liefert dann entweder die Daten aus dem Cache oder leitet das an den Speichercontroller weiter.
Im Falle eines virtuellen Speichers übernimmt die Seitentabelle (Pagetable) ganz grob (um mal die prinzipielle Gemeinsamkeit herauszustreichen) die Funktion der Tags (wobei die Pagetables zwar durch das OS erstellt werden [Treiber bei GPUs], dieses aber im normalen Betrieb nur bei Page-Faults [also wenn eine Adresse nicht gemappt ist] eingreifen muß). Auch dort ist vermerkt, auf welche physische Adresse (Speicherstelle) eine bestimmte virtuelle Adresse gemappt ist (natürlich nicht für jede einzelne sondern in Blöcken). Auch hier wird die Adresse bei einem Speicherzugriff in Hardware in die entsprechende physische Adresse umgesetzt. Dies kann bei einem gemeinsamen virtuellen Speicher zwischen CPU und GPU auch dazu führen, daß die Speicheranforderung über PCIe weitergeleitet werden muß. Und dies erledigt eben der HBCC ohne Softwareinteraktion.

Wie schon mal geschrieben, Controller werden konfiguriert und steuern dann den Ablauf, sie werden nicht gesteuert. Sonst wären es ja keine Controller. ;)

[Hübie]

Hm, ja stimmt konfiguriert nicht gesteuert. Ich sehe da gerade aber keinen Vorteil wenn der angeforderte Datensatz noch auf der SSD liegt und nicht mal im DRAM oder gar VRAM. Dazu braucht man doch einen cleveren Algorithmus um die Daten schon mal vorzuladen. Danke jedenfalls für die Erklärung und jetzt wo ich es lese, frage ich mich warum ich die pagetables gar nicht in betracht gezogen habe. Wo würde diese in dem Fall eigentlich angelegt werden? Im "VRAM" (HBC) oder DRAM?

[Gipsel]

Hm, ja stimmt konfiguriert nicht gesteuert. Ich sehe da gerade aber keinen Vorteil wenn der angeforderte Datensatz noch auf der SSD liegt und nicht mal im DRAM oder gar VRAM. Dazu braucht man doch einen cleveren Algorithmus um die Daten schon mal vorzuladen.Erstmal geht es für Spiele um Sachen, die im Systemspeicher liegen. Und da geht es direkt von der GPU zur CPU und von deren Speicher wieder zur GPU, ohne daß Software eingreifen muß.
Liegt irgendwas noch auf der Festplatte (in einem memory mapped file, wohl nur für Profi-Anwendungen relevant), löst ein Zugriff einen Page Fault (Interrupt) auf CPU-Seite aus und das OS liest es von der Platte (mit allen Prefetch-Kinkerlitzchen, die das OS integriert hat). Der Vorteil ist einfach, daß sich der Programmierer nicht drum kümmern muß und man Alles lesen kann, auf das das OS zugreifen kann (also auch irgendwelche NAS-Systeme oder weiß der Teufel was, solange das nur in den Adressraum eingeblendet ist).
Danke jedenfalls für die Erklärung und jetzt wo ich es lese, frage ich mich warum ich die pagetables gar nicht in betracht gezogen habe. Wo würde diese in dem Fall eigentlich angelegt werden? Im "VRAM" (HBC) oder DRAM?Die der GPU natürlich im VRAM, die der CPU im Systemspeicher der CPU.

[StefanV]

So ein Controller wäre wahrscheinlich aufgefallen. Es wäre auch unüblich so etwas fundamental Neues zu implementieren und dann nicht zu nutzen. Da geht deine Fantasie wohl etwas mit dir durch. ;)
Also hübie, damit etwas auffällt, muss man erst mal wissen, wonach man sucht. Weißt DU, wie ein HBCC auf 'nem TSMC 28nm Prozess ausschaut? Weißt DU, wie das auf einem GF/Samsung 14nm Prozess ausschaut?

Ohne zu wissen, wonach man suchen muss, ist es einfach völlig bescheuert zu behaupten, dass das ganze auf 'nem DIE Shot nicht zu erkennen wäre. Denn, wie gesagt, müsste man dazu erst mal wissen, wonach man suchen muss! Und man muss wissen, WO (=in welchem Bereich) man suchen muss.

Und ich bin mir ziemlich sicher, dass NIEMAND außerhalb von AMD weiß, wie so ein HBCC auf 'nem DIE ausschaut.

Und warum sollte man den HBCC, so denn er auf Fiji vorhanden ist, nicht nutzen? Na, weil der nicht so funktioniert wie er sollte zum Beispiel...
Schon mal von MSAA auf der Radeon 8500 (R200) gehört? Mit rotated Grid natürlich...
Anandtech hat dazu sogar 'nen relativ umfangreichen Artikel...
Nutzbar war das ganze dann mit R300...

Und bei VEGA hat man das dann halt gefixt/verbessert und ist auch noch auf die Idee gekommen, das zu bewerben. Auch wenn Fiji das hatte...

[Complicated]

Und wie willst du das bei theoretischen 512 TB ohne Adressierung lösen? Versteh ich nicht. :confused: Sorry vielleicht steh ich da echt auf dem Schlauch aber mich dann für blöd verkaufen ist sicher nicht zielführend. Man kann es ja gerne erklären. ;)

Edit: Ok complicated. Werds mir noch mal durchlesen.
Zu keiner Zeit habe ich versucht dich für blöd zu erklären, die Materie ist alles andere als einfach und man verrennt sich leicht, vor allem wenn die nächste Entwicklung da wieder Änderungen einführt. Ich freue mich, dass du dich entschlossen hast den verlinkten Quellen mehr Beachtung zu schenken. :up:

[Hübie]

Also ich habe mir computerbase und anandtech jetzt noch mal durchgelesen, aber so richtig klar ist es mir dennoch nicht. :redface: Gipsel hat mit seinem letzten Beitrag aber gut weiter geholfen. Deine Art zu Schreiben ist halt nicht immer sehr umgänglich und dann sperrt man sich für gewöhnlich da es ja keine hirnrissige Idee ist sondern vielleicht einfach falsches Verständnis einer Sache oder ein Missverständnis. ;)
Nun gut ich komme nun mehr dahinter dass es wohl keine Anpassungen der App benötigt um vom HBC profitieren zu können, weil mir das Funktionsprinzip nun klarer ist.

[Complicated]

Ich empfehle dir die beiden Links zu CCIX die ich hier wenige Beiträge zuvor gepostet habe. Die Wortwahl mit "hirnrissig" ist irgendwann einfach die Konsequenz wenn dutzende Beiträge zuvor einfach ignoriert werden, und das nicht nur meine. Weder Anand noch Computerbase sind in der Materie tief genug gegangen in ihren Artikeln. Gipsel hat nichts anderes geschrieben, nur deine Bereitschaft sich darauf einzulassen war deutlich höher bei ihm - ist ja auch ok, doch deine Art dagegen zu schreiben ohne auf Quellen einzugehen ist nicht förderlich für einen sinnvollen Austausch. ;)

[Hasenpfote]

Eindeutiges Sender-Empfänger-Problem zwischen allen Beteiligten :D
Daher kommt mal alle ein bisschen runter und formuliert Eure Sätze ein bisschen leichter verständlich(da freuen sich auch Hardware-Laien wie ich).

Ansonsten Danke für die umfangreichen Erläuterungen auf den letzten Seiten.
Wenn man als unbeteiligter Mitleser den Bullshit rausfiltert, war es wirklich interessant.
Rein theoretisch sollte Vega somit auf der speicherhungrigen professionellen Seite (wie auf'm Analyst Day vorgestellt) wirklich interessant sein. Ich hoffe, dass die kleine Vega für Normalsterbliche bezahlbar bleibt (~400Euro).

Hat eigentlich jemand noch was davon gehört, dass Vega virtualisierbar sein soll? Also mehrere Guests die Karte parallel nutzen können? Ich hatte nur gelesen, dass so'ne Online-Streaming-Klitsche Vega diesbezüglich testet.

[Eldoran]

An sich könnte der HBCC von der HPC-APU (Greenland?) stammen. Entsprechende Patente (https://www.google.com/patents/US20130138892) gibt es schon lange genug. Mir ist nur nicht ganz klar, warum das nicht schon in Fiji steckte.

[Eldoran]

Hat eigentlich jemand noch was davon gehört, dass Vega virtualisierbar sein soll? Also mehrere Guests die Karte parallel nutzen können? Ich hatte nur gelesen, dass so'ne Online-Streaming-Klitsche Vega diesbezüglich testet.
Ja, laut semiaccurate (http://semiaccurate.com/2017/01/17/amd-talks-vega-high-level/) definitiv möglich. Wobei das wohl schon seit Tonga (http://semiaccurate.com/2016/05/25/amds-firepro-s7100x-hardware-virtualized/) möglich ist.

[StefanV]

Eindeutiges Sender-Empfänger-Problem zwischen allen Beteiligten :D
Nein, hier wird einfach von dem, was nVidia macht auf die Welt geschlossen und dabei nicht bedacht, dass es auch noch andere/bessere Lösungen gibt.

Und genau davon muss man mal runter kommen, denn es gibt immer viele Möglichkeiten etwas zu realisieren, nie aber eine Perfekte. Der eine mag eher eine Software Lösung, der andere die Hardware.

Ein weiterer Punkt ist, dass AMD auch noch in anderen Bereichen aktiv ist, in denen nVidia mal überhaupt keine Dinge anzubieten hat...
Und genau das ist doch der Knackpunkt. AMD hat sehr umfangreichendes Wissen darüber, wie eine x86 CPU mit Speicher umgeht und auch, wie man von außen darauf zugreifen kann. Und genau dieses Wissen kann man sich in diesem Punkt zu Nutze machen...

UND jetzt behaupte ich mal, dass AMD schon lange an einem 'HBCC' gearbeitet hat, das aber bei bisherigen, GDDR5, Karten keinen Sinn machte und daher deaktiviert ist. Und dass das NICHT im Speichercontroller sitzt!
Sondern in der IOMMU, die ja AMD eh seit einiger Zeit in den GPUs verbaut haben soll...

[Complicated]

Das ist richtig. Die IOMMU ist der zentrale Kern in AMDs Speicherverwaltung für hUMA bei APUs, allerdings gab es bisher auf GPUs keine IOMMU Einheit. Möglich, dass dies oder Elemente davon in den HBCC gewandert ist. Allerdings war IOMMU involviert bei der klassischen I/O-Anbindung welche durch CCIX eigentlich ersetzt wird. Bei Carrizo war IOMMU noch das dritte Element in Verbindung mit dem GPU-Speicherkontroller und dem CPU-Speichercontroller. Siehe Bild:

http://www.notebookcheck.com/fileadmin/_processed_/csm_carrizo_hsa_features_d6eff11ebd.jpg

Interessant hier die separate "ATC"-Kommunikation um die Cache-Kohärenz zu gewährleisten.
Mittlerweile gibt es IOMMU in der dritten Version - das Update war gerade im Dezember 2016. Hier der Link zum Whitepaper falls jemand mal rein schauen will: http://support.amd.com/TechDocs/48882_IOMMU.pdf

Allerdings glaube ich, dass nur Teile davon im HBCC enthalten sind, da dieser CCIX und GenZ Merkmale aufweist, welche IOMMU nicht bieten konnte. Das sind z.B die direkten memory read/writes auf SSD/HDD/SAN. In den beiden Links zu CCIX die ich schon gepostet habe ist auch dieser Unterschied zu finden in den animierten Grafiken. Dort wird der Bereich der hier bei AMD IOMMU und "ATC" genannt wird als "SMP" betitelt, weil die Beispiele mit symetrischen Multi-prozessoren ausgeführt sind. ATC ist im Prinzip die fabric, welche in einer APU die Cache-Cohärenz herstellt.

Edit:
Ich habe auch den Abschnitt im neuen Paper gefunden der die Implementierung mit Hypertransport betrifft. Ich zitiere es mal hier. Vielleicht kann jemand versiertes dies erläutern:
4.3 Issues Specific to the HyperTransport™ Architecture
This section discusses implementation considerations that are specific to IOMMUs attached to a HyperTransport link. The HyperTransport specification requires devices (especially tunnels and bridges) to interoperate with other devices in ways that ensure correctness and maintain performance. Among other require-ments, HyperTransport devices must make certain transaction ordering guarantees and must ensure they operate without deadlocks.

A key requirement in the HyperTransport specification is that posted requests must be able to pass non-posted requests. The introduction of the IOMMU, however, means that posted requests (e.g. writes to memory) may spawn non-posted requests (I/O page table walks) that must complete before the posted request can be allowed to progress further.
To avoid deadlocks, the IOMMU requires a dedicated virtual channel for its I/O page table walk requests.

This ensures that, the IOMMU’s page table walks on behalf of posted requests can complete, regardless of the completion status of other non-posted traffic in the fabric. The IOMMU also requires that the host bridge process its requests without spawning any requests to other devices. In other words, the IOMMU’s table structures must be located solely in system memory. The IOMMU can share its virtual channel with other traffic as long the other traffic is also guaranteed to make forward progress. In practice, this means that any other devices sharing the IOMMU’s page walk channel must also restrict their non-posted traffic solely to accessing system memory. To allow the IOMMU to support different AMD processors with different isochronous capabilities the IOMMU control registers contain bits that control the state of the PassPW bits, the coherent bit and the isochronous bit in the HyperTransport™ link read request issued by the IOMMU
Ich denke das von mir Fett markierte spricht dagegen, dass IOMMU auf GPUs vorhanden ist. Allerdings kann das wie gesagt jemand anderes vielleicht besser einschätzen.

[Hasenpfote]

Ja, laut semiaccurate (http://semiaccurate.com/2017/01/17/amd-talks-vega-high-level/) definitiv möglich. Wobei das wohl schon seit Tonga (http://semiaccurate.com/2016/05/25/amds-firepro-s7100x-hardware-virtualized/) möglich ist.Aus der Zeit habe ich auch noch Artikel im Hinterkopf. Aber aktuellere Infos habe ich nicht gelesen. Konkret meinte ich auch Virtualisierung für Consumer-Karten. Ich hatte gehofft, dass AMD das mit Vega auch für normale Kunden bringt (und mit den aktuellen Patches für den Linux-Kernel Hoffnung gehabt). Na mal sehen...

[Complicated]

Ich glaube das was du meinst nennt AMD MxGPU. Und ich glaube nicht, dass dies für Consumer Karten kommen wird. Siehe: http://www.amd.com/en-us/press-releases/Pages/amd-reveals-worlds-2016feb01.aspx
FirPros unterstützen es und der Linux-Kernel 4.11 seit April: https://www.heise.de/newsticker/meldung/Linux-4-11-bringt-GPU-Virtualisierungstechnik-von-AMD-3683873.html

https://www.heise.de/newsticker/meldung/Rechenkarten-von-AMD-Radeon-Instinct-MI6-MI8-und-MI25-mit-Vega-GPU-3568504.html
Alle Radeon-Instinct-Karten sollen sich für die Hardware-Virtualisierung eignen. Auf einer Karte können jeweils mehrere Sessions laufen, jede mit eigenem Speicherbereich. Die von AMD als "Multiuser GPU" ("MxGPU") bezeichnete Technik verwendet den PCI-Express-Standard SR-IOV (Single Root I/O Virtualization).
Gilt für MI6, MI8 und MI25. Das sind Fiji, Polaris und Vega.

[Eldoran]

Ich glaube das was du meinst nennt AMD MxGPU. Und ich glaube nicht, dass dies für Consumer Karten kommen wird.
An sich ist das tendenziell eher ein Professional Feature - also eher selten auf Consumer Hardware relevant. Erst jetzt bringt AMD langsam diese Funktionen beim Linux Treiber ein. Allerdings besteht laut Heise Hoffnung:
https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-11-3641334.html#gpuamd
AMD überstellt Teile der GPU mit Hilfe von SR-IOV (Single-root Input/Output Virtualization), das derzeit nur einige der professionellen AMD-Grafikkarten der FirePro-Reihe bieten; Mainstream-Grafikkarten sollen die Funktion aber auch bald erhalten.

[Eldoran]

Complicated: an sich findet sich eine IOMMU tendenziell in der CPU bzw. Northbridge. Allerdings ob Vega eine IOMMU hat, kann ich nicht beantworten SR-IOV, XDMA und der HBC legen es nahe, andererseits passt das ganze konzeptuell nicht so recht. Der HBCC arbeitet eher wie ein klassischer Cache Controller, weniger wie Virtual Memory mit TLB.
Meinem Gefühl nach sind das Details bei denen nicht ganz klar ist, wie diese bei Vega grundsätzlich funktionieren sollen => wie funktioniert XDMA/Crossfire, wenn es konzeptuell kein VRAM gibt?

[Hasenpfote]

Ich glaube das was du meinst nennt AMD MxGPU.Genau das meinte ich. Zugegeben, das dürfte schwerig im Consumer-Geschäft zu bewerben/verkaufen sein. Und im 4.11-Kernel wurden auch nur die ersten Arbeiten diesbezüglich umgesetzt. Aber ok, dann gab es da nicht viel Neues. Danke an alle.

[Brillus]

An sich ist das tendenziell eher ein Professional Feature - also eher selten auf Consumer Hardware relevant. Erst jetzt bringt AMD langsam diese Funktionen beim Linux Treiber ein. Allerdings besteht laut Heise Hoffnung:
https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-11-3641334.html#gpuamd
Das wäre für mich DAS killerfeature weit vor FreeSync, linux normal und zum spielen Win10 in der vm mit voller 3D unterstützung.

[Eldoran]

Das wäre für mich DAS killerfeature weit vor FreeSync, linux normal und zum spielen Win10 in der vm mit voller 3D unterstützung.
Erfahrungsgemäß dürfte es noch ein paar Kernel Versionen brauchen, bis das einsatzbereit ist. Und wie performant das dann anfangs ist, ist die nächste Frage. Zumindest für diesen Zweck.
Ich finde das extrem interessant - ich nutze seit Jahren fast ausschließlich Linux und habe oft als Testsystem VMs (KVM) laufen. Ich hoffe also, dass das möglichst bald einsatzbereit ist, nur meine Erfahrung rät zu eher vorsichtigen Prognosen...

[mboeller]

mal eine dumme Idee.

Eine 64bit NEON Einheit im A55 kann entweder 8 8bit INT, 4 16bit INT, 2 32bit FP oder 1 64bit FP durchführen. Siehe Anandtech-Artikel: http://www.anandtech.com/show/11441/dynamiq-and-arms-new-cpus-cortex-a75-a55/4


Each SIMD NEON pipe in the A53/A55 can perform 8 8-bit integer, 4 16-bit integer, 2 32-bit integer or single-precision floating-point (FP), or 1 64-bit integer or double-precision FP operations per cycle


Warum wird das nicht auch so zB. beim VEGA implementiert? Das wären dann ja 50 TPOS für Machine Learning.

Wo ist der Haken?

[Complicated]

Das sind CPU FPU-SIMD und keine GPU Einheiten die dort bei Anand besprochen werden. Das können ja AMD und Intel ebenfalls mit ihren SIMD Instruktionen SSE bis AVX.

[Brillus]

Erfahrungsgemäß dürfte es noch ein paar Kernel Versionen brauchen, bis das einsatzbereit ist. Und wie performant das dann anfangs ist, ist die nächste Frage. Zumindest für diesen Zweck.
Ich finde das extrem interessant - ich nutze seit Jahren fast ausschließlich Linux und habe oft als Testsystem VMs (KVM) laufen. Ich hoffe also, dass das möglichst bald einsatzbereit ist, nur meine Erfahrung rät zu eher vorsichtigen Prognosen...

Mein nächster Kauf ist sowieso für end des Jahres geplant, dann sollte man zumindest wissen ob es enthalten ist. Aktuell bin ich nich auf Win7 und da kann man den updatelock umgehen, also echt interessant wäre das Feature so ob 2019.(Meine hardware Käufe sind so 2-3 Jahres zyklus also würde mein nächster Kauf bis übers Win7 supportende halten müssen.

[Troyan]

mal eine dumme Idee.

Eine 64bit NEON Einheit im A55 kann entweder 8 8bit INT, 4 16bit INT, 2 32bit FP oder 1 64bit FP durchführen. Siehe Anandtech-Artikel: http://www.anandtech.com/show/11441/dynamiq-and-arms-new-cpus-cortex-a75-a55/4



Warum wird das nicht auch so zB. beim VEGA implementiert? Das wären dann ja 50 TPOS für Machine Learning.

Wo ist der Haken?

Ist doch auch so. Es sind 25TFLOPs mit FP16 oder 50TOPS mit INT8.

[Eldoran]

Mein nächster Kauf ist sowieso für end des Jahres geplant, dann sollte man zumindest wissen ob es enthalten ist. Aktuell bin ich nich auf Win7 und da kann man den updatelock umgehen, also echt interessant wäre das Feature so ob 2019.(Meine hardware Käufe sind so 2-3 Jahres zyklus also würde mein nächster Kauf bis übers Win7 supportende halten müssen.
Ich warte auch gerade auf meinen nächsten Hardware Kauf... Wie gesagt, laut heise soll Vega das Feature prinzipiell freigeschaltet bekommen (so weit plausibel bei AMD - ich hab auch Jahrelang KVM auf einem popeligen E-350 genutzt...). Auch dass das unter Linux allgemein verfügbar wird, halte ich für wahrscheinlich. Es dürfte wenn dem so ist vermutlich zum Launch oder bald danach angekündigt werden. Ich mache mir nur etwas Sorgen um den Termin der praktischen Einsatzfähigkeit. Die Technologie ist aber nicht mehr ganz neu, das erhöht die Chancen.

[Isen]

Webcast für Computex
Für uns, am 31.05 um 04:00 Uhr:
https://www.amd.com/en/events/computex-2017

The one-hour event will feature:
Appearances by AMD technology partners,
Updates on current and upcoming AMD products by AMD President and CEO Dr. Lisa Su and Senior Vice President and General Manager, Computing and Graphics Business Group, Jim Anderson,
And never-before-seen AMD hardware demonstrations

[5CH4CHT3L]

Webcast für Computex
Für uns, am 31.05 um 04:00 Uhr:
https://www.amd.com/en/events/computex-2017
Immer diese Zeitverschiebung :/

[mboeller]

Ist doch auch so. Es sind 25TFLOPs mit FP16 oder 50TOPS mit INT8.

ist wohl an mir vorbei gegangen... :(

[AlphaNUSS]

Kein Raja auf der Computex? Ich hoffe mal wir bekommen trotzdem einiges zu sehen.

[Eldoran]

Kein Raja auf der Computex? Ich hoffe mal wir bekommen trotzdem einiges zu sehen.
Ja, die angekündigten Sprecher sind wohl reines Management. Das Ziel auf der Computex dürfte aber auch weniger ein Launch einer Hardware als eben die Ankündigung bzw. Teaser. Also eher die Verkaufsseite des ganzen (was ja auch der Zweck von Messen ist). Andererseits sind auch diverse Demos angekündigt - demnach sind wohl unter anderem Benchmarks bzw. Demonstrationen, die bestimmte Aspekte zeigen zu erwarten.
Ich denke wir bekommen zumindest mehr Daten um unsere Schätzungen zu verbessern.

[vinacis_vivids]

Gibs schon irgendwelche Demo-Leaks?

[PrivateCeralion]

Wer ist alles um 4:00 wach und guckt den Stream?

[horn 12]

ICH ;-)

[PrivateCeralion]

ICH ;-)

Yeah, ich bin nicht alleine :D hoffentlich wissen wir in einer halben Stunde alles über Vega ;)

[horn 12]

Nun, da kann ich nicht die Hand ins Feuer legen.
Hoffe doch sehr, aber glauben tu ich schon lange nicht mehr :-)

[horn 12]

Hoffe nun versagt AMD nicht ----> 04:49 wird über Vega geredet!

[iuno]

27. Juni fuer die FE

RX Vega zur Siggraph (laeuft 30. Juli bis 3. August)

[Linmoum]

RX Vega Launch Ende Juli.

[crux2005]

RX Vega Launch auf SIGGRAPH 2017 - also erst Juli. GG AMD

[AtTheDriveIn]

Und wieder nix :(

[horn 12]

Prey gezeigt und AMD Versagt erneut auf Ganzer Linie!
Eine Stunde Schlaf geraubt!

Vega RX Gaming erst Ende Juli - August und da ist selbst Volta nicht mehr weit...
Zumindest hätte man Karten zeigen müssen, Benchmarks und ob es Custom Karten sofort zu kaufen gibt und die Performance andeuten wo die Reise hingeht!

[BiZiNiZz]

Prey gezeigt und AMD Versagt erneut auf Ganzer Linie!
Eine Stunde Schlaf geraubt!

Vega RX Gaming erst Ende Juli - August und da ist selbst Volta nicht mehr weit...
Zumindest hätte man Karten zeigen müssen, Benchmarks und ob es Custom Karten sofort zu kaufen gibt und die Performance andeuten wo die Reise hingeht!

Der Witz an der ganzen Sache war ja, das Prey auf 2 Karten in 4K lief.......

[horn 12]

AMD versagt erneut auf ganzer Linie
Wollen die Vega NICHT an den Mann bringen
Haben mehr Probleme als Ihnen lieb ist, so meine Einschätzung!

[Skysnake]

Hätte man sich echt sparen können

[Linmoum]

Wenn sie gar nichts zu sagen ist es schlecht, wenn sie dann doch was sagen ist es nicht ausreichend genug... Kann ja keiner was dafür, wenn ihr da heute großartig viel erwartet habt. :freak:

Spätestens nach Lisa Sus Aussagen letzte Woche war klar, dass da vor Juli nichts kommen wird. Und auch, wenn es einige hier immer noch liebend gerne hätte, aber die Prioritäten liegen bei AMD (zur Zeit) woanders, als bei Consumer-GPUs.

[OgrEGT]

Die Frage wär ja wie läuft Prey in Ultra 4k auf anderen Systemen? Auf CB bspw. wurde nur mit very high settings getestet...

https://www.computerbase.de/2017-05/prey-benchmark/2/#diagramm-prey-3840-2160


Und ist bekannt die Demo mit 2xFE 16Gb oder 2xRX 8Gb lief?

[r3ptil3]

Das soll wohl wohl ein Scherz sein?

Wieder keine Infos ausser dem Releasedatum??

[Korvaun]

Tjo, wie vorausgesagt, wird nix mit 2Q2017, jetzt frühestens August kaufbar. Und da wäre ich auch vorsichtig, Ref-Karten in kleinen Mengen erstmal, Custom dann eher Ende August wenn nich gar erst im September.

[TheGood]

Ach Ende Juli ist jetzt doch näher als zuerst befürchetet. Wenn Sie dann in der 1. Augustwoche ausreichend Karten ausliefern könnten würde es ja passen. Alle anderen holen sich die etwas teurere Frontier Edition.

Entweder ist VEGA wirklich sehr schnell oder grottenlangsam. Anders ist das Marketing leider nicht zu verstehen....

[uweskw]

Bleibt nur zu hoffen, dass es von der Computex den ein odere anderen Leak gibt.
Tja, weiter treu und doof warten oder jetzt nen System mit Ryzen und 1080Ti holen?
Naja, ein paar Tage werde ich ohnehin warten um zu sehen wer wirklich was Kunden/OC-freundliches aus dem neuen AGESA macht.

greetz
US

[MadCat]

Also harren wir der Dinge. Wenn, gibt es für mich nur eine Custom von Sapphire.
Werkskühler waren bisher nicht die leisesten...

Den delay kann ich aktuell verschmerzen, da sich der Hauptgrund für das Upgrade auf Vega RX auch aktuell verschiebt... ;)

@theGood: Hoffen wir das erstere, das letztere wäre ein Desaster.

[dildo4u]

Die Frage wär ja wie läuft Prey in Ultra 4k auf anderen Systemen? Auf CB bspw. wurde nur mit very high settings getestet...

https://www.computerbase.de/2017-05/prey-benchmark/2/#diagramm-prey-3840-2160


Und ist bekannt die Demo mit 2xFE 16Gb oder 2xRX 8Gb lief?
Die höste Stufe ist Very High.

[Pirx]

na toll mit Crossfire - sieht ja wirklich nicht so gut aus für Vega

W6Digv4mJi8

ps: "on ultra settings"??

[dildo4u]

Very High ist die Höste Einstellung ich vermute sie wollten es erst mit einer Karte zeigen,das wäre aber nur mit der alten Version gegangen.Per Patch wurden später die Screen Space Reflections gefixt was Performance kostet.

Links unten sieht man die SSR:

http://abload.de/img/preyssrimua5.png

https://youtu.be/YC2ZlLoo14w

[Digidi]

Tearing tritt doch nur auf wenn man über der Frequenz des Monitors liegt. Also waren das wirklich mehr als 60 Fps denn ein Monitor hat minimal 60Hz

[w0mbat]

Also mMn bedeutet das einfach, dass Vega keine Chance haben wird. Wenn Vega gut werden würde, hätten sie mehr gezeigt, bei Ryzen haben sie ja auch vorher schon angegeben.

Schade,

[Screemer]

Tearing tritt doch nur auf wenn man über der Frequenz des Monitors liegt. Also waren das wirklich mehr als 60 Fps denn ein Monitor hat minimal 60Hz
schon mal was von 144hz oder 120hz oder gar 200hz monitoren gehört? tearing tritt auch auf, wenn man unter der frequenz des monitors liegt. also quasi immer, wenn man nicht genau die frequenz des monitors hält, vrr oder vsync nutz.

[vinacis_vivids]

ps: "on ultra settings"??

"ultra high settings"

[Dorn]

Also mMn bedeutet das einfach, dass Vega keine Chance haben wird. Wenn Vega gut werden würde, hätten sie mehr gezeigt, bei Ryzen haben sie ja auch vorher schon angegeben.

Schade,
Wenn es der Preis richten würde, kein Problem aber mit HBM2 no way.
Werde das Teil trotzdem kaufen "müssen". :freak:

[Loeschzwerg]

Ich muss leider auch und hoffe einfach mal auf das Beste :freak: Die Demo hat schon einen etwas unbefriedigenden Eindruck hinterlassen. Was sollte dadurch vermittelt werden?

[Pirx]

Daß immerhin schon zwei lauffähige Vega-Karten existieren?;)

[MadManniMan]

Ernsthaft? Wir reden im Sommer 2017 noch über Crossfire?

[Raff]

Sommer -> Hitze -> Feuer. Logisch.

Gutes Timing, Ende Juli hätte ich einen Grund zum Feiern und Geldausgeben ... :D

MfG,
Raff

[dildo4u]

Ernsthaft? Wir reden im Sommer 2017 noch über Crossfire?
Sie wollten in der Präsentation hervorheben das Threadripper 64 PCI-E Lanes hat,daher wurden Multi GPU Systeme gezeigt.

[Achim_Anders]

Die Demo sollte einfach die 64 Lanes von Threadripper zeigen... Hatte mit Vega relativ wenig zu tun.

[Dino-Fossil]

Im Endeffekt war es also nur ein "But our princess GPU is in another castle exhibition"

Die Performance bleibt ebenfalls weiter völlig im Dunkeln - also liegt ihnen einiges daran selbige völlig geheim zu halten oder sie haben evtl. noch Treiberprobleme, die sowieso verhindern, dass Vega stabil/verlässlich auf Performance kommt?

Gut, dass mir meine 480 noch eine Weile reicht...

[r3ptil3]

Überlegt sich AMD vorher nicht was sie mit solchen Aktionen auslösen?

Totale Verwirrung... die einen deuten CF als schlechte Performance, dann wiederrum kommen die PCIe Lanes von Threadripper als Grund, was total sinnfrei ist.

Die hätten einfach einen 3DMark Score veröffentlichen sollen, um die Leute zu beruhigen.

[deekey777]

Daß immerhin schon zwei lauffähige Vega-Karten existieren?;)
Ernsthaft? Wir reden im Sommer 2017 noch über Crossfire?
Wieso Crossfire. Ich glaub, das war anders gemeint. Oder habe ich was verpasst?

[Loeschzwerg]

Wenn auf der Folie dick fett Vega "angekündigt" wird und dann die Demo folgt, erwarte ich zumindest etwas anderes als eine "PCIe Demo" für Threadripper.

Warum dann nicht vier virtuelle Systeme mit je 4C/8T + 1 GPU und auf einer Workstation (16C/32T + 4x GPU) bzw. etwas vergleichbares um wirklich die Stärken der Threadripper-Plattform zu demonstrieren?

Sehr unglücklich aufgezogen.

[HOT]

Crossfire über IF u.U. Das könnte schon was anderes sein als bisher.
Und die Leistungsfähigkeit wird man schon über die FE erahnen können - also am 27. und darum gehts den meisten doch eigentlich, auch wenn das nur ne Radeon Pro mit entsprechenden "blauen" Treibern ist, also keine Spieleoptimierungen hat.

Überlegt sich AMD vorher nicht was sie mit solchen Aktionen auslösen?

Totale Verwirrung... die einen deuten CF als schlechte Performance, dann wiederrum kommen die PCIe Lanes von Threadripper als Grund, was total sinnfrei ist.

Die hätten einfach einen 3DMark Score veröffentlichen sollen, um die Leute zu beruhigen.

Diese komische Strategie verfolgen die ja schon lange. Immer irgendwas zeigen was hinterher einfach 0 Aussagekraft hat.

[Locuza]

Die Boardpartner ließen auf der Computex derweil durchblicken, dass es zunächst nur Referenzdesigns geben wird und eigene Custom-Designs folgen sollen.
Ob AMD wieder ein Modell mit Kompakt-Wasserkühlung anbieten möchte, konnte noch niemand sagen. Die Frontier Edition zeigte der Hersteller bereits mit einer solchen.
Ebenso wurde unter der Hand das Offensichtliche bestätigt: Den Anfang wird ausschließlich Vega 10 machen.
Mittelklassemodelle mit der kleineren Vega-11-GPU sind erst gegen Ende 2017 zu erwarten, wahrscheinlich erst nächstes Jahr.
http://www.pcgameshardware.de/Vega-Codename-265481/News/AMD-Radeon-RX-Vega-Release-Termin-1229152/

[Dino-Fossil]

Möglicherweise hat Raja im AMA neulich den Mund ein bisschen zu voll genommen und es war AMD gar nicht mehr möglich noch einen brauchbaren Vega-Programmpunkt auf die Beine zu stellen.
Oder das Demo-System hatte kurzfristige technische Probleme.
Oder ein asiatisch aussehender Typ in Lederjacke hat es kurz vor der Show geklaut.
Oder...

Spekulationen über Spekulationen...

[Ihm]

Also mMn bedeutet das einfach, dass Vega keine Chance haben wird. Wenn Vega gut werden würde, hätten sie mehr gezeigt, bei Ryzen haben sie ja auch vorher schon angegeben.

Schade,

Chance gegen wen oder was?
Wenn eine Vega für ca. 300€ die Leistung einer "1070 Ti" abrufen kann und die Treiber halbwegs stimmen, dann hat sie schon gewonnen...für eine gewisse Zielgruppe.
Wenn ein Ryzen 1800X für 480€ im anwendungsspezifischen Multiprozessorbetrieb die Leistung einer 1000€ Intel CPU abrufen kann und keine Probleme mit Board etc. hat, dann hat sie auch schon gewonnen...für eine gewisse Zielgruppe.

Einige müssen sich mal angewöhnen etwas über den Tellerrand zu schauen. ;)

[gnomi]

Na ja. Bei High End und neuen GPU's geht es ja schon darum, die Konkurrenz zu schlagen, oder?
1070 Performance in etwas günstiger ist dann in der Praxis zwar keinesfalls schlecht, aber das lockt natürlich jetzt auch keinen Enthusiasten groß von nvidia weg.
Ich habe so ein wenig das Gefühl, dass AMD gute Produkte hat, die aber Intel und nvidia maximal etwas treiben, statt für großes Aufsehen zu sorgen. (wie Athlon oder ATI 970 damals noch)
Dementsprechend bin ich auch immer reservierter als es sein müsste. (und bleibe bei Intel und nvidia, logisch!)
Aber warten wir es mal ab...

[fondness]

Ja die Präsi war schon ziemlich zurückhaltend, ähnlich wie auch die von Raja letztens. Wenn man die 1080 schlägt, muss man wohl schon zufrieden sein, mehr erwarte ich nicht mehr.

[BlacKi]

Tjo, wie vorausgesagt, wird nix mit 2Q2017, jetzt frühestens August kaufbar. Und da wäre ich auch vorsichtig, Ref-Karten in kleinen Mengen erstmal, Custom dann eher Ende August wenn nich gar erst im September.
wird man nicht schon mit dem erscheinen der FE wissen wie schnell vega wird? zumindest wird das keine 2 monate mehr dauern.

[Dino-Fossil]

Vielleicht ist die Performance auch (noch?) sehr inkonsistent - immerhin ist es eine relativ weit überarbeitete Architektur, die sich evtl. vom bisherigen GCN-Verhalten sehr unterscheidet.
Zeigt man da nur ein paar Benches die sehr gut laufen geht wieder der Hype los, zeigt man schlechte ist es offensichtlich auch Käse.

[Grundkurs]

Wenn man die 1080 schlägt, muss man wohl schon zufrieden sein, mehr erwarte ich nicht mehr.
Wenn AMDs High-End Produkt im August-Oktober 2017 dort rauskommt, wo nvidia mit der 1080 schon im Mai 2016 war, wäre das mehr als traurig. Was dann als nächstes passiert kann man an drei Fingern abzählen, nvidia senkt die Preise der 1080, AMD wird wegen des teuren hbm2-speichers nicht mitziehen können und vom Start weg p/l-mäßig nicht mit der 1080 mithalten. Dann wird eine kurze Zeit lang in den Foren steif und fest drauf gepocht, dass Vega bei Singularity of the Ashes Benchmarks ja wohl deutlich die Nase vorne hat und in irgendeinem dx12-Benchmark ebenfalls vorne liegt, irgendwann verstummen auch diese Stimmen. Mit Einführung von Volta ab Frühjahr 2018 ist der Enthusiasten-Drops dann für AMD auf unbestimmte Zeit wieder gelutscht. Verstehe nicht wie sich das so entwickeln konnte, mit GCN war noch gleichstand, so lange ist das gar nicht her...

[fondness]

Wenn AMDs High-End Produkt im August-Oktober 2017 dort rauskommt, wo nvidia mit der 1080 schon im Mai 2016 war, wäre das mehr als traurig. Was dann als nächstes passiert kann man an drei Fingern abzählen, nvidia senkt die Preise der 1080, AMD wird wegen des teuren hbm2-speichers nicht mitziehen können und vom Start weg p/l-mäßig nicht mit der 1080 mithalten. Dann wird eine kurze Zeit lang in den Foren steif und fest drauf gepocht, dass Vega bei Singularity of the Ashes Benchmarks ja wohl deutlich die Nase vorne hat und in irgendeinem dx12-Benchmark ebenfalls vorne liegt, irgendwann verstummen auch diese Stimmen. Mit Einführung von Volta ab Frühjahr 2018 ist der Enthusiasten-Drops dann für AMD auf unbestimmte Zeit wieder gelutscht. Verstehe nicht wie sich das so entwickeln konnte, mit GCN war noch gleichstand, so lange ist das gar nicht her...

Tja, wenn die eine Seite konstant Ressourcen aufbaut und die andere abbauen muss, landet man eben irgendwann bei einer solchen Situation. Immerhin hat AMD jetzt wieder etwas Luft durch Ryzen und stellt wieder fleißig Leute ein, aber das wird sich natürlich auch erst frühestens bei der nächsten Generation auswirken.

[Ihm]

Na ja. Bei High End und neuen GPU's geht es ja schon darum, die Konkurrenz zu schlagen, oder?
1070 Performance in etwas günstiger ist dann in der Praxis zwar keinesfalls schlecht, aber das lockt natürlich jetzt auch keinen Enthusiasten groß von nvidia weg.
Ich habe so ein wenig das Gefühl, dass AMD gute Produkte hat, die aber Intel und nvidia maximal etwas treiben, statt für großes Aufsehen zu sorgen. (wie Athlon oder ATI 970 damals noch)
Dementsprechend bin ich auch immer reservierter als es sein müsste. (und bleibe bei Intel und nvidia, logisch!)
Aber warten wir es mal ab...

Nein, meiner Meinung nach nicht; oder nicht ganz.
Mir ist eine GPU lieber, die 10% weniger Leistung hat, aber dafür 30-40% weniger kostet. Nicht wegen meines Geldes, sondern wegen dem Fortschritt der ganzen Branche. Je mehr Leute sich einen schnellen Rechner leisten können, desto schneller geht es voran; z.B. VR.
High-End Leistung zum High-End Preis bringt den paar "Verrückten" mehr Auflösung mit ein paar mehr Details zum "Heimwanken". Der Fortschritt orientiert sich aber immer an der spielenden Masse und die Masse hat keine 1080 oder ein 1080 SLI-Gespann, sondern eine Grafikkarte im Bereich 150-350€; oder eine Konsole.
Wenn AMD es also mit der Vega schafft eine Grafikkarte auf den Markt zu werfen, die aktuelle "Fast-High-End"-Leistung mit "Mid-Range"-Preisen kombinieren kann, profitieren wir alle davon; aktiv oder passiv.

Beim Ryzen habe ich auch allen empfohlen abzuwarten, bis die Kinderkrankheiten raus sind oder die Probleme auf dem Tisch liegen.
Mit dem richtigen Board und RAM kann man aber auch heute schon eine sehr performante Workstation mit 8 physikalischen Kernen bauen. Zur Erinnerung: Für den 6900K will Intel bis heute 1000€ sehen. Für knapp 480€ bekommt man einen Ryzen X1800 mit fast identischer Leistung bei Bildbearbeitung und Rendering. Und in den anderen Szenarien ist das Teil auch nicht schwach.

http://www.anandtech.com/show/11170/the-amd-zen-and-ryzen-7-review-a-deep-dive-on-1800x-1700x-and-1700/18

Es gibt also überhaupt keinen Grund enttäuscht zu sein. Man sollte AMD eher dafür danken, dass sie wieder oben mitmischen und ihre Wettbewerber damit unter Druck setzen. In Anbetracht des verfügbaren Budgets ist das eine Glanzleistung von AMD. An Intels Ankündigungen kann man ja sehen, was dann auf einmal alles möglich ist.

Ich persönlich werde mir alleine schon aus diesem Grund einen AMD-Rechner zusammenbauen. Intel und Nvidia müssen stärker unter Druck gesetzt werden und das geht nur, wenn der Verbraucher mehr AMD-Hardware erwirbt. Auf die möglichen 10%-15% weniger Leistung bei AMD-GPUs verzichte ich gerne, wenn ich damit langfristig mehr bewegen kann.

[VooDoo7mx]

Chance gegen wen oder was?
Wenn eine Vega für ca. 300€ die Leistung einer "1070 Ti" abrufen kann und die Treiber halbwegs stimmen, dann hat sie schon gewonnen...für eine gewisse Zielgruppe.
Wenn ein Ryzen 1800X für 480€ im anwendungsspezifischen Multiprozessorbetrieb die Leistung einer 1000€ Intel CPU abrufen kann und keine Probleme mit Board etc. hat, dann hat sie auch schon gewonnen...für eine gewisse Zielgruppe.

Einige müssen sich mal angewöhnen etwas über den Tellerrand zu schauen. ;)

Wenn vega 10 so schnell wie eine "1070Ti" wäre für 300€ wäre das eine absolute Katastrophe. Ein Vega 10 Board ist in der Herstellung weit teuerer als ein 1080Ti Board. Größerer Chip, teurer HBM2 Speicher, aufwendigere, teurere Stromversorgung, ggf. noch eine AIO Wakü. Wenn AMD das dann noch für 300€ verramschen muss, machen sie praktischen keinen Gewinn oder fast schon Minus.
Aber das ist typisch für AMD Käufer. Hauptsache immer billig und geiz ist geil. Ob da die angebetete Firma pleite geht ist da erst einmal zweitrangig. Das so ein Preiskampf auch ruinös sein kann, ist anscheinend egal.

Und gerade AMD braucht endlich mal vernünftige Margen und Gewinne, damit sie in Forschung und Entwicklung investieren können.
Wenn aber da nichts rumkommt werden sie nie wirklich erfolgreich sein.

[Taigatrommel]

Chance gegen wen oder was?
Wenn eine Vega für ca. 300€ die Leistung einer "1070 Ti" abrufen kann und die Treiber halbwegs stimmen, dann hat sie schon gewonnen...für eine gewisse Zielgruppe.
Wenn ein Ryzen 1800X für 480€ im anwendungsspezifischen Multiprozessorbetrieb die Leistung einer 1000€ Intel CPU abrufen kann und keine Probleme mit Board etc. hat, dann hat sie auch schon gewonnen...für eine gewisse Zielgruppe.

Einige müssen sich mal angewöhnen etwas über den Tellerrand zu schauen. ;)
Wie wahrscheinlich ist es denn, dass Vega (10) für einen solchen Preis starten wird? IMHO absolut unrealistisch. Wenn Raja selbst davon spricht oder zumindest andeutet, man wird sich leistungstechnisch eher an einer 1080 Ti orientieren können, dann wird der Preis wohl nicht unterhalb von 600,-€ liegen.

Selbst wenn man nun weiterspinnt und sagt, die Karte wird ziemlich genau die Leistung einer 1080 Ti erreichen, so wirkt sich die Verzögerung immer negativer aus. Das nVidia Produkt bekomme ich jetzt für unter 700,-€. Das ist dann nun auch nicht mehr soooo weit von einer Vega entfernt - wenn sie denn wirklich für ~600€ starten wird, ggf. wird man die UVP ja auch zwischen 600 und 700€ ansiedeln.
Natürlich sind die besseren Customs der 1080 Ti deutlich teurer, allerdings darf man nicht vergessen, dass Vega ebenfalls zunächst nur mit Referenzdesign starten wird.

Ich persönlich glaube aufgrund der komplexen Entwicklung und den Problemen, welche HBM2 bereitet, nicht an einen Preisbrecher. Es sei denn AMD schreibt Vega eh als Verlustgeschäft ab und verhökert das Produkt ohne Gewinnziele, das kann ich mir allerdings nicht vorstellen.
Kunden, welche keine speziellen Vorlieben bzgl. der Marke haben oder eben bereits mit einem (guten) Freesync Monitor ausgestattet sind, haben meiner Meinung nach kaum Gründe, jetzt noch extra auf Vega zu warten. Es scheint sowohl unwahrscheinlich, dass Vega die Ti spürbar in der Leistung schlagen wird, noch spürbar im Preis unterbieten wird. Wer also noch im Sommer eine neue Karte kaufen will, der greift bedenkenlos zu nVidia.


Ich selbst bin ein wenig enttäuscht über die Vorstellung und hatte eigentlich fest mit einer Vorstellung von Vega RX gerechnet. Woran es nun scheitert, darüber kann man wohl nur spekulieren. Ist die Performance noch immer nicht ganz dort, wo man sie gerne hätte? Wahrscheinlicher sind wohl eher Produktionsengpässe: Es bringt ja nichts, das Produkt jetzt anzukündigen und groß zu präsentieren, wenn man effektiv ohnehin erst in allerfrühestens acht Wochen die ersten Karten ausliefern kann. Ein Paperlaunch in vier bis sechs Wochen bringt AMD ebenfalls keine Punkte. Von daher gehe ich davon aus, dass man die Vorstellung vor allem aufgrund schlechter Verfügbarkeit verschoben hat.

[Nakai]

Ja die Präsi war schon ziemlich zurückhaltend, ähnlich wie auch die von Raja letztens. Wenn man die 1080 schlägt, muss man wohl schon zufrieden sein, mehr erwarte ich nicht mehr.

50% auf Fiji, dank dem Takt darf man erwarten. Dass das auf 1080OC liegt, sollte klar sein.

Ja, das sollte man erwarten dürfen.

[Dino-Fossil]

Immerhin gibt es von PCGH aber auch einen Hinweis auf Vega11 als "midrange" Vega.
Das kann man, mMn, durchaus als positiv bewerten. Wäre Vega10 so schlecht, dass sie kaum die 1080 knacken, bräuchte es keinen weiteren Vega, dann kann man genauso gut Polaris weiterlaufen lassen.
Vega11 als neue midrange-Lösung erscheint mir als sinnvoller, falls Vega10 sich wirklich mit der 1080Ti anlegen kann, denn damit wäre zwischen Polaris und Vega10 eine zu große Lücke.

[vinacis_vivids]

Zurückhaltung finde ich gut :)
Das macht Lust auf mehr...

[Mancko]

50% auf Fiji, dank dem Takt darf man erwarten. Dass das auf 1080OC liegt, sollte klar sein.

Ja, das sollte man erwarten dürfen.

Das ist aber bei den Kosten für das Produkt und dem zeitlichen Nachteil auch viel zu wenig. GP104 ist ein Performance Chip. Das beginnt bei der Chipgröße geht über das kastrierte Speicherinterface bis hin zur simplen Platine und das der seit über 1 Jahr in solchen Preisgefilden verkauft werden kann ist ohnehin schon ausschließlich der Abstinenz von AMD zu verdanken. Die 1080Ti kann Nvidia auch für 300 verhökern und verdient immer noch ordentlich Asche.

[Eldoran]

Der Schwerpunkt war offenbar darauf wie viele Premium OEM Produkte demnächst auf den Markt kommen. So weit durchaus verständlich, der Launch der anderen Produkte passiert zu einem anderen Termin.

Immerhin sind sowohl Threadripper als auch Raven Ridge als grundsätzlich funktionstüchtig vorgestellt worden. Die Prey Demo fällt auch eher in diese Kategorie.

Andererseits gerade bei Vega war die Stimmung ziemlich: ja es funktioniert, beim compute ist alles bestens. Es hatte einen starken Drall zum Hinhalten. Ich würde sagen, die Treiber sind noch nicht wirklich fertig, vor allem die Optimierungen bei Spielen.