hUMA hilft beispielsweise beim Einsatz von Megatexturing enorm, sorgt also dafür, dass, wenn diese Features eingesetzt werden, die FPS eben nicht abfallen. Grad bei großen Datentransfers zwischen CPU und GPU limitiert bei hUMA nichts, was die Programmierung vereinfacht und nicht verkompliziert, darum geht es bei HSA - Einsatz möglichst aller Ressourcen bei redziertem Entwicklungsaufwand.
Die Frage ist doch, an welcher Stelle wird der hUMA Vorteil potentiel ansetzen!?
Wenn man das mal nüchtern betrachtet, ist es doch alles eine Frage, wo die Quelle liegt. Speziell auf dein Beispiel bezogen heist das, der Vorgang, die Daten in den "VRAM" zu schaufeln, würde durch hUMA und die entfallende Datenübertragung zwischen RAM und VRAM Bereich beschleunigt werden. Nur was passiert, wenn die Daten einmal im VRAM sind? -> dann hilft hUMA nicht mehr... Da einzig und allein die Zugriffsgeschwindigkeit auf den Speicher zählt.
Der Knackpunkt an der ganzen Geschichte ist aber aus meiner Sicht folgender:
Der VRAM ist genau dafür da, Daten schnell verfügbar zu machen. Das heist folglich auch, das die Daten dort möglichst lange gehalten werden sollten. (was sie in der Praxis scheinbar auch tun) Somit würde zwar hUMA auf dem Papier einen Vorteil bieten, aber genau dort, wo der VRAM seinen eigentlichen "Sinn" ausspielt, keine Vorteile mehr bereitstellen können. Denn die Daten sind schon dort, wo man den schnellsten Zugriff drauf hat.
Um nochmal konkret auf dein Beispiel zurück zu kommen. Normal sollte es doch so sein, diese besagten Daten kommen irgendwo am Anfang von der HDD, wandern in den RAM und werden (bei aktueller Umsetzung) vom RAM in den VRAM übertragen. Auf der APU kostet letzteres Bandbreite, die so schon knapp ist. hUMA würde also genau dort zwar auf dem Papier einen Vorteil bringen, wenn sich die "Ausführungseinheiten" für die 3D Berechnung permanent aus dem RAM bedienen müssten. -> dies sollte in der Praxis aber nur dann beim spielen eintreten, wenn der VRAM Bereich entweder zu klein ist (um alle benötigten Daten zu fassen) oder wenn sich permanent die Daten derart ändert, das von irgendwo extern nachgeladen werden muss.
Ersteres kann man ausschließen, indem man einfach mehr VRAM deklariert und letzteres? Neja, kommt faktisch nie vor. Zumal sich dann immernoch die Frage stellt, woher stammen die Daten. hUMA greift ja erst, wenn diese im RAM liegen. Kommen sie von der HDD/SSD, gibts immernoch massivste Leistungsverluste durch noch deutlich langsamere Zugriffe. Es bleibt also darauf aufbauend die Frage, warum liegen die Daten also nur im RAM und nicht im VRAM? Aus meiner Sicht ist in dieser Konstellation also der VRAM Bereich zu klein gewählt wurden, da scheinbar potentiell genügend RAM an der APU steckt um die Daten im RAM zwischen zu puffern.
-> heist also weiterhin, wählt man hier mehr VRAM Größe (bis die Daten dort alle reinpassen), müssen die Daten nur einmalig dorthin übertragen werden. Und dann hat man schlicht vollen Zugriffsspeed, den die Hardware bereit zu stellen im Stande ist. Und der Initialdatenimport in den VRAM Bereich geschieht idR beim Spielstart und überträgt gefühlt/geschätzt 90-95% der benötigten Daten direkt in den VRAM.