Na habe ich aber beruflich mit WebGL und OpenGLES Erfahrung aber doch was entgegenzusetzen. Ich weiß schon gut genug wie wo was ich in den Speicher werfe.
Das ist dann aber doch schon etwas anders als in Spielen...
Denn idR sitzt da noch der Treiber dazwischen, der einfach mal steuert, wie das Speichermanagement abläuft. Wenn du als Entwickler sagst, die Daten fliegen aus dem VRAM raus, dann fliegen sie raus. Wenn der Entwickler dies aber nicht tut, dann bleiben sie drin. Was nun, wenn der Speicher voll wird? -> man kümmert sich mit mehr oder weniger intelligenten Mechanismen darum, unwichtige/alte Daten aus dem Speicher zu werfen, damit man für andere Daten Platz schafft. Die Daten fliegen dabei idR auch nicht direkt aus dem VRAM, sondern wandern in eine Art Swapbereich (früher im Rivatuner mit XP und einer ATI GPU schimpfte sich das bspw. non local VRAM), heute sieht man die gesamte Größe bspw. in den Eigenschaften der Grafikkarte.
Unterm Strich muss das aber alles überhaupt nichts bedeuten. Denn es sagt einfach absolut gar nichts darüber aus, welche Daten auch wirklich zur Laufzeit benötigt werden... Und hier kommt der Knackpunkt. Dies ist die große Unbekannte. Um so besser diese Technik funktioniert, desto näher kommt man an das Optimum der minimalen Speicherbelegung herran. Die Frage ist allerdings, will man das überhaupt? Speicher ist dafür da, benutzt zu werden... Jedes Bit, was nicht im Speicher ist und bei Bedarf hinein transferiert werden muss, kostet Zeit... Wäre es schon drin, würde es keine Zeit kosten, dieses erst reinzutransferieren. Und der Anteil der Zeit zwischen GPU und VRAM ist dabei keineswegs der Großteil besagter Zeit. Denn der Großteil kommt von RAM über PCIe zu GPU.
Sehr witzig finde ich hier im Thread mal wieder das hin und her der Leute... Erst war wenig VRAM Belegung das bessere Speichermanagement, dann mal wieder mehr (nämlich dort, wo NV deutlich am VRAM gegeizt hat, G92 512MB, G200 1GB, GF100 1,5GB und auch GK104 mit 2GB) -> jetzt "geizt" AMD am HBM Speicher, weil es technisch offenbar nicht anders geht und auf einmal ist weniger Belegung wieder "besser"
-> das gleiche trifft anderesrum natürlich ebenso auf die Gegenfraktion zu...
Prinzipiell richtig.Aber das Vermögen den vollen Speicher auszugeben und wieder mit neuen Daten zu füllen macht die Musik.Und das kann HBM besser als GDDR5.
Speicher wird nicht "ausgegeben"...
Speicher ist dafür da um Daten aufzunehmen und diese bei Bedarf wieder abzugeben. In erster Linie zählt der Speed dessen, das ist richtig. Aber wenn Voll dann Voll. Und bei Bedarf > Kapazität ist das nunmal kein Problem mehr der Speichergeschwindigkeit, sondern ein Problem des Speichermanagements sowie der Anbindung des Auslagerungspools.
Du erwähnst oben, dass Speicher voll machen und wieder zu leeren ein Märchen ist obwohl dies eigentlich permanent gemacht wird. Es gab mal Zeiten, bei denen Speicher nicht im Überfluss verfügbar war. Manche meinen, dass man damals noch sauber programmieren musste.
HBM hat hier durchaus einen vorteil weil die Bandbreite hier von Vorteil ist.
Kennst du Spiele, die wirktlich den Speicher leeren und neubefüllen? Während der Laufzeit, einfach so mittem im Level ohne Ladepunkt oder ähnlichem??
Ich kenne genau ein einziges -> Anno 1701. Und das auch nur auf einer ATI Hardware von damals. Höchstwarscheinlich aber auch nur ein Management Thema, denn mit einer NV Karte der damaligen Zeit sah man das Verhalten nicht!
Das Problem hier ist, alle Welt geht davon aus, das nur die Speicherbandbreite in Problem ist. Grundsätzlich richtig im normalen Workload -> aber im Limit ist das Problem die PCIe Anbindung. 16GB/sec sind und bleiben 16GB/sec -> Ob da nun die GPU mit 500GB/sec+ in den Speicher kommunizieren kann oder nicht, völlig egal, die Daten passen nicht alle rein und es muss über den PCIe Slot nachgeladen werden.
HBM ist nicht effizient ... es ist eine andere Methode. DDR3 ist auch nicht effizienter als DDR2 Speicher aber lassen wir das.
Doch ist er... Ca. Faktor 3-4 in Messungen von Bandbreite/Watt ggf. GDDR5.
Das Problem ist, bei 4GB hat man schon 500GB/sec+. Man hat also Bandbreite, die möglicherweise einfach verpufft. Bei GDDR5 baut man entsprechend ein schmaleres Interface drauf und verbraucht damit weniger. Bei HBM kannst du aktuell nur sparen indem du weniger Menge drauf baust.
Dies wird sich ändern, wenn es HBM Stacks mit variabler Größe gibt. Bis 32GB ist im Programm... Dann lässt sich möglichweise auch mit zwei Stacks bei vierfacher Menge pro Stack immernoch 8GB verbauen und man hätte mit 250GB/sec+ auch eine Bandbreite, die eher zum Bedarf passt -> oder mit drei Stacks und 6 oder 12GB bei ~375GB/sec.
ist exakt der gleiche Chip und das mit dem Verbrauch kann jeder Hans sogar noch besser einstellen als es AMD getan hat, Stichwort Spannungsoptimierung
+1 für Elkinator! Allein schon die Alliteration auf Terminator ... oh man 
jemand mit Verstand, ich gab die Hoffnung schon auf ^^
