AMDs HBCC dürfte mit den zuvor genannten - wenn überhaupt - nur indirekt etwas zu tun haben. Etwas vergleichbares zu HBCC scheint mir nVidia momentan nicht zu haben. In dem von dir zuvor geposteten
Link wird die Funktionsweise doch angeprochen und das die Herangehensweise etwas grundlegend neues sein soll, das es bisher so noch nicht gab. Die Demonstration des HBCC mit Tomb Raider auf der FAD17 mit der Begrenzung des VRAMs auf 2GB, dürfte dies mehr oder weniger auch bestätigen. Wenn nVidia eine vergleichbare Technik zu HBCC bereits hätte, dürfte die 1080Ti in der dort gezeigten Demo ebenso wenig einbrechen wie Vega es tut. Dies lässt somit zunächst einmal den Schluss zu, dass nVidia eben nichts vergleichbares zu HBCC hat oder - vorsichtig ausgedrückt - nichts was seinen Dienst so leistungsfähig und effizient verrichtet wie eben AMDs Lösung. Vermutlich dürfte HBM hier durch seine technischen Eigenheiten eine gewisse Schlüsselrolle innehaben um überhaupt in der Form als schneller und effizienter Cache fungieren zu können.
Ist die rangehensweise denn wirklich neu, die dort im Artikel angesprochen wird?
Ehrlich gesagt sehe ich da eher unpassende(re) Vergleiche zu CPU Caches... Es war doch von der reinen Nutzung her gesehen die ganze Zeit schon so, die GPU konnte auf den VRAM Zugreifen und wenn dieser ausging, konnten Daten aus/umgeschaufelt werden. Ebenso, was viele wohl gar nicht mehr kennen oder auf dem Schirm haben, vor Jahren hat man so ein Feature mal HyperMemory (ATI) oder TurboCache (NV) geschimpft. Mit quasi dem gleichen Ansatz... Einem zusätzlichen Abstraktionslayer, der über einen lokalen und remote Cache gespannt wurde. Im Unterschied zu damals war allerdings die Möglichkeiten wohl deutlich geringer gegeben, das zu steuern. Nicht nur, weil sich in Sachen Speichermanangement seit dieser Zeit eine Menge verändert hat, Games heute idR intelligent den Dateninhalt streamen, GPUs auch im VRAM Limit noch brauchbar funktionieren und es eine Logik im Treiber gibt, die anhand von definierten Mustern versucht, alte Daten rauszuputzen.
http://www.amd.com/Documents/HyperMemory_Whitepaper.pdf
Im Widerspruch dazu steht aber die technische Funktionsweise eines Caches. Der soll schnell Daten bereit stellen bzw. halten. Und das funktioniert auch nur dann, wenn die Daten entsprechend dort überhaupt drin sind. HBCC geht, so ist es im Moment anzunehmen den komplett anderen Weg. AMD möchte möglichst wenig Daten lokal bei der GPU halten und stattdessen den RAM dafür nutzen. Das Problem, was sich daraus ergibt -> ist exakt das gleiche, wie damals mit dem HyperMemory/TurboCache Verfahren. Die Software MUSS wissen, was für Daten demnächst benötigt werden, damit diese über den schmalen PCIe Slot nachgeladen werden können. Denn was definitiv und nachweislich der Fall ist -> im VRAM Limit, also wenn die Szene Texturen benötigt, die nicht im lokalen VRAM vorhanden sind, dann bringt die FPS Rate ein, Nachladeruckler sind die Folge, FPS dauerhaft niedriger sind der nächste Schritt und Standbilder im Unspielbarkeitsbereich ist Stufe 3. Dies ändert auch HBCC nicht bzw. HBCC ändert an diesem Grundproblem nix.
Wünschenswert wäre aus meiner Sicht hier, wenn man sich auf einen gemeinsamen Nenner einigt, der dafür sorgt, bspw. einen gemeinsamen Ansatz zu fahren um Speicherlastige Texturdaten in zukünftigen Games nicht mehr zentral im VRAM halten zu müssen, sondern einfach aus dem RAM nachlädt, wenn benötigt. Ich denke aber, HBCC verfolgt hier einen anderen Ansatz, nämlich dass die Softwareentwickler dazu animiert werden, genau diesen Job selbst zu tun... Man schauen, wie das am Ende aufgeht. Vom HyperMemory/TurboCache Ansatz ließt man heute gar nix mehr
Und beide Begriffe wurden eher mit LowEnd Karten in Verbindung gebracht -> dabei ist/war genau dieser Ansatz eigentlich vom technischen her der Urvater vom HBCC und natürlich auch vom "modernen" VRAM MGMT heutiger Modelle... Man möchte nur hoffen, dass man diese Technik diesmal annimmt. Denn damals hat das nicht gefruchtet
Ich kann dir heute schon sagen, was passieren wird... Vega kommt auf den Markt, die Redaktionen und vor allem die User werden HBCC auf Herz und Nieren prüfen und alles dran setzen den Punkt zu kreieren, wo die Funktionsweise umkippt. Dann wird man die Ergebnisse rumposauen. Während die eine Fraktion das Thema als den Supergau aufhängt, kommt die andere Fraktion und wird irgendwas von Treiberoptimierung und Zukunft erzählen. -> im Endeffekt eine typische AMD Story
