Theorie um Vegas HBCC Feature

The_Searcher

Komplett-PC-Käufer(in)
3DCenter hat versucht ein bisschen Licht hinter Vegas HBCC Feature zu bringen.

Als Ergebnis wurde gesagt das es sich um HBCC "nur" um das normale HBM-Speicherinterface handelt. Allerdings arbeitet dieses Feature dann doch anders als normaler GDDR5 bzw. wie der HBM Speicher bei Fiji.

Das HBCC Feature soll (ohne zutun der Entwickler) der Software die Speicherverwaltung entziehen bzw. dieser nur noch virtuell erlauben beliebige Speichermengen zu fordern. Die Grundlegendste Veränderung ist jedoch das der HBM Speicher tatsächlich nur noch als Cache fungieren soll. Das bedeutet das nur noch die wichtigsten Daten auf diesen liegen und der Rest auf den PC-Hauptspeicher geladen werden. Interessant hierbei ist das CPUs genauso arbeiten.

3DCenter merkt zudem noch an, das die Größe des Caches eine geringere Rolle spielen könnte, und es deshalb auch egal sein kann ob eine 16 bzw. 8 Gibibyte Karte verwendet wird.

Sollte sich das bestätigen wäre das Geheimnis um AMD Aussage, dass Sie den (GPU-)Speicherverbrauch signifikant verringern werden, gelöst.

AMDs HBCC-Feature arbeitet zugunsten hoherer Minimum-Frameraten sowie der Grafikkarten-Langlebigkeit | 3DCenter.org
 
ich sehe das bis jetzt noch kritisch

"Das bedeutet das nur noch die wichtigsten Daten auf diesen liegen und der Rest auf den PC-Hauptspeicher geladen werden."

heißt für mich, das nur die Texturen etc. von dem im Speicher liegen was man gerade auf dem Bildschirm sieht

dreht man sich dann im Game schnell um fängt es an zu ruckeln weil erstmal die neuen informationen wieder geladen werden müssen

da hab ich lieber nen randvollen Speicher aber weniger Ruckler

aber wir werden erst bei Tests sehen, as AMD da wirklich gemacht hat
 
dreht man sich dann im Game schnell um fängt es an zu ruckeln weil erstmal die neuen informationen wieder geladen werden müssen
Ich kann mir nicht vorstellen, dass AMD diesen naheliegenden "worst" case nicht bedacht bzw. keine Lösung dafür gefunden hat. Falls es wirklich dieses von dir beschriebene Problem sehr häufig geben sollte, ist das HBCC-Feature relativ witzlos.

Wenn das mit den minimum FPS so hinkommt, könnte ich mir vorstellen, dass Pascal- und Volta-Karten höhere avg fps haben, aber AMDs Vega im Gegenzug mit relativ hohen minimum FPS auftrumpfen kann, wodurch das Spielerlebnis flüssiger wirken könnte. Haltet ihr das für realistisch oder ist das nur eine Spinnerei von mir?
 
Der Raja hat ja schon im Interview betont dass es bezüglich VRAM ein Umdenken geben wird wie bei HDD zu SSD.
Nicht immer mehr und mehr Kapazität sei wichtig sondern zunehmend Bandbreite, das sei auch nun auch eine Herausforderung fürs Marketing.
Auf spezielle Optimierung (AMDs aufgestockter TreiberTeam?) zum HBCC soll die Performance nochmal deutlich gestiegen werden.
Die erste Generation wird sicher noch nicht ganz rund laufen aber wenn die Technik taugt sich durchsetzt dann hat AMD einen nicht zu unterschätzenden Techniologie- und Kostenvorteil.

raja-koduri-page-024-740x416.jpg
Das dürfte unter anderem die Folie mit Rajas kleinem Seitenhieb gegenüber Nvidia erklären. "Die Konkurrenz macht weiter und weiter und weiß gar nicht wo hin es geht" oder so ähnlich waren seine Worte. Na mal schauen...
 
