Diskussion zu: Hardware- und Nachrichten-Links des 19./20. August 2017

[Leonidas]

Link zur News:
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-1920-august-2017

[y33H@]

Eventuell bringt Intel zur Coffee-Lake-Ankündigung am Montag um 17 Uhr (Livestreams bei Facebook & Intel) sogar eine offizielle Preisliste mitDas war nie Coffee Lake, sondern Kaby Lake Refresh ... alleine das Bild mit 8th Gen und dem Ultrabook sagt alles aus.

[Gast Ritis]

Der HBCC ist in der Einführung der Technik schon etwas seltsam. Es ist klar, dass das mit 8GB VRAM bei aktuellen Games ein Null-Summen Spiel ist. Höchstens bei irgend welchen Extrem-Texture-Mods weit über 8GB Bedarf könnte wohl ein relevanter Effekt messbar werden.

Wenn es also noch nichts bringen kann würde ich an Stelle AMD das auch deaktivieren, im Zweifel spart man sich unerwartete Bug-Reports solange man noch wichtige Treiber-Baustellen hat.
Viele der Vega-Teaser sind IMHO auch wirklich nur an die Developer-Gemeinde gerichtet und nicht unbedingt Signal an die Gamer gewesen, Rapid Packed Math und Primitive Shader z.B...

Ich hatte fest mit Vega-Varianten mit nur 4GB gerechnet, da HBCC das komplett kompensieren könnte. Vielleicht kommt ja mit den Vega 56 noch ein entsprechendes SKU.
Ansonsten wird man wohl erst mit den APUs vom HBCC profitieren können, sofern diese auf einen Cache-Bereich zugreifen können, SRAM oder HBM2. Es ist ohnehin noch nicht klar, warum beim Vega der HBCC, HBM und eigentliche GPU-Teil via IF verknüpft sind. Es liegt zumindest nahe, dass die neuen APUs aus Vega und Zen mittels IF "zusammengeklebt" werden. AFAIK haben die zumindest heute schon die Option für gleichen/geteilten HW-Adressraum im RAM. Die Frage ist dann nur wie viel Fläche und Wärmebudget unter dem AM4-Heatspreader für so eine APU genutzt werden kann, womöglich braucht es für HBM Varianten der APUs erst den 7nm Prozess...

[MrSpadge]

Ein Coffee Lake X klingt gar nicht so inwahrscheinlich: sie haben die Hardware und die Erfahrung + BIOS-Entwicklung aus dem KBL-X Umbau. Und wenn der 6-Kerner mit höherer TDP noch mal ordentlich Basistakt drauf legen kann, dann dürfte er sogar den SKL-X 8-Kerner in den Anwendungsbereichen überholen, die SKL-X nicht gut liegen. Und nebenbei wenigstens deutlich messbar etwas auf CFL Desktop drauflegen, also deutlich sinnvoller als KBL-X werden.

MrS

[N0Thing]

Dies funktioniert bislang ohne bemerkbare Einschränkungen, Fehler oder gar Performanceverluste – vielmehr steigt die Performance laut den Messungen der PCGH sogar minimal. Die Prüfung der eigentlichen Feature-Eigung – das Hochhalten der Performance und vor allem der Minimum-Frameraten auch bei Grafikkartenspeicher-Mangel – war bei diesen Benchmarks allerdings nicht möglich, dafür braucht man sicherlich Vega-Grafikkarten unterhalb von 8 GB Speicher-Bestückung. Irritierend nur, das AMD das Feature nicht generell freischaltet – und gerade das Argument, das man hierzu noch Erfahrungen sammeln will, zieht wenig, denn diese Erfahrungen würden sich bei einer Freischaltung für die Anwender viel eher ergeben als denn allein über die Messungen in AMDs Laboren.

Andere Redaktionen kommen auch zu teilweise abweichenden Ergebnissen, was die Vor- und Nachteile von HBCC betrifft.

