Archiv verlassen und diese Seite im Standarddesign anzeigen : Diskussion zu: AMDs HBCC-Feature arbeitet zugunsten höherer Minimum-Frameraten ...
Leonidas
2017-05-19, 20:44:58
Link zur News:
https://www.3dcenter.org/news/amds-hbcc-feature-arbeitet-zugunsten-hoeherer-minimum-frameraten-sowie-der-grafikkarten-langleb
mag ja alles schön und gut sein, nur dürften die entwickler dann keinne thread_private oder node_private adressierung vornehmen. amd kann nur previous_shared ablegen lassen, mehr geht nicht. die entwickler könnten das selbst festlegen und wenn sie es so nicht wollen, kann amd da ja nicht einfach per treiberoptimierung alles abändern wies ihnen gefällt um sich einen vorteil zu verschaffen. was amd da macht halte ich für blödsinn. damit kann es mehr probleme geben als es sinn macht und letztendlich kennen wir amds pflege. die schaffen ja nicht mal pünklich gameready treiber zu launchen und verschlafen schon mal wichtige termine bei vorankündigungen von spielen, leisten dort zuweilen überhaupt keine treiberpflege. dieser ganze optimierungkram den amd da letztlich mit crimson relive aufgeblasen hat, überfordert sie doch jetzt schon und unter dx12 ist das für die ihvs eigentlich tabu. wenn das alles sein soll, ist hbcc der letzte schrott und passt nicht zu allen engines. ein controler der das virtuelle speicheradressverhalten beeinflusst? das wird weder dem spieleentwickler noch m$ gefallen, einfach einen maulkorb verpasst zu bekommen wies amd passt. wieder so ein proprietärer vorstoss seitens amd, wobei sie immer behaupten alles open source.
@leonidas
Kannst du bitte noch den Unterschied/Vorteil des HBCC-Feature gegenüber dem alten "AGP aperture size"-Feature erklären? Danke.
"..... hochtrabenderweise als "High-Bandwith Cache ...."
Was soll daran eigentlich kein Cache sein? Das AMD schon lange daran arbeitet den Speicher der GPU in die bereits vorhandene virtuelle Speicherhierarchie einzubinden ist kein Geheimnis.
Welche zusätzlichen Eigenschaften soll ein Cache haben der nach Meinung des Autors diese Bezeichnung verdient hätte?
Leonidas
2017-05-20, 06:14:27
Das "hochtrabenderweise" gehört in diesem Augenblick in Anführungszeichen. Ich wollte kenntlich machen, das dies erst alles wie Marketing geklungen hat - obwohl es sich dann als echt herausgestellt hat. Hab es nun leicht abgeändert.
Unterschied zur AGB Aperture Size: Ja, das frage ich mich auch. Aber derzeit gibt es zu wenige Infos insgesamt darüber.
Achill
2017-05-20, 11:22:54
Als AMD zum Jahresanfang die Vega-Architektur vorstellte, konnte man mit dem dort erwähnten "High-Bandwith Cache" und "High-Bandwith Cache Controller" noch nicht viel anfangen – insbesondere die Nennung eines extra Caches verführte zur (fälschlichen) Annahme, AMD könnte hier (neben dem eigentlichen Grafikkartenspeicher sowie den Chip-internen Caches) noch einen weiteren superschnellen Zwischenspeicher verbaut haben. Inzwischen ist spätestens mit der Vorstellung der "Radeon Vega Frontier Edition" zum FAD'17 klar, das der "High-Bandwith Cache Controller" (HBCC) nichts anderes als ein anderer Name für das HBM-Speicherinterfaces des Vega-10-Grafikchips ist – und das die daran angebundenen bis zu 16 GB HBM2-Speicher von AMD (vermeintlich) hochtrabenderweise als "High-Bandwith Cache" betrachtet werden.
@Leonidas - ich weiß nicht ob das so stimmt. Wenn HBCC nur HBM2 wäre, dann würde RotTR@4k mit deaktivierten HBM2 nicht so schnell laufen weil dann alle Reads aus dem System-RAM kommen würden? Siehe: https://youtu.be/UlZbDcSrj3o?t=123
(Jemand hat die Live-Präsi aufgenommen, die Rucker sind Streaming-Probleme)
Ich denke, dass der HBCC schon eine Logische Einheit ist, die zwischen der GPU und natürlich dem HBM2 aber auch anderen Speicher operiert.
Wenn AMD beim Namen nicht total nach klang gegangen ist, dann wäre ein "Cache Controller" äquivalent zu Konzepten aus der Software-Welt ein aktives Element, das darüber entscheidet:
* Welche Daten kommen in die Cache (HBM2)
* Entfernen von Daten aus der Cache
* Fetch von Daten aus attached NVRAM oder aus dem System-Ram
Ein weiterer Punkt kann sein, dass sich dadurch Latenz-Vorteile ergeben. Wenn bisher durch den Treiber (CPU) gesteuert wurde (und über den PCIe Chanel kommuniziert werden muss), jetzt aber der HBCC selbst fetched.
Eine weitere Möglichkeit könnte sein, dass der HBCC aufgrund der Lese- und Schreibzugriffe die Daten Optimal über die HBM2 Zellen anordnet, damit diese bei bestimmen Lese-Schreib-Mustern nicht blockiert sind.
Zuletzt könnte ich mir noch ein Caching/Swapping auf Blockebene vorstellen, wird zum Beispiel von einer Textur nicht alle Teile verwendet, so verbleiben nur die genutzten Daten in der Cache. Korrekter ist wahrscheinlich sogar, das nur die benötigten Daten-Blöcke gefetched werden (Reduktion der PCIe Last).
Ist natürlich alles nur Specu - aber wer weiß ... ;)
sys64738
2017-05-20, 14:22:21
Für mich sieht das wie eine Umbenennung von HyperMemory (https://en.wikipedia.org/wiki/HyperMemory), bzw. TurboCache (https://en.wikipedia.org/wiki/TurboCache) aus. Meinem Verständnis nach scheint es auf jeden Fall nur dann etwas positives zu bewirken, wenn denn der Videospeicher auch tatsächlich zu knapp wird, kann dann aber, da dann ja über den PCIe gegangen werden muss, echten Videospeicher nicht ersetzen.
Gast Ritis
2017-05-20, 14:57:06
Ich denke, dass der HBCC schon eine Logische Einheit ist, die zwischen der GPU und natürlich dem HBM2 aber auch anderen Speicher operiert.
Wenn AMD beim Namen nicht total nach klang gegangen ist, dann wäre ein "Cache Controller" äquivalent zu Konzepten aus der Software-Welt ein aktives Element, das darüber entscheidet:
* Welche Daten kommen in die Cache (HBM2)
* Entfernen von Daten aus der Cache
* Fetch von Daten aus attached NVRAM oder aus dem System-Ram
Ein weiterer Punkt kann sein, dass sich dadurch Latenz-Vorteile ergeben. Wenn bisher durch den Treiber (CPU) gesteuert wurde (und über den PCIe Chanel kommuniziert werden muss), jetzt aber der HBCC selbst fetched.
So ist es. Wenn AMD explizit über einen Cache-Controller spricht, dann gibt es den auch. Wahrscheinlich wird das HBM für legacy Software simple/alte Modi erlauben.
Aber ein Cache benötigt im Gegensatz zu Standard RAM keine Speicherverwaltung durch den Programmierer und muss nicht alloziert oder freigegeben werden. Ordentlicher Cache wird immer per Hardware on the fly verwaltet, es spricht nichts dagegen, dass das mit dem HBCC auch so gemeint ist. Prefeching und leeren des Caches sind dann nur optionale Softwarefeatures und werden in der Regel vom Compiler gehändelt, oder bei Handoptimierungen, das traut man den üblichen Gamesentwicklern eigentlich nicht zu. Das wird bei einer GPU dann in angepassten Treibern erledigt.
Der Cache-Controller von Vega könnte unterschiedlich konfiguriert werden, als Write-Through oder Write-Back, je nachdem was günstiger ist. Zudem soll dieser ja auch Disk- und Netzwerkseitige Sourcen cachen können. Bei SGG wird das nochmal den Schub gebracht haben den man gegenüber dem Fijii-Prototypen demonstriert hat.
Je besser das Caching durch die HW und den Treiber abgewickelt wird desto weniger Geschick müssen die Applikationsentwickler an den Tag legen. Das sollte sich auf alle Arten von Software durchschlagen.
Dass die Game-Entwickler bislang durch die Bank dort grossen Quark angerichtet haben hat man ja bereits öfters von AMD durch die Blume gehört.
@leonidas
Kannst du bitte noch den Unterschied/Vorteil des HBCC-Feature gegenüber dem alten "AGP aperture size"-Feature erklären? Danke.
PCIe hat eine höhere Bandbreite als AGP ;)
Für mich sieht das wie eine Umbenennung von HyperMemory (https://en.wikipedia.org/wiki/HyperMemory), bzw. TurboCache (https://en.wikipedia.org/wiki/TurboCache) aus. Meinem Verständnis nach scheint es auf jeden Fall nur dann etwas positives zu bewirken, wenn denn der Videospeicher auch tatsächlich zu knapp wird, kann dann aber, da dann ja über den PCIe gegangen werden muss, echten Videospeicher nicht ersetzen.
Das Ding muß sowieso eine MMU haben um 512TB virtuellen Speicher adressieren zu können, da fällt das caching quasi als Abfall ab.
Um den "zusätzlichen" Speicher zu nutzen kann der Treiber Legacy-Anwendungen einfach mehr GPU Speicher zurückmelden.
So ist es. Wenn AMD explizit über einen Cache-Controller spricht, dann gibt es den auch. Wahrscheinlich wird das HBM für legacy Software simple/alte Modi erlauben.
Aber ein Cache benötigt im Gegensatz zu Standard RAM keine Speicherverwaltung durch den Programmierer und muss nicht alloziert oder freigegeben werden. Ordentlicher Cache wird immer per Hardware on the fly verwaltet, es spricht nichts dagegen, dass das mit dem HBCC auch so gemeint ist. Prefeching und leeren des Caches sind dann nur optionale Softwarefeatures und werden in der Regel vom Compiler gehändelt, oder bei Handoptimierungen, das traut man den üblichen Gamesentwicklern eigentlich nicht zu. Das wird bei einer GPU dann in angepassten Treibern erledigt.
Der Cache-Controller von Vega könnte unterschiedlich konfiguriert werden, als Write-Through oder Write-Back, je nachdem was günstiger ist. Zudem soll dieser ja auch Disk- und Netzwerkseitige Sourcen cachen können. Bei SGG wird das nochmal den Schub gebracht haben den man gegenüber dem Fijii-Prototypen demonstriert hat.
Je besser das Caching durch die HW und den Treiber abgewickelt wird desto weniger Geschick müssen die Applikationsentwickler an den Tag legen. Das sollte sich auf alle Arten von Software durchschlagen.
Dass die Game-Entwickler bislang durch die Bank dort grossen Quark angerichtet haben hat man ja bereits öfters von AMD durch die Blume gehört.
Als HW wird lediglich eine MMU da sein, und im Page-Fault-Handler wird aus der Speicherhierarchie in den GPU-Speicher kopiert und die MMU-Tabellen angepasst.
Iscaran
2017-05-20, 16:26:00
Wenn ich das richtig verstehe ist HBCC eine Funktion die optimal erst mit Unterstützung des Programms funktioniert. Aber auch ohne dies evtl. zu guten Performance boosts führen kann.
Bei HBCC fungiert der HBM als "Cache". Die Texturen des Games werden primär im normalen RAM vorgehalten und der GPU-Treiber/Software entscheidet dann was davon im Cache gelagert wird.
Deswegen kann es eben bei VRAM-Mangel auch so drastisch die Min FPS anheben...
Kartenlehrling
2017-05-20, 16:46:08
Ist die Idee nicht alt?
Nvidia hat doch auch ein Teil der Arbeitsspeichers verwalten können, war aber nur auf 1gb beschränkt.
Screemer
2017-05-20, 17:01:59
ich denke nicht, dass hbcc mit einer der bisher verwendeten "caching"-geischichten für gpus vergleichbar ist. bin schon sehr gespann wie und ob es wirklich gut performt. die 2gb vram präsentation von rottr hat mich auf jeden fall schon mal ziemlich beeindruckt. hisn hätte da bestimmt einige extrembeispiele für spiele die vram fressen bis es kein morgen gibt.
Wenn ich das richtig verstehe ist HBCC eine Funktion die optimal erst mit Unterstützung des Programms funktioniert.
Eher umgekehrt.
Die Frage ist was ist effizienter, wenn die Software den Speicher verwaltet so wie sie es will, oder der Grafiktreiber.
Es kann nur etwas bringen wenn das Verwalten des Texturstreamings von der Software nicht optimal ist. Evtl. können vom Grafiktreiber auch Bubbles in denen man die Daten über den PCIe hin- und herschaufeln kann besser erkannt werden.
Die Frage ist wie viel es vom Grafiktreiber abhängt ob dieses Caching effizient funktioniert, wenn da für jedes Spiel Anpassungen notwendig sind, wird es wohl kaum mehr als ein paar Vorzeigespiele geben die davon nennenswert profitieren.
Aber egal wie gut das Caching ist, echter Grafikspeicher bei welchem gar kein auslagern notwendig ist immer besser.
danarcho
2017-05-21, 00:26:23
Als HW wird lediglich eine MMU da sein, und im Page-Fault-Handler wird aus der Speicherhierarchie in den GPU-Speicher kopiert und die MMU-Tabellen angepasst.
Eine MMU wird da nicht reichen, sonst könnten das schon Fiji und Polaris.
Ich denke eher, dass es sich um ein Hardware-Feature handelt, um Pages ohne Treiber-Intervention aus dem RAM zu fetchen. So wie es Caches halt auch machen.
So gesehen geht es dann auch nicht mehr um Software vs Treiber, sondern um Software vs Hardware. In die gleiche Richtung gehen eigentlich schon die HSA-Features. Dort fällt auch schon das komplette manuelle Management der Kopiervorgänge weg, sofern man die HSA-Runtime verwendet.
Disclaimer: Ich habe mich noch nicht viel mit HBCC beschäftigt, falls ich grad Blödsinn erzähle ;)
Aber egal wie gut das Caching ist, echter Grafikspeicher bei welchem gar kein auslagern notwendig ist immer besser.
Klares Nein!
"Echter" Speicher wird durch vergrößern langsamer.
Eine MMU wird da nicht reichen, sonst könnten das schon Fiji und Polaris.
Ich hab da nichts gefunden, lediglich Verweise auf die IOMMU vom Host.
Und die Zugriffe bei APUs laufen über die MMU vom Host, aber das ist eine andere Baustelle.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.