Wie sieht es eigentlich mit dem RAM-Verbrauch aus, wenn der HBM als Cache dient? Da müsste man ja dann die fehlende VRAM-Kapazität sicher als RAM vorhalten, wenn dorthin ausgelagert wird.
 
Wie sieht es eigentlich mit dem RAM-Verbrauch aus, wenn der HBM als Cache dient? Da müsste man ja dann die fehlende VRAM-Kapazität sicher als RAM vorhalten, wenn dorthin ausgelagert wird.
Laut der Theorie von 3DCenter wäre dies genau der Fall.
3DCenter schrieb:
Denn anstatt den Grafikkartenspeicher als den hauptsächlichen Speicher für die Grafikchip-Berechnungen zu betrachten, wird nunmehr der PC-Hauptspeicher (bzw. ein Teil hiervon) als der hauptsächliche Speicher des Grafikchips deklariert – und der Grafikkartenspeicher wird logisch gesehen tatsächlich zum Cache dieses Hauptspeicher-Teils. Damit verändert sich die Speicherbelegungsstrategie: Während es vorher das Ziel war, den Grafikkartenspeicher möglichst gut mit Daten zu befüllen, egal ob nun wirklich nutzvoll oder nicht, geht die Speicherbelegungsstrategie bei Vega eher in die Richtung, in diesen Cache (den Grafikkartenspeicher) wirklich nur konkret benötigte Daten einzuladen.

Wobei man jetzt argumentieren könnte, das jemand der sich eine 500€ Karte leistet, auch eine entsprechende RAM-Menge besitzt. Ausnahmen bestätigen natürlich die Regel und sollte bitte nicht als pauschalisierung meinerseits gesehen werden :)
 
Ich sehe den Vorteil noch nicht.

Ist es nicht jetzt schon so, dass der Grafikspeicher gefüllt wird und alles was dort nicht reinpasst im RAM landet?
 
Naja, wenn es so kommt und sich auch lohnt, dann hätte ich mit meinen 32 GB Ram ja alles richtig gemacht.

Schade, dass es nun doch noch mehrere Wochen dauern wird, bis wir endlich die ersten richtigen Vega-Karten kaufen können.
 
Wie sieht es eigentlich mit dem RAM-Verbrauch aus, wenn der HBM als Cache dient? Da müsste man ja dann die fehlende VRAM-Kapazität sicher als RAM vorhalten, wenn dorthin ausgelagert wird.
Das musst du (unter Windows) im Grunde auch jetzt schon. WDDM-Allokationen können jederzeit in den Hauptspeicher ausgelagert werden, was z.B. nötig wird, wenn sich mehrere Prozesse um den Grafikspeicher prügeln, und Windows verlangt, dass der dafür nötige Speicher in irgendeiner Form (RAM oder Swap-Datei) vorhanden ist. Wichtig ist aber natürlich, dass die Daten wirklich im "richtigen" RAM liegen, wenn sie angefordert werden, und nicht auf der Swap-Partition.

Ist es nicht jetzt schon so, dass der Grafikspeicher gefüllt wird und alles was dort nicht reinpasst im RAM landet?
Ja, was aber mit dem aktuellen Modell nicht so gut funktioniert, ist das dynamische Swappen zwischen RAM und VRAM. AFAIK funktioniert das nur softwaregesteuert auf der Granularität von typischerweise recht großen WDDM-Allokationen.

In der Regel will man, dass Texturen nach Möglichkeit im VRAM liegen (Rendertargets immer, bei Vertex-Buffern ist es weniger wichtig), aber wenn ein Spiel 8GB VRAM belegt, dann wird in der Regel pro Frame nur ein Teil davon wirklich gebraucht. Da sich der benötigte Datensatz von Frame zu Frame in der Regel nur geringfügig ändert, kann so ein Cache-Design durchaus daür sorgen, dass man ein solches Spiel auch mit 4GB VRAM problemlos spielen kann, mit entsprechend regem Datentransfer auf dem PCIe-Bus.

Falls es tatsächlich so kommt: Leider etwas spät. Die R9 Fury könnte das ganz gut gebrauchen und (für Spieler) gibt es VRAM inzwischen in Massen. Dürfte aber auch für andere Anwendungsbereiche durchaus sinnvoll sein.
 
Die bessere Frage ist warum soll das nur Vega können? Klar ist Bedingung, dass die GPU direkt auf dem RAM zugreifen kann, aber das kann Pascal auch. Und GDDR5 ist immer noch massiv schneller als was PCIe liefern kann.

Weiterhin ist halt die Frage wie gut es funktioniert wenn die Applikation es nicht nativ unterstützt, denn dann muss der Treiber halt raten was als nächstes benötigt wird und jede Texturestreamingengine arbeitet etwas anders. Das dürfte viel Treiberarbeit werden.
 
Wenn das ganze hardwareseitig so umgesetzt wird wie ein CPU-Cache, dann muss der Treiber ziemlich genau gar nichts raten. Der 3DCenter-Artikel erklärt ja eigentlich ganz gut, wie das funktionieren würde, wenn die Umsetzung entsprechend aussieht.

Wenn man sich ältere Quellen zu dem Thema durchliest, scheint das auch durchaus plausibel - Daten würden dann eben on demand in den VRAM geladen, mit entsprechendem Hardware-Support (und ohne wäre das ganze witzlos) also ohne Interaktion mit dem Treiber.

Direkt auf den RAM zugreifen kann jede GPU der letzten... ganz vielen Jahre, unter anderem jede, die Vulkan-Support bietet. Das ist im Grunde auch die einzige Möglichkeit, mit den neuen Grafik-APIs überhaupt große Datenmengen in den VRAM zu schreiben. Das ist nicht neu.
 
Zuletzt bearbeitet:
Der Raja hat ja schon im Interview betont dass es bezüglich VRAM ein Umdenken geben wird wie bei HDD zu SSD.
Nicht immer mehr und mehr Kapazität sei wichtig sondern zunehmend Bandbreite, das sei auch nun auch eine Herausforderung fürs Marketing.
Bei zu wenig (V)RAM hilft nur eins: Mehr (V)RAM.

Da kann AMD noch so viel erzählen wie sie wollen, das Auslagern auf ein langsameres Medium wird immer mit Geschwindigkeitseinbußen verbunden sein, sofern die Daten im (V)RAM auch wirklich benötigt werden und in Echtzeit benötigt werden. Und selbst Quad Channel-DDR4-RAM mit 3200MHz ist im Idealfall (den es nie gibt...) nur ca. 100GB/s schnell. Dann noch die Latenzen... Von einer NVMe-SSD braucht man garnicht erst reden. Die ist ja nochmals deutlich langsamer - und vorallem bezüglich des Schreibens auch in der Lebensdauer begrenzt.

Und ich habe auch wenig Interesse daran, dass die Treiber für solche Späße vom Hersteller erst angepasst werden müssen. "Oh sorry, deine Grafikkarte ist älter wie zwei Jahre... EOL. Aber du kannst ja eine Neue kaufen...".

Da versucht sich ne Firma bloß ihren sauteuren und unflexiblen HBM-RAM schönzureden...
 
Wenn das ganze hardwareseitig so umgesetzt wird wie ein CPU-Cache, dann muss der Treiber ziemlich genau gar nichts raten. Der 3DCenter-Artikel erklärt ja eigentlich ganz gut, wie das funktionieren würde, wenn die Umsetzung entsprechend aussieht.

Wenn man sich ältere Quellen zu dem Thema durchliest, scheint das auch durchaus plausibel - Daten würden dann eben on demand in den VRAM geladen, mit entsprechendem Hardware-Support (und ohne wäre das ganze witzlos) also ohne Interaktion mit dem Treiber.

