T
Teralios
Gast
Ich denke nicht, dass PCIe hier direkt der »Flaschenhals« ist, denn im Endeffekt kann man mit intelligentem Preload der Daten später sich nur noch auf die geänderten Teile konzentrieren und die Anweisungen fürs Rendern laufen ja eh.GerryB schrieb:Positiv ist, das anscheinend auch PCiE 3.0 schnell genug ist.
PCIe4 16x zeigt gegenüber PCIe3 16x ja auch nur in bestimmten Szenarien ein Vorteil. Ich hab es - ohne vollständige Messung - bisher nur in Skyrim SE mit sehr vielen Mods sowie Fallout 4 mit sehr vielen Mods nachstellen können. Beide Spiele mit entsprechend grafischen Mods profitieren von PCIe4 auf einer 5700 XT, weil bei unerwarteten »Assets« diese schneller in VRAM liegen, als unter PCIe.
Wenn ich SAM richtig deute, und damit bin ich ja nicht alleine, geht es primär darum, dass man nun relativ einfach den gesamten VRAM sehen kann und ansprechen kann. Wir wissen das die BAR 32 Bit, wovon aber nur 28 Bit für die Adressen zur Verfügung stehen. Man muss hier also auf der BAR mit »Indikatoren« arbeiten um den richtigen RAM zu verwalten usw. SAM reduziert halt diese Abfragen schon gewaltig.
Mal schauen was kommt, hoffe wir drei haben genug Wirbel gemacht, dass AMD endlich etwas mehr rausgibt. Oder irgendein Treiberentwickler aus Linux, auch gerne mit Fingerklopfen für mich. Nur so wird man besser!ZeroStrat schrieb:Ich bin wirklich mal gespannt, wie sich das mit dem Zen 2 Support noch entwickelt.
Dass wiederum wundert mich nicht, dass es primär im CPU-Limit Wirkung zeigt. Wenn ich mir unter Windows die WDDMv2-Doku ansehe, dann wird der VRAM vom Treiber verwaltet und wenn man da dank der 32Bit-BAR immer nur 256MB Happen verarbeitet kann, dann fallen da ja einige Abfragen weg.ZeroStrat schrieb:Was ich ja auch stets faszinierend finde, ist die Tatsache, dass SAM eher im CPU-Limit Wirkung zeigt. Es muss also letztlich etwas sein, dass auf der CPU passiert