Bei Computerbase (https://www.computerbase.de/2017-08/radeon-rx-vega-64-56-test/7/#abschnitt_hbcc_hat_im_schnitt_weder_vor_noch_nachteile) kommt im Schnitt ein Gleichstand heraus, allerdings bedingt durch einige negative Ausreißer:

Warum AMD die Funktion noch nicht von sich aus aktiviert hat, zeigt sich wiederum in den einzelnen Spielen. Es gibt viel Spiele, die sowohl bei den FPS als auch bei den Frametimes profitieren, Ausnahmen wie Anno 2205, Ashes of the Singularity, Doom und insbesondere Battlefield 1 machen diesen Vorteil im Durchschnitt aber wieder zunichte. Werden die problematischen Titel aus den Ratings genommen, steigen die FPS durch HBCC um ein Prozent, die 99-Percentile-Frametimes hingegen sogar um drei Prozent.

[Gast Ritis]

..
Bei Computerbase (https://www.computerbase.de/2017-08/radeon-rx-vega-64-56-test/7/#abschnitt_hbcc_hat_im_schnitt_weder_vor_noch_nachteile) kommt im Schnitt ein Gleichstand heraus, allerdings bedingt durch einige negative Ausreißer:
Bei AotS ist die Min FPS deutlich gestiegen wobei durschnittliche FPS arg gesunken sind. Das arbeitet wohl gegen den Gamecode, aber ich würde mehr Min FPS bevorzugen.

Aber diese Tests zeigen eines: Überall wo die Min-FPS durch HBCC merklich ansteigen liegt noch Potential für die Optimierung im Gamecode oder allenfalls Treibern vor, auch für andere Architekturen. Denn dass ein generischer Caching-Algorithmus für das Nachladen von Sourcen besser funktioniert als Handoptimierter Code sollte eigentlich nicht sein, ein Coder müsste besser wissen wann vor den hohen Belastungen die GPU gerade den RAM nicht so intensiv benötigt.

[Gast]

HBCC kann nicht der heilige Gral sein. Die Entwickler der Anwendung müssen schon so optimieren das Daten im System RAM vorgehalten werden, also async während der Laufzeit von der Platte geladen oder generiert werden um sie bei bedarf in den Grafik RAM zu verschieben, und dort die Daten wiederum in den System RAM verschieben die nicht mehr gebraucht werden. Woher soll der HBCC denn wissen welche Daten später gebraucht werden, welche komplett obsolet sind und welche jetzt benötigt werden. Das es so mal zu mehr und mal weniger FPS kommt ist doch klar. Es ist ja mehr Zufall als Logik das der HBCC die richtige Entscheidung trifft. ^^ Dazu kommt das die Bandbreite und Latenz zwischen GPU und System RAM eine wichtige Größe darstellt.

Nvidia hatte doch vor >10 Jahren ähnloches verbrochen. Turbo Cache hieß da der Spaß. Wenn es den HBCC für 2GB RX560/550 und APUs mit 1GB onpackage Grafik RAM geben würde, dann könnte ich es nachvollziehen. Aber diese funktion macht bei Highend 8GB Karten keinen Sinn. Jedenfalls nicht solange sie up to date sind. Wenn es dann zukünftig mal spiele gibt die >8GB voraussetzen um zu starten, dann hat dieses Feature auch bei Spielen eine Daseinsberechtigung.

[HOT]

Leo, da fehlt Cascade Lake. Der kann zwar auch mit 3Dxpoint-RAM umgehen, wird sicherlich aber auch mit DRAM in die normalen Märkte sichern. Das ist grob SkylakeX mit 14FF++.
IcelakeX wird sicherlich erst zum Jahreswechsel 19/20 verfügbar.

[Gast]

HBCC kann nicht der heilige Gral sein. Die Entwickler der Anwendung müssen schon so optimieren das Daten im System RAM vorgehalten werden, also async während der Laufzeit von der Platte geladen oder generiert werden um sie bei bedarf in den Grafik RAM zu verschieben, und dort die Daten wiederum in den System RAM verschieben die nicht mehr gebraucht werden. Woher soll der HBCC denn wissen welche Daten später gebraucht werden, welche komplett obsolet sind und welche jetzt benötigt werden. Das es so mal zu mehr und mal weniger FPS kommt ist doch klar. Es ist ja mehr Zufall als Logik das der HBCC die richtige Entscheidung trifft. ^^ Dazu kommt das die Bandbreite und Latenz zwischen GPU und System RAM eine wichtige Größe darstellt.

Der HBM2 dient lediglich als Cache, als "Hauptspeicherbereich" wird der Arbeitsspeicher genutzt der per Treiber ausgewählt (Größe) und zugewiesen wurde. Der Treiber verschiebt dann die Daten in den Cache (HBM2) die für die Berechung gebraucht werden und hält sie dort vor. HBC ist der Controller und HBCC dann der HBM2. Per Low Lewel oder dx12 kann sich die Hardware selbstständiger verwalten. Dabei wird Spielen die Kontrolle über die Speicherverwaltung komplett entzogen und in Hardware übertragen.

Leider gibt es einen Exclusive und Inclusive Modus für den HBC. Der Inclusive Mod (HBC on und unterstützt) ist nur möglich, soweit er vom Spieleentwickler berücksichtigt wird. Einschalten kannst du das Teil aber völlig nutzlos. Wenn das nicht der Fall ist, bleiben die Performancesteigerungen durch den HBC-HBCC aus. Es wird damit an den Entwicklern liegen, ob es funktioniert oder nicht. Die Zukunft wird es beweisen. Ich denke mal bei Karten über 8GB HBM2 macht der HBC kaum Sinn.

Nach dem Chaos das AMD jetzt auch noch mehrere unterschiedliche SKUs fertigen lässt, sind die zum Teil nicht nutzbaren Feature die doch all so viel Leistung generieren sollen und die man gar nicht gebrauchen kann, einfach nur lächerlich. AMD hat den Lanuch von Vega völlig überhypt und verwachst. Das hätte man den Leuten alles schon längst erklären können.

Video mal angucken, der Kerl hat sowas von recht: https://www.youtube.com/watch?v=Ecepu4BdYeE

Ein Witz alles.

[MrSpadge]

@Gast: du unterschätzt Hardware Cache Controller gewaltig. Ganz einfaches Bsp: von ner detaillierten Textur ist nur ein kleiner Bruchteil zu sehen, der Rest ist verdeckt. Jegliche statische Optimierung kann das nicht vorher wissen und muss die ganze Textur laden. Der HBCC hat die Chance, nur die benötigten Blöcke nachzuladen und VRAM sowie PCIe-Bandbreite zu sparen. Hatte er vorher die gesamte Textur geladen, könnte er bei zusätzlichem Speicherbedarf nun nur den tatsächlich genutzten Teil behalten und den Rest wegwerfen. Ähnliches wird auch in anderen Teilen des Rendervorgangs möglich sein.

MrS

[Gast]

@Gast: du unterschätzt Hardware Cache Controller gewaltig. Ganz einfaches Bsp: von ner detaillierten Textur ist nur ein kleiner Bruchteil zu sehen, der Rest ist verdeckt. Jegliche statische Optimierung kann das nicht vorher wissen und muss die ganze Textur laden. Der HBCC hat die Chance, nur die benötigten Blöcke nachzuladen und VRAM sowie PCIe-Bandbreite zu sparen. Hatte er vorher die gesamte Textur geladen, könnte er bei zusätzlichem Speicherbedarf nun nur den tatsächlich genutzten Teil behalten und den Rest wegwerfen. Ähnliches wird auch in anderen Teilen des Rendervorgangs möglich sein.

MrS

Nichts hindert eine Applikation daran einen Prefetch zu triggern um entsprechende Pages vorzuladen.

[Gast Ritis]

@Gast: du unterschätzt Hardware Cache Controller gewaltig. Ganz einfaches Bsp: von ner detaillierten Textur ist nur ein kleiner Bruchteil zu sehen, der Rest ist verdeckt. Jegliche statische Optimierung kann das nicht vorher wissen und muss die ganze Textur laden. Der HBCC hat die Chance, nur die benötigten Blöcke nachzuladen und VRAM sowie PCIe-Bandbreite zu sparen. Hatte er vorher die gesamte Textur geladen, könnte er bei zusätzlichem Speicherbedarf nun nur den tatsächlich genutzten Teil behalten und den Rest wegwerfen. Ähnliches wird auch in anderen Teilen des Rendervorgangs möglich sein.

MrS

Das sehe ich auch so. Im Micro-Management des VRAMs wird der HBCC Vorteile bringen, wenn viel weniger VRAM vorliegt als in einem Level/Scene/Cave/Submap brutto benötigt.
PCIe ist viel schneller geworden, der RAM ebenso, die Caches je Shadereinheiten grösser und die Render-Pipeline mit relativ viel Shading tiefer. Dort wird künftig ein Coder nur noch gegen die API programmieren können und im Treiber und in HW lässt sich der VRAM besser managen.

Komisch wird es nur wie jetzt bei den Vegas mit 8GB und 16GB VRAM, wenn Spiele mit HBCC weniger Framedrops haben bei denen man eigentlich davon ausgeht, dass diese Games brutto/netto die 8GB gar nicht benötigen oder auch mit 6GB gut auskommen. Wenn HBCC zeigt, dass dort im Min-FPS 10-20% mehr geht sollte das händisch auch möglich sein, wenn der VRAM ohnehin gross genug ist.

Was man noch nicht weiss ist ob der HBCC bei Games nur das Mapping zwischen RAM und VRAM macht, oder ob der auch Flushes und Preloads in den lokalen Caches der GPU forciert. Kann ich mir aber jetzt erst mal nicht vorstellen. Da AMD in den Slides den L2 direkt auch an PCIe verbunden hat könnte zumindest ein direktes Laden in den L2 mit WriteBack in HBC gemeint sein.

Im Kern waren die Aussagen zu HBCC aber immer nur es als typischer Last-Level-Cache zu verstehen mit Gewinnen durch Segmentierung der Speicherobjekte und Vermeidung von Overhead im VRAM. Aber auch als Cache nicht nur für den RAM sondern eben auch zu den SSD- und Netzwerkressourcen... Der Vorteil wäre am Ende dass der Coder nur noch gegen die API programmiert und sich nicht mehr um das VRAM Management kümmert....

[MrSpadge]

Nichts hindert die Applikation daran... außer Zeit des Programmierers, Komplexität und Latenz. Um sowas zu implementieren müsste man sich ja im CPU-Thread erstmal die Ergebnisse des Geometrie-Setups etc. der GPU über den PCIe holen, auswerten (welche Teile welcher Ressourcen werden gebraucht?) und die entsprechenden Daten über den PCIe zurückschicken. Bis das fertig ist hat die GPU schon die nächsten beiden Bilder gemalt. Die GPU hat diese Infos jedoch direkt vorliegen - deshalb überlasst man auch in CPUs das Cache-Management der Hardware, bis auf ein paar grobe (prefetch) Vorgaben.

MrS