Direkt auf den RAM zugreifen kann jede GPU der letzten... ganz vielen Jahre, unter anderem jede, die Vulkan-Support bietet. Das ist im Grunde auch die einzige Möglichkeit, mit den neuen Grafik-APIs überhaupt große Datenmengen in den VRAM zu schreiben. Das ist nicht neu.

Welcher Hardwaresupport? AMD entzieht dem Spiel einfach die Speicher Allocation und verlegt sie in den Treiber. Das spiel wird weiterhin die gleiche Menge VRAM haben wollen, nur setzt sich nun der Treiber dazwischen und verteilt den Bedarf auf VRAM und RAM. Und man darf nicht vergessen, dass auch bei den CPUs es öfter zu Chace overflow und Cache Misses kam bis die Software die Daten angepasst bereit stellte.
 
Welcher Hardwaresupport? AMD entzieht dem Spiel einfach die Speicher Allocation und verlegt sie in den Treiber
Es ist doch noch gar nicht bekannt, wie das ganze funktioniert. Mit Hardware-Support meine ich einfach, dass folgende Schritte von der GPU übernommen werden:
1. Daten von HBM-Cache anfordern
2. Cache-Miss feststellen
3. Daten per DMA vom Host laden und in den HBM-Cache schreiben

...wie eben bei jedem CPU-Cache und den kleineren GPU-Caches, die ja ohnehin schon vorhanden sind. Ich sehe nicht, warum man das nicht so umsetzen sollte.

Und man darf nicht vergessen, dass auch bei den CPUs es öfter zu Chace overflow und Cache Misses kam bis die Software die Daten angepasst bereit stellte.
CPUs haben aber auch nur wenige MB Cache und nicht mehrere Gigabytes. Das Verhältnis zwischen Cachegröße und Working Set ist völlig anders.
 
Also wenn ich sehe wie Broadwell im vergleich zu allen anderen bisher erhältlichen CPUs seine IPC durch den riesigen Cache hochschraubt, bin ich sehr offen gegenüber dem Gedanken das die GPU jetzt auch mit einem "Cache" arbeitet:ugly:
Arbeitsspeicher ist im Notfall schnell nachgekauft^^
 
Es ist doch noch gar nicht bekannt, wie das ganze funktioniert. Mit Hardware-Support meine ich einfach, dass folgende Schritte von der GPU übernommen werden:
1. Daten von HBM-Cache anfordern
2. Cache-Miss feststellen
3. Daten per DMA vom Host laden und in den HBM-Cache schreiben

...wie eben bei jedem CPU-Cache und den kleineren GPU-Caches, die ja ohnehin schon vorhanden sind. Ich sehe nicht, warum man das nicht so umsetzen sollte.


CPUs haben aber auch nur wenige MB Cache und nicht mehrere Gigabytes. Das Verhältnis zwischen Cachegröße und Working Set ist völlig anders.

1. das tut heute jede GPU auch aus ihrem VRAM
2. das ggf. auch
3. das dann auch

Nur weil ich den VRAM plötzlich Cache nenne, ändert sich gar nichts. Broadwell hatte einen großen L3 Cache der natürlich auch deutlich fixer angebunden ist als der RAM. Vegas HBCC hängt aber genauso an PCIe wie der VRAM jeder stinknormalen Grafikkarte.
 
Nur weil ich den VRAM plötzlich Cache nenne, ändert sich gar nichts.
Doch, Punkt 2 und 3 eben schon. Bislang entscheidet die Software (sprich: Anwendung und Treiber), was im VRAM steht und was nicht. Die GPU kann da nicht einfach on demand Daten reinladen und wieder rauswerfen. Das kann sich ändern.
 
Kepler kann es bedingt, Pascal kann es sicher. Die GPU muss nur den RAM adressieren können. Der Rest ist primär eine Treiberfrage, denn nur der Treiber kann und muss VRAM Bedarf und verfügbaren RAM passend anpassen.
 
Zurück