SYSMEM - VRAM - BAR Uploads [Archiv]

pixeljetstream

2020-11-15, 13:21:54

Aus aktuellem Anlass...
bitte keine Schlammschlacht wie in den anderen Threads.
Das ganze soll nur als technisches FYI dienen, aus SW Entwicklersicht, also wie man die API nutzt und was Vor-/Nachteile sind, die Details zum Bus sind nicht so mein Ding.

API Standard
============

Der Standardweg in den APIs Daten auf die GPU zu bekommen ist im SYSRAM Speicher zu haben, der von der CPU geschrieben und von der GPU gelesen werden kann. Der Speicher wird durch die API vom Treiber angelegt.

CPU schreibt -> SYSMEM -> GPU liest / konvertiert -> VRAM (ideal fuer mehrfachen Zugriff/Benutzung)

Da Texturdaten fuer gewoehnlich in einem herstellerspezifischem Format (optimiert fuer lokale Kohaerenz) gespeichert sind, kann man diese nicht direkt schreiben, sondern ueberlaesst der copy-engine auf der GPU die Format konvertierung (linear zu tiled). Man hat also die Daten linear in dem SYSRAM Buffer und die GPU kopiert und konvertiert dabei direkt in den VRAM Buffer. Auch bei den meisten linearen Bufferdaten die viele frames verwendet werden (Vertex, Index etc.) benutzt man das gleiche Prozedere. Die GPUs verfuegen heute ueber mehrere so asynchrone Copy Engines, so dass man parallel uploads/readback handlen kann.

CPU schreibt -> SYSMEM -> GPU liest direkt bei Benutzung (typischerweise einmal lesen oder kleine Daten die sich gut im Cache halten)

Aber auch ohne Copy Engine kann die GPU direkt auf SYSMEM zugreifen, das macht man bei Daten die sich jeden Frame aendern. Sagen wir also die CPU schreibt Kameramatrixdaten, oder Partikeldaten als Stream raus, die werden eh nur "einmal" von der GPU gelesen (beim Rendern) und dann auch noch in einem ziemlich linearen Zugriff der sich gut auf der GPU in den lokalen Caches haelt. In dem Fall kann man sich die Kopie in einen VRAM Buffer sparen.

(in Zukunft soll neben SYSMEM noch der lesende Zugriff auf Dateien unter gewissen Bedingungen folgen, DirectStorage etc.)

BAR - Memory
============
CPU schreibt -> VRAM

Hier kann die CPU direkt die per-frame Daten in den VRAM reinschreiben. Das ist gut fuer die Art von Zugriffen, die nicht ganz so linear sind, oder wenn die gleichen Daten doch mehrfach im gleichen Frame verwendet werden. Bei letzteren ist der klassische (obige Ansatz) Ansatz nicht so gut, weil sich der BUS transfer bei "cache-miss" bis die daten dann wieder im Cache sind, allzu negativ auf latenzen auswirkt.

Das Problem ist nun das dieser Heaptyp im Moment relativ klein ist eben nur 256 MB. Erst mit den neuren BAR Features, resizeable bar, 64-bit, main board BIOS, gpu bios, OS etc. geht hier mehr (das ist dann ne Frage dessen was die Hersteller an Kombinationen offiziell unterstuetzen/ testen / garantieren wollen, wie iscaran schon paar Mal im Forum schrieb ist das trotz Standards nicht unbedingt ein einfacher Selbstlaeufer).

256 MB an sich sind nicht immer soo schlimm (sagen wir bei double buffering sind das auch schon 128 MB * 100 Hz an traffic). Die Vulkantitel profitieren ja selbst bei der Menge schon, und am Ende transferiert man ja nicht wahnsinnig viele Mengen ueber diesen Weg (persistene Daten etc. sind ja eh anders) und nicht jedes Zugriffspattern profitiert.

Etwas doofer dagegen ist dass sich alle Applikationen diese 256 MB Teilen, ergo N Mal das Spiel starten ist nicht so prickelnd, wobei das bei Gaming nicht ganz so oft zutrifft.

Vulkan
------
Vulkan exponiert einen optionalen Heaptyp der im VRAM liegt aber von der CPU geschrieben werden kann.

AMD hatte das etwas frueher als NV in ihrem Treiber. Das hatte bei NV dann dazu gefuehrt dass ein paar Vulkan Titel, die so progammiert waren um diesen Heap zu nutzen auch ein paar Prozent zulegten ab gewissen Treiberversionen. Ergo das gibt es bereits fuer heutige GPUs und CPUs beider Lager.

DX12
----
Der im Moment (Zeitpunkt dieser Nachricht) wichtigere Punkt ist aber das DX12 diese Unterscheidung zwischen CPU-schreibbaren VRAM und SYSMEM gar nicht hat (ausser embedded). Es gibt nur einen "upload" Heaptyp. Der Treiber muesste also per Heuristik rauskriegen welche Allokationen den BAR memory nutzen sollten und welche nicht (was deutlich leichter ist wenn das Limit nicht so klein ist). Was auch dadurch verkompliziert wird das im gleichen API-Memory Daten liegen koennten die davon profiteren und andere die es nicht tun (zum Zeitpunkt der Allokation so direkt nicht bekannt, und nicht ganz im Sinne der neuen APIs). Solange die DX12 API dies nicht explizit kann, also wie Vulkan der Entwickler sagen kann was nun direkt profitiert und was nicht, muss der Grafik-Treiber also aktiv eingreifen und gut schaetzen um das ganze sinnvoll zu nutzen.

Iscaran

2020-11-15, 13:59:00

Interessant:

BAR - Memory
============
CPU schreibt -> VRAM

Hier kann die CPU direkt die per-frame Daten in den VRAM reinschreiben, was gut fuer die Art von Zugriffen is, die nicht ganz so linear sind, oder wenn die gleichen Daten doch mehrfach im gleichen Frame verwendet werden, und dabei sich der "erste/cache-miss" BUS-transfer bis die daten dann wieder im Cache sind, allzu negativ auf latenzen auswirkt.

Das könnte ja evtl. erklären warum das SAM-Feature (Smart Access Memory) von AMD erst jetzt in Kombination mit Infinity Cache kommt. Evtl. kommt der Performance Boost von SAM erst durch die Verbesserte Cache-Steuerung durch das BAR zustande ?

Liest sich zumindest ein bisschen so, wie du es erläuterst.

Btw. Übrigens sehr gute Idee dazu ein eigenen Topic aufzumachen der das alles sammelt !

anddill

2020-11-15, 14:09:52

Danke für die Erklärung, auch wenn ich davon nur ca. 77,2% verstanden habe.
Also kommt der Gewinn nicht dadurch zustande, daß man den Overhead verringert, indem man größere Datenblöcke in einem Rutsch auf die GPU wuppen kann, ohne das in 256MB Häppchen zu zerlegen.
Sondern dadurch daß man den Overhead direkt verringert, und Kleinkram statt erst ins Übergabefenster zur Selbstabholung zu packen direkt an die richtige Stelle im Grafikspeicher schreibt, da man den vollen Bereich direkt von der CPU aus adressieren kann?

Kommt bei den ganzen hübschen Folien überhaupt nicht so rüber.

pixeljetstream

2020-11-15, 14:30:16

Das könnte ja evtl. erklären warum das SAM-Feature (Smart Access Memory) von AMD erst jetzt in Kombination mit Infinity Cache kommt. Evtl. kommt der Performance Boost von SAM erst durch die Verbesserte Cache-Steuerung durch das BAR zustande ?

Da deine Aussage erstmal groesen unabhaengig klingt, meochte ich darauf hinweise dass die Vulkantitel das feature schon auf jetziger hw nutzen koennen und manche das auch tun, nur da gabs halt kein marketing slides fuer paar Prozente ;) Und es ist mit 256 MB im Moment natuerlich nicht ganz so optimal.

Complicated

2020-11-15, 15:28:29

@pixeljetstream
Danke für den Thread und mit dem Intro.

Gast

2020-11-15, 18:49:54

Hallo, danke für die interessanten Einblicke.

Könntest du eventuell auch mal erläutern wie sich das im Zusammenhang mit Direct Storage verhält?

Iscaran

2020-11-15, 19:30:14

Da deine Aussage erstmal groesen unabhaengig klingt, meochte ich darauf hinweise dass die Vulkantitel das feature schon auf jetziger hw nutzen koennen und manche das auch tun, nur da gabs halt kein marketing slides fuer paar Prozente ;) Und es ist mit 256 MB im Moment natuerlich nicht ganz so optimal.

Hmm guter Einwurf...müsste man eigentlich in Benchmarks mit SAM sehen, daß es in Vulkan-Titeln dann nicht ganz soviel bringt ?

Auch interessant, daß in DX12 ja diese RAM Unterscheidung ebenfalls gar nicht mehr hat - aber dennoch IIRC profitierten DX12 Titel mit am meisten von SAM?

Könnte es sein, daß SAM einfach hilft die Datenlokalität deutlich zu erhöhen indem es eine "direktere" Verschaltung von GPU-Treiber und Speicheradressraum des "Games" (/APP) was auch immer, ermöglicht. Und zwar rein "treiberseitig" sozusagen?

Bin kein 3D-Entwickler oder sonstwas Programmierer nur interessierter Laie ;), daher ist vielleicht meine Ausdrucksweise oft sehr schlampig oder inkorrekt.

pixeljetstream

2020-11-15, 21:37:18

Hmm guter Einwurf...müsste man eigentlich in Benchmarks mit SAM sehen, daß es in Vulkan-Titeln dann nicht ganz soviel bringt ?

Auch interessant, daß in DX12 ja diese RAM Unterscheidung ebenfalls gar nicht mehr hat - aber dennoch IIRC profitierten DX12 Titel mit am meisten von SAM?

Wie ich im dx12 Absatz schrieb, hat man im Treiber schon die Möglichkeit den memorytyp dennoch zu nutzen, muss man halt die passenden Optimierungen dafür basteln. Ist halt nicht immer einfach/so robust wie wenn der Entwickler es selbst direkt ordentlich machen kann. Widerspricht bissl den Geist der Low Level APIs aber am Ende zählt eh immer das Ergebnis und hilft beim Design neuer APIs zu wissen worauf man achtet (Vulkan kam ja leicht später als dx12 zum Beispiel).

crux2005

2020-11-15, 22:41:54

Mein 5+ Jahre altes Z170X Gaming G1 hat im Bios die Option "Above 4G decoding". Beschreibung: Enables/Disables 64bit PCIe decoding". Ist das die Voraussetzung für SAM/BAR?

Habe es mal testweise angemacht, erzeugt nur unnötig Ruckler. ;D

pixeljetstream

2020-11-15, 23:27:17

Die 256 MB BAR Variante geht auch ohne besondere Einstellungen. Und alles darüber gibt es im Moment noch nicht in öffentlichen Grafik Treibern. Zu gegebener Zeit werden die Hersteller dazu Details zu den Produkten liefern, bzw. haben dies schon. Darum soll es in dem thread aber imo nicht gehen.

Skysnake

2020-11-16, 01:04:54

Mein 5+ Jahre altes Z170X Gaming G1 hat im Bios die Option "Above 4G decoding". Beschreibung: Enables/Disables 64bit PCIe decoding". Ist die Voraussetzung für SAM/BAR?

Habe es mal testweise angemacht, erzeugt nur unnötig Ruckler. ;D
Das ist die Grundvoraussetzung.

Was der Treiber am Ende daraus macht ist ne andere Frage.

Iscaran

2020-11-16, 09:40:10

Btw....hier bei Intel gibts eine VOLLSTÄNDIGE PCIe v2.1 Specification zum Ansehen und Lesen :-).

Wer sich tiefer mit der Materie auskennt kann da vielleicht ein paar relevante Infos zu den Anforderungen finden die es benötigt BAR (oder AMDs SAM) umzusetzen:

https://www.intel.com/content/dam/altera-www/global/en_US/uploads/e/e2/PCI_Express_Base_r2.1.pdf

Iscaran

2020-11-16, 09:45:41

https://www.pugetsystems.com/labs/hpc/Will-your-motherboard-work-with-Intel-Xeon-Phi-490/
Puget hat 2013 BAR auf Xeon Phis testen wollen. Ergebnis - es hat nicht funktioniert bzw. was gebracht, weil...*trommelwirbel* die Validierung an allen dafür notwendigen Stellen nicht klappte:

The bottom line is, unless your vendor has validated a specific board for use with the Xeon Phi then don't expect it to work ... I wish it wasn't so.

AMD SAM: "We validated that feature on ..... systems"

Iscaran

2020-11-16, 11:44:13

Offensichtlich ist auch (EDIT: funktionierendes, performance bringendes /EDIT) BAR unter Linux kein einfacher selbstläufer - und es ist nicht "schlicht" eine BIOS-Option:

https://gitlab.freedesktop.org/drm/amd/-/issues/1039
Womöglich ein Grund warum AMD hier den "Marketing-Namen" SAM gewählt hat und dieses auch nur recht strikt validiert/umsetzt?

Dort gibt es auch einen weiterführenden Link zu einer Ursache des Problems:

Maybe the behavior of the BIOS which is described in the following patch is at fault here?
"Even with the "Above 4G decoding" (or similar) BIOS option enabled,
many BIOS do not assign the PCI root bus a 64-bit address space.

Patch-Link: https://lists.freedesktop.org/archives/amd-gfx/2020-May/049748.html

Gast

2020-11-16, 21:42:30

Ich gehe davon aus, dass AMD das alles nur mit X570, Ryzen 5000 und RDNA2-Karten validiert hat, es aber prinzipiell auch mit aelteren Konfigurationen gehen wuerde.

Das freizuschalten ist aber wahrscheinlich ein Albtraum, einfach weil die Anzahl der ungetesteten Permutationen so gigantisch ist bei PCs.

Gast

2020-11-17, 10:20:35

Wie ich im dx12 Absatz schrieb, hat man im Treiber schon die Möglichkeit den memorytyp dennoch zu nutzen, muss man halt die passenden Optimierungen dafür basteln. Ist halt nicht immer einfach/so robust wie wenn der Entwickler es selbst direkt ordentlich machen kann. Widerspricht bissl den Geist der Low Level APIs aber am Ende zählt eh immer das Ergebnis und hilft beim Design neuer APIs zu wissen worauf man achtet (Vulkan kam ja leicht später als dx12 zum Beispiel).

Ist das überhaupt noch relevant, wenn Features wie SAM, oder wie es bei NV auch immer heißen wird, aktiv sind?

Weil so wie ich es verstehe gibt es dann die Unterscheidung "CPU Adressable VRAM" und den Rest nicht mehr, weil der gesamte VRAM "CPU Adressable" ist.

Iscaran

2020-11-17, 13:41:08

Complicated

2020-11-17, 15:19:26

Das stammt aus Anandtechs Artikel und zeigt neue Integer-Instruktionen die Zen 2 noch nicht hatte. Die wurde implementiert, hat aber IMHO mit SAM nichts zu tun, da ISA:
Hier die gesamte Übersicht neuer Instruktionen bei Zen 3:
https://www.anandtech.com/show/16214/amd-zen-3-ryzen-deep-dive-review-5950x-5900x-5800x-and-5700x-tested/6
It’s worth highlighting those last two commands. Software that helps the prefetchers, due to how AMD has arranged the branch predictors, can now process three prefetch commands per cycle. The other element is the introduction of a hardware accelerator with parallel bits: latency is reduced 99% and throughput is up 250x. If anyone asks why we ever need extra transistors for modern CPUs, it’s for things like this.

Edit:
Ich denke aber, dass diese Folie die QoS Elemente enthalten könnte, welche das SAM unterstützen - da wäre Zen2 IMHO ebenfalls gut aufgestellt wenn das zuträfe:

https://images.anandtech.com/doci/16214/Ryzen%205000%20Series%20Tech%20Day%20-%20Zen%203%20Architecture%20-%20Deep%20Dive-page-026.jpg

pixeljetstream

2020-11-17, 18:39:20

Ist das überhaupt noch relevant, wenn Features wie SAM, oder wie es bei NV auch immer heißen wird, aktiv sind?

Weil so wie ich es verstehe gibt es dann die Unterscheidung "CPU Adressable VRAM" und den Rest nicht mehr, weil der gesamte VRAM "CPU Adressable" ist.
Einmal liegen die Daten im RAM das andere Mal im VRAM. Ist schon ein Unterschied. IMO sollte man nicht pauschal alles im VRAM ablegen (wobei das je nach Titel vermutlich auch okay ist, solange Platz ist).

pixeljetstream

2020-11-17, 18:41:57

https://twitter.com/SebAaltonen/status/1327191532177420288

Was ist davon zu halten bzgl. der Limitierung auf Zen3 ?
Kann es mit den Latenzen zu tun haben ?

Immerhin gab es ja auch eine deutlich Veränderung der CPU cores zw. Zen2 und Zen3
https://www.reddit.com/r/Amd/comments/jt1hr5/a_zen_3_core_is_14_larger_than_a_zen2_core_324mm%C2%B2/
Sebastian twitterte später das es eh nicht so gut bestellt ist um Standard tiling Support bei Texturen, ergo ist das eher was für Konsolen, oder Treiber intern. Ich twitterte selbst dazu dass er mit den 256 MB vermutlich auch experimentieren kann in vk weil Texturdaten eh nicht gehen.

Iscaran

2020-11-17, 19:58:28

Hmm, mein Japanisch ist zu schlecht und die eher schwierige Google Übersetzung machts kaum besser - aber jemand wie ihr mit dem technischen Know-How kann vielleicht mehr damit anfangen.
https://translate.googleusercontent.com/translate_c?depth=2&pto=aue&rurl=translate.google.com&sl=auto&sp=nmt4&tl=de&u=https://www.coelacanth-dream.com/posts/2020/11/05/linux-amd-smart-access-memory/&usg=ALkJrhjw5e8tyan3wcw1rhsHa5ck-dmDNg

Ryzen 2600 + RX560 unter Linux mit resizable BAR "aktiviert" => in 1 von 3 theoretischen Benchmarks +12% - in anderen +- 0-1%.

Iscaran

2020-11-17, 20:00:28

@Complicated:

Das QOS ding klingt mir eher nach "Optimierungen" bzgl. Infinity Cache:
"Enforcement of L3 Cache occupancy"...wie erhöht man die Hitrate im Cache nochmal ? Indem man dafür sorgt dass die CUs "wissen" was bei anderen CUs so im Cache liegt oder so ?

Iscaran

2020-11-18, 16:22:30

Ist vielleicht doch ein bisschen mehr "Secret Sauce" in SAM enhalten als simples resizable BAR ?
https://www.pcgameshardware.de/Radeon-RX-6800-Grafikkarte-276952/Specials/Smart-Access-Memory-Benchmarks-1361997/

SAM bringt mal 10-12%, dann wieder nur 2-3% oder 0%.
Es liegt auch nicht an DX12 vs DX11 vs Vulkan oder so.

Dachte erst es wäre so: Vulkan +-0, DX11 +-2-3%, DX12 +-10%.
Ist es aber nicht, AC-Valhalla DX12 Titel gewinnt +11% mit SAM, Dirt 5 aber nur 3-4%exakt 0%.
Vulkan ebenso, Doom ca 1%, Red dead redemption dagegen +10%.

Dagegen im CB-Test bestenfalls 1-2% Performance ?!?
https://www.computerbase.de/forum/threads/amd-radeon-rx-6800-xt-im-test-rdna-2-gegen-nvidia-geforce-rtx-3000.1982436/page-14
Speziell Borderlands 3 merkwürdig. AMDs offizielle Marketing-Folien zeigen +5%...und nachdem Sie sonst eigentlich fast exakt das Bild zeigen was die Benchmarks bestätigen wundert das schon ? War SAM @CB evtl. nicht wirklich aktiv ?

Ebenso die seltsamen Ergebnisse mit PCIe v3 (künstlich im BIOS runtergestellt) (bei PCGH).

Complicated

2020-11-18, 16:50:56

Es muss ja auch der passende Workload sein, wo die CPU entsprechend Daten direkt in den GPU-Speicher schreibt.

Dem CB-Test traue ich da auch nicht wirklich über den Weg, da sie das SAM als proprietär bezeichnen. Der Abschnitt hat IMHO nicht viel Aufmerksamkeit bekommen bei denen.

Ich denke das QoS unterstützt auch jegliche Funktion die Kohärenz herstellen muss mit unterschiedlichen Speichern.

pixeljetstream

2020-11-18, 17:03:14

Ist vielleicht doch ein bisschen mehr "Secret Sauce" in SAM enhalten als simples resizable BAR ?
...
SAM bringt mal 10-12%, dann wieder nur 2-3% oder 0%.
Es liegt auch nicht an DX12 vs DX11 vs Vulkan oder so.

Dachte erst es wäre so: Vulkan +-0, DX11 +-2-3%, DX12 +-10%.
Ist es aber nicht, AC-Valhalla DX12 Titel gewinnt +11% mit SAM, Dirt 5 aber nur 3-4%exakt 0%.
Vulkan ebenso, Doom ca 1%, Red dead redemption dagegen +10%.

Es sind mehrere Faktoren.
Am wichtigsten ist das Zugriffsmuster und die Art der Nutzung der Daten auf der GPU (shader, fixed function units etc. die der Endverbraucher der Daten sind die so geschrieben wurden). Das hoffte ich ja im ersten Post klar zu machen.
Dann die effektive Menge. Auch wenn Vulkan es schon direkt Entwicklern anbot, konnte es da bisher nur 256 MB insgesamt verwalten, was wie ich schrieb bei double buffering effective 128 MB sind da die andere Hälfte ja inflight ist. Jetzt ist dieser Wert eben deutlich höher und das Spiel kann darauf reagieren und es eventuell öfter nutzen.
Und letztendlich wie der Treiber das Feature sonst einsetzt unabhängig von dem was der User an uploads generiert und anfragt.

Ergo finde ich es nicht überraschend das es so auseinander geht. Die Game Engines haben ja zum Teil sehr unterschiedliche Architektur. Das ist etwas was ich hier im Forum immer wieder betone die Anforderungen sind sehr unterschiedlich was eben heutige Entwicklung deutlich von früher unterscheidet.

Iscaran

2020-11-25, 10:33:19

Zur Möglichen Limitierung auf Zen3 schreibt Teralios von CB was interessantes:
https://www.computerbase.de/forum/threads/amd-smart-memory-access-nvidia-bestaetigt-arbeiten-an-vergleichbarer-loesung.1981166/post-24880460
"1. Die Funktionalität den RAM eines PCIe-Device anzusprechen, ist ein Bestandteil des PCIe-Standards. Teile kamen bereits mit PCIe 1.0, mit PCIe 2.0 wurde es ausgebaut.

2. Um die Aderessen vollständig in den Adressraum der CPU abzubilden, benötigt diese eine MMIO und ab 4GB Device RAM die Option für MMIO >4GB.

3. Um den Device RAM abzusichern gegen unbefugte Modifikation, aber auch um den System RAM abzusichern, müssen die CPUs entsprechend die Intel Vt-d als auch eben AMD VI beherrschen und dort kommt erst mit Zen 3 wichtige Funktionen hinzu, die es absichern.

4. PDEP/PEEXT ist unter Zen 2 relativ langsam und erst mit Zen 3 entsprechend »schnell«. Da es unter Zen 2 echt extrem langsam, in diesem Fall würde SAM mit sehr hoher Wahrscheinlichkeit unter Zen 2 sogar Leistung kosten.

SAM/BAR benötigt verschiedene Voraussetzung auf Hardware und Software-Ebenen.
"

Complicated

2020-11-25, 10:39:27

4. PDEP/PEEXT ist unter Zen 2 relativ langsam und erst mit Zen 3 entsprechend »schnell«. Da es unter Zen 2 echt extrem langsam, in diesem Fall würde SAM mit sehr hoher Wahrscheinlichkeit unter Zen 2 sogar Leistung kosten.

SAM/BAR benötigt verschiedene Voraussetzung auf Hardware und Software-Ebenen."
https://www.anandtech.com/show/16214/amd-zen-3-ryzen-deep-dive-review-5950x-5900x-5800x-and-5700x-tested/6

PDEP/PEXTParallel Bits
Deposit/Extreact300 cycle latency
250 cycles per 13 cycle latency
1 per clock

Iscaran

2020-11-25, 10:46:56

pixeljetstream

2020-11-25, 11:04:35

Ja das schreibt Teralios auch - er quotet afaik die Tabelle aus dem Anand-Artikel.

In dem Anandartikel ist aber leider keine Referenz zu SAM dabei - zumindest lese ich sie nicht. Liegt aber auch daran dass zur Zen3 Vorstellung, das SAM Feature noch niemand auf dem Schirm hatte.
PDEP/PEEXT hat imo nix direkt mit SAM an sich zu tun. Die Erwähnung basiert doch vielleicht nur auf dem imo irrtümlichen tweet von Sebastian Aaltonen. Der sowas auf ner Konsole nutzen kann aber am PC nicht wirklich, weil es da keine Textur encoding gibt die für alle Hersteller schnell ist (das hatte ich im tweet Austausch mit ihm auch angesprochen). Die genauen bit encodings einer Textur im sind Hersteller spezifisch, wie im ersten Post hier erwähnt.

Iscaran

2020-11-25, 11:11:36

Kann ich nicht beurteilen - laut Teralios steckt da aber mehr dahinter, es sind ja noch weitere Änderungen an den CPU Instructions hier relevant.

Wollte es daher hier einbringen, als Info.

Complicated

2020-11-25, 11:21:11

Daher hatte ich die Folie mit den neuen QoS Befehlen für die Speicherabsicherung und des gemeinsamen Zugriffs vermutet. Die Beschreibungen sind zwar kurz, doch scheinen dies Korrelationen zu sein für SAM, IMHO.

Edit:
MPK ist sogar Zen3 exklusiv und könnte ebenfalls die entscheidende Rolle spielen:
MPK memory protection keys, user data acess/write permission via 4-bit key in leaf page table
Wenn jemand das MPK anderweitig zuordnen kann, kann man es ja ausschließen.

pixeljetstream

2020-11-25, 11:26:21

Kann ich nicht beurteilen - laut Teralios steckt da aber mehr dahinter, es sind ja noch weitere Änderungen an den CPU Instructions hier relevant.

Wollte es daher hier einbringen, als Info.
Schade dass die Leute den Zusammenhang nicht näher begründen.

Iscaran

2020-11-25, 11:30:31

Vielleicht findet jemand von euch Hinweise auf notwendige Instructions in CPU Programming guide.

https://developer.amd.com/wordpress/media/2017/11/54945_PPR_Family_17h_Models_00h-0Fh.pdf

Mit den Stichworten MMIO und BAR findet man ein paar Treffer.

Aber für mich ist das nur noch "unverständliches Kauderwelsch was da dann steht :-).

pixeljetstream

2020-11-25, 11:45:35

IMO ist das ganze halt eine komische Inverssuche, man will Gründe finden warum Version a vs b, und findet dann Unterschiede und macht diese verantwortlich, ohne den eigentlichen Grund zu kennen. Manchmal ist die einfachste Erklärung die naheliegendste, es wäre ein Cluster fuck alle alten Permutationen zu validieren und Support zu garantieren, daher ist es wirtschaftlicher zu sagen „ab jetzt achten wir auf ein gutes Zusammenspiel für dieses Feature im Consumer market“. Sonst wird die Fußnotenliste in welcher Kombi es garantiert wird ewig lang (bios Versionen etc.).

Iscaran

2020-11-25, 11:50:22

Oder hat das ganze eventuell mit diesem bislang nicht dokumentierten Feature von ZEN CPUs zu tun ?
https://www.agner.org/forum/viewtopic.php?f=1&t=41&sid=d28ec47f053924756fec8108f1cd1865

Weiter unten ist auch ein Link zu einem anderen CPU-Blogger der bestimmten memory relevanten Instructions untersucht hat insbesonder zum Store-Load Forwarding was mit der undefinierten neuen Zen-Funktion zu tun hat:
https://pvk.ca/Blog/2020/02/01/too-much-locality-for-store-forwarding/

Allerdings ist das für mich alles zu kryptisch und ich kann nicht beurteilen ob so etwas beim Ausführen von GPU-Code oder von CPU-GPU-Kommunikation relevant sein kann.

Auf der Wikichip fidnet man zur Zen3-Architektur folgendes Info-Schnipsel - das hier im Kontext stehen könnte:
https://en.wikichip.org/wiki/amd/microarchitectures/zen_3
Key changes from Zen 2
"Hardware implementation of BMI2 PDEP/PEXT bit scatter/gather operations, compared to prior microcode emulation."

Iscaran

2020-11-25, 11:52:45

Manchmal ist die einfachste Erklärung die naheliegendste, es wäre ein Cluster fuck alle alten Permutationen zu validieren und Support zu garantieren, daher ist es wirtschaftlicher zu sagen „ab jetzt achten wir auf ein gutes Zusammenspiel für dieses Feature im Consumer market“. Sonst wird die Fußnotenliste in welcher Kombi es garantiert wird ewig lang (bios Versionen etc.).

Da stimme ich dir zu - ist wohl die plausibelste Erklärung. Bislang hat halt niemand darauf geachtet ALLE "dependencies" die so etwas braucht irgendwie als "Feature" zu kommunizieren.

AMD macht halt nun mit "SAM" den Anfang um resizable BAR im Consumermarkt zu etablieren. Existiert hat es ja schon - nur genutzt wurde es praktisch nicht. Was aber bei bis zu 10% Performance boost für lau eigentlich schon schade ist.

Complicated

2020-11-25, 11:56:35

aus den Kommentaren bei Agner:
Although I had to double-check about the equivalence of the test cases, this "memory renaming" got noticed and examined earlier in this year by some of the usual suspects:

https://gist.github.com/travisdowns/bc9 ... 82f85b9e9c
https://pvk.ca/Blog/2020/02/01/too-much ... orwarding/

Both Zen 2 and Ice Lake have been verified as handling bypass transformations for at least isolated store/load pairs, which the store/increment-at-addr/load test case is apparently equivalent to just 2 back-to-back instances of.
Die Links aus dem Zitat:
https://gist.github.com/travisdowns/bc9af3a0aaca5399824cf182f85b9e9c
https://pvk.ca/Blog/2020/02/01/too-much-locality-for-store-forwarding/

Iscaran

2020-11-25, 12:00:36

Ja - aber ist "Split-Forwarding" nun relevant für SAM ?
Außerdem gibt es das Feature auch schon auf ZEN2 - damit wäre es nicht ZEN3 - exklusiv.

Skysnake

2020-12-01, 11:14:47

So was wollten jetzt alle hater nochmal genau sagen?

https://www.golem.de/news/smart-access-memory-asus-unterstuetzt-sam-auf-intel-boards-2012-152489.html

Wie direkt am Anfang gesagt, so lange die nicht irgend eine secret souce drin haben, läuft das auch mit Intel CPUs, SOFERN halt die ganze Chain die nötigen PCIe features unterstützt...

Complicated

2020-12-01, 12:53:51

Damit ist AMD im Zugzwang ebenfalls SAM für Zen2 zu bringen ;)
Gut für alle, so ein offener Standard der einen Performance Zuwachs ermöglicht. :D

basix

2020-12-01, 13:27:07

Damit ist AMD im Zugzwang ebenfalls SAM für Zen2 zu bringen ;)
Gut für alle, so ein offener Standard der einen Performance Zuwachs ermöglicht. :D

Zugzwang ist ein lustiges Wort in diesem Zusammenhang. Immerhin geht es hier auch um AMD GPUs, bei welchen AMD sein "good to go" geben muss ;)

Für Zen 2 gibt es nun zwei Möglichkeiten:
- Es wird bald kommen
- Es geht aufgrund irgendeiner HW-Limitation der CPU nicht
Letzteres halte ich für eher unwahrscheinlich aber garantiert ist es eben noch nicht.

Zum Performance Zuwachs:
AMD hat gesagt, dass wenn Entwickler mit SAM im Hinterkopf ihre Spiele entwickeln, sie noch deutlich mehr Performance rausholen können. Gibt es da mehr Infos dazu oder Abschätzungen von versierten Leuten, wie viel das "mehr" in etwa sein könnte? Die Art Limitation bezüglich Datenaustausch zwischen CPU und GPU (Daten rumkopieren usw.) sollte man eigentlich profilen können.

Tesseract

2020-12-01, 13:39:01

- Es geht aufgrund irgendeiner HW-Limitation der CPU nicht

kann eigentlich nicht sein wenn der IO-die mit der ganzen PCIe-logic identisch ist.

basix

2020-12-01, 14:15:37

kann eigentlich nicht sein wenn der IO-die mit der ganzen PCIe-logic identisch ist.

Würde ich prinzipell auch behaupten. Aber gab es da nicht mal was mit irgendwelchen CPU Befehlen?

Skysnake

2020-12-01, 14:42:29

Aber schon traurig wie lange es dauert das im consumerbereich zu bringen....

Iscaran

2020-12-01, 20:14:24

So wie es scheint, muss es vor allem auch die MMU auf der CPU "korrekt" umsetzen können.
https://de.wikipedia.org/wiki/Memory_Management_Unit

Sieh dazu auch xexex kommentar auf CB (https://www.computerbase.de/forum/threads/smart-access-memory-asus-bringt-amd-feature-fuer-intel-mainboards.1985877/post-24962356) und seinen weiterführenden Link:
https://www.patreon.com/posts/44371506

"Crypto PCI-E Decoding" ist übrigens ebenso "Above 4GB decode" oder anders ausgedrückt "resize BAR" - nur für X370 boards ?!?

Ich denke der Stein kommt nun endlich ins Rollen und wir erleben den finalen, richtigen Wechsel hin zu "nativen 64bit-Systemen" und zwar vom BIOS Angefangen.

So wie es ja lange Zeit noch einen 16-Bit DOS support gab, bis man die alten Zöpfe gekappt hat.

Iscaran

2020-12-04, 21:24:35

https://www.computerbase.de/2020-12/smart-access-memory-ryzen-3000-kein-support/

Also das PDEP scheint wohl doch wichtig zu sein fürs SAM - die Hinweise verdichten sich, daß vollständiger und performanter BMI2-Instruction Set support in Hardware wohl ein notwendiges "accesoire" ist.

EDIT: https://www.reddit.com/r/Amd/comments/k6cbk7/zen_zen_and_zen_2_cannot_support_sam_due_to_the/gekl10k/

Das PDEP ist nicht notwending fürs resizable BAR, aber das PDEP "macht" die Beschleunigungswirkung aus. Ein größerer Adressraum allein bringt eben noch nicht Performance. Das kommt erst wenn die CPU besser mit der GPU zusammen operieren kann um hier die ein oder andere Adressmanipulation abzukürzen oder sogar wegzulassen die notwendig ist bis ein Pixel "berechnet" ist.

Eldoran

2020-12-06, 02:28:54

Ich sehe nicht weshalb PDEP/PEXT bezüglich smart access memory limitieren sollten. Ja das ist eine bisher wenig performante Implementierung dieses Befehls, Aber das sollte nicht der einzige Weg sein, SAM zu implementieren. Vor allem das maskieren sollte für SAM irrelevant sein.. Das sind eher so Sachen die für cryptographire relevant sind.

Gast

2020-12-06, 21:40:55

Ich sehe ehrlich gesagt nicht warum PDEP/PEXT notwendig sein sollte.
Die Befehle dienen ja dazu Bitfolgen zu maskieren, das sollte wohl kaum der typische Anwendungsfall für Grafik sein, da will man ja üblicherweise komplette Speicherbereiche kopieren und nicht nur teile davon.

RitterRost

2020-12-06, 23:08:38

Sebbi hat auf Twitter klargestellt: "pdep/pext is indeed nice for tiling your textures by CPU (expecially if the GPU supports standard swizzle). However the support for PCI-E resizable bar has nothing to do with this instruction..."

Es gibt also vermutlich Anwendungsfälle, wo diese bestimmte Art, Zieladressen zu bestimmen, hilfreich ist... Aber, das bedeutet nicht, das der erweiterte BAR ohne diese Instruktionen nutzlos ist (wie gesagt, bei AMD unter Linux für HPC wird extended BAR seit Jahren genutzt).

via: https://forum.beyond3d.com/posts/2180915/

pixeljetstream

2020-12-07, 09:28:51

Wir hatten das hier gleich am Anfang schon, da hatte ich auch darauf hingewiesen dass die Instruktion in dem konkreten Zusammenhang mit SAM nicht soviel Sinn macht bei PC.

Das encoding von Texturen im Hardware spezifischen Format kann von den Instruktionen profitieren, wird aber von dedizierter hw auf dem Chip gemacht. Auf Konsolen wo das Format fest ist, könnte man sich das zu nutze machen, aber ist vermutlich auch selten dort

https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12502128#post12502128

RitterRost

2020-12-07, 13:54:05

Leider wird das aber aktuell noch immer verbreitet:
https://www.computerbase.de/2020-12/smart-access-memory-ryzen-3000-kein-support/

"...Die Aussage lautet, dass ältere AMD-Prozessoren mit „_pdep_u32“ eine für SAM nötige Funktion nicht vollständig unterstützen."

Das wird leider in ähnlicher Weise auch von anderen News-Seiten berichtet und im Navi Thread hier im Forum auch immer wieder geäußert...

Schade, dass AMD da nicht mal offiziell etwas zu sagt.

Iscaran

2020-12-07, 14:54:45

Gibts denn keine Vergleichsbenchmarks mit resized BAR >4GB unter Linux für diverse Systeme ?

Dort gibts das ja schon seit >2 Jahren. Dann hätte man was an der Hand anhand dessen man diskutieren könnte.
Besonders interessant wären hier natürlich Zen1, Zen2 vs Intel Benchmarks mit resized BAR.

Nachtrag: Das einzige das ich dazu kenne ist der Benchmark von Coelacanth auf einem Ryzen 2600 mit einer RX560:
https://translate.google.com/translate?client=firefox-b-e&client=tw-ob&um=1&ie=UTF-8&hl=de&sl=ja&tl=de&u=https%3A%2F%2Fwww.coelacanth-dream.com%2Flastmod%2F

Er findet dabei in 1 von 3, zugegeben sehr theoretischen Benchmarks, einen positiven Effekt von ca 12%, die anderen beiden sind so bei +-0.

Nachtrag2: hmmm ganz neu von THW: bis zu +20% auf Intel 10900k und Z490 allerdings nur auf einer 6800 XT (keine anderen GPUs im Test).
https://www.tomshardware.com/news/resizable-bar-intel-z490-motherboard-benchmarks

aufkrawall

2020-12-07, 15:03:13

Ist die Frage, ob die Userspace-Treiber das evtl. auch noch etwas gesondert behandeln müssen, damit man profitieren kann?

Iscaran

2020-12-07, 15:18:29

Ja die Hinweise verdichten sich dass SAM ein klitzekleinwenig mehr ist als nur Above 4GB Decode oder "resize BAR". Zumindest unter Windows:

https://arstechnica.com/civis/viewtopic.php?p=39418245&sid=2a838c99983d5cbd1f6a401128aaa3cd#p39418245
"SAM does appear to be more (how much more is another question) than just dynamic BAR, as it requires platform firmware updates in the form of AMD's AGESA.

Were it just resizable BAR, then it's already there. It's part of WDDMv2 and required to be DirectX 12 compliant at an FL above 11. AMD introduced it as part of their suite of HSA and VRAM virtualisation with GCN. The minimum tier of DX12 compatibility (FL 12_0) appears to be a Microsoft developer pointing at AMD Southern Islands and saying "what that does".

The BAR takes time to resize and the GPU is cut off from RAM while it does it, so the GPU displays a static image. SAM could, at minimum, be the ability to do this on the fly."

Mit dem AGESA Punkt hat er was getroffen, warum braucht es ein AGESA Update, wenn das ganze einzig und allein ein PCIe/Mainboard/Chipsatz Ding wäre?

Wir brauchen einfach mehr Infos was das Ding macht.

Iscaran

2020-12-07, 15:22:18

Auch interessant hier die Diskussion am Beispiel des Z490 Chipsatzes wo es 2 BIOS-Optionen gibt:

Above 4GB Decode
UND
Resize BAR

Es ändert sich die Speicherzuteilung wie sie im Linux Windows dann dargestellt wird:
https://forums.guru3d.com/threads/resizeable-bar-support-issues.435389/#post-5859661

Beim Test mit der RX580 kommt es auch zu Bugs wie er schreibt...

Iscaran

2020-12-08, 11:41:31

Es gibt ein paar Treiberupdates zu Linux-Treibern bzgl. SAM-Optimierungen.

Vielleicht kann jemand mit mehr programming skills etwas mehr da rauslesen als ich es kann :-)
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7951/commits

Raff

2020-12-08, 17:38:53

PCGH hat just den ganzen Parcours mit 20 Spielen einmal mit und einmal ohne SAM getestet: https://www.pcgameshardware.de/Radeon-RX-6900-XT-Grafikkarte-276950/Tests/RX-6900-XT-oder-RTX-3090-Grafikkarten-Vergleich-1362845/3/

Die Basis bildet ein optimierter Ryzen 9 5950X, also ohne CPU-Limit. Leider fehlt Full HD in den Balken, da geht's aber gut ab:

"Zu den Glanzlichtern zählen die Leistungsgewinne in Full HD, beispielsweise in Red Dead Redemption 2 (bis zu +11,8 %), Greedfall (bis zu +13,7 %) und Forza Horizon (bis zu +15,9 %). Je höher die Auflösung, desto geringer die Zugewinne durch SAM; in Ultra HD bleibt von den großen Sprüngen nur wenig übrig. "

Die Skalierung ist aber nicht immer positiv.

MfG
Raff

Iscaran

2020-12-08, 17:53:12

@Raff: In ALL euren Grafik steht zum Testsystem drin Ryzen 3900...

System AMD Ryzen 9 3900X (12C/24T) @ 4,5 GHz (all-core), Asus X570 Crosshair VIII, 32 GiB Corsair DDR4-3800 (14-15-14-26-1T)*

Iscaran

2020-12-10, 09:33:49

Mit dem RMV-Tool müsste es doch möglich sein SAM in Aktion zu sehen ?
(Durch die Analyse der verschiedenen Memory Heaps Visible/Invisible to CPU ?)
https://www.phoronix.com/scan.php?page=news_item&px=Radeon-Memory-Visualizer-Opens

Iscaran

2020-12-15, 11:19:38

Hier im Phoronix forum hat mal einer einen Benchmark auf einem 3800X gemacht mit
rBAR ON/OFF

Einige der Benchmarks deuten an dass rBAR auf dem 3800 X sogar eher Performance kostet als dass sie mehr bringt.

https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/1225727-amd-smart-access-memory-resizable-bar-on-linux-still-ripe-for-improvement?p=1225937#post1225937
"b550 aorus pro, 3800xt, vega 56, all on stock, linux 5.10, mesa git 13 dec 2020."

bios csm: off, above 4G decoding: on
[ 4.155637] [drm] Detected VRAM RAM=8176M, BAR=8192M

$ vblank_mode=0 glxgears
71851 frames in 5.0 seconds = 14370.048 FPS
76439 frames in 5.0 seconds = 15287.775 FPS
76745 frames in 5.0 seconds = 15348.868 FPS

Unigine Superposition v1.1:
preset high
result: 7915
fps min: 50.64, avg 59.20, max 71.16
GPU °C: Min 43.0 Max 66.0

Unigine Heaven 4.0:
1080p, ultra, extreme, 8x
fps: 73.1
Score: 1843
Min FPS: 11.3
Max FPS: 147.6

bios csm: off, above 4G decoding: off
[ 4.249088] [drm] Detected VRAM RAM=8176M, BAR=256M

$ vblank_mode=0 glxgears
98150 frames in 5.0 seconds = 19629.842 FPS
93457 frames in 5.0 seconds = 18691.219 FPS
94206 frames in 5.0 seconds = 18841.086 FPS

Unigine Superposition v1.1:
preset high
result: 7915
fps min: 50.53, avg 59.20, max 71.68
GPU °C: Min 46.0 Max 65.0

Unigine Heaven 4.0:
1080p, ultra, extreme, 8x
fps: 73.0
Score: 1838
Min FPS: 11.3
Max FPS: 146.5

Zweiter Test mit anderen CPU Settings:

b550 aorus pro, 3800xt 6 core 4775mhz, memory 3600mhz fclk 1800mhz, vega 56 1590sclk-900-mclk, linux 5.10, mesa git 13 dec 2020
counter-strike global offensive:
2560x1440, low quality
above 4G decoding off: 392 fps, 387 fps => Mittelwert 389.5
above 4G decoding on: 385 fps, 399 fps => Mittelwert 392

Allerdings sieht man schon, daß es bei CS GO eher nur die Schwankung des Benchmarks ist, die er misst. BAR hat also keinen Effekt hier.
Die Unigine Benchmarks zeigen auch 0.0 Effekt.

Nur beim vBlank - scheint OFF deutlich besser zu sein als ON ?

Aber wir brauchen mal tests mit verschiedenen CPUs auf Linux mit rBAR on/Off.

RitterRost

2020-12-15, 15:10:46

Wenn Du Phoronix liest, dann hast Du doch sicher auch gelesen, dass die Grafiktreiber gerade erst Code eingebaut bekommen, der aus dem großen Specherbereich/BAR Nutzen ziehen soll.
https://www.phoronix.com/scan.php?page=news_item&px=Mesa-21.0-AMD-Smart-Memory

Je nach Benchmark und GPU Generation bringt das erst mal noch nicht viel.
https://www.phoronix.com/scan.php?page=news_item&px=AMD-Smart-Access-Memory-Initial

Ich weiß nicht, warum Du die CPU so betonst. Die sollte doch kaum eine Rolle spielen.

Iscaran

2020-12-15, 21:08:30

Ich weiß nicht, warum Du die CPU so betonst. Die sollte doch kaum eine Rolle spielen.

Weil aktuell noch unklar ist ob auch ältere Zen CPUs wirklich von SAM profitieren können wegen der PDEP/PEXT Problematik.

Ansonsten lese ich auch bei Phoronix die News mit. Die Patches betreffen eben das rBAR feature in Linux. Weil ja alle Welt immer rBAR und "SAM" gleichsetzt, was aber vermutlich auch nicht ganz stimmt - wenn man sich eben genau die Patches ansieht.

RitterRost

2020-12-18, 10:18:00

Weil aktuell noch unklar ist ob auch ältere Zen CPUs wirklich von SAM profitieren können wegen der PDEP/PEXT Problematik.

Ansonsten lese ich auch bei Phoronix die News mit. Die Patches betreffen eben das rBAR feature in Linux. Weil ja alle Welt immer rBAR und "SAM" gleichsetzt, was aber vermutlich auch nicht ganz stimmt - wenn man sich eben genau die Patches ansieht.

Ok.
Die "Hardware"-Grundlagen sind ja resizeable BAR zusammen mit BIOS-Unterstützung und UEFI-Modus, damit dieses PCIe Feature läuft.

Dann muss noch die "Software" - hier der Grafiktreiber das große Speicherfenster nutzen, damit es schneller sein kann, als ein kleines Fenster, das bei Bedarf verschoben werden muss...

Das "Hardware" Feature läuft (abseits von BIOS-Problemen) ja seit längerem unter Linux, oder jetzt auch unter Windows auf diverser Hardware: https://videocardz.com/newz/asus-and-msi-demonstrate-resizeable-bar-amd-smart-access-memory-working-on-zen-and-zen2-cpus

Auf der Software-Seite hast Du sicher diesen Thread gesehen:
https://twitter.com/SebAaltonen/status/1335609441824231424
"pdep/pext is indeed nice for tiling your textures by CPU (expecially if the GPU supports standard swizzle). However the support for PCI-E resizable bar has nothing to do with this instruction..."

Warum knüpfst Du jetzt solche Erwartungen an diese CPU Befehle?
Weil die evtl. öfter eingesetzt werden und dann beim Zugriff auf den Speicher schneller sein könnten?

Complicated

2020-12-18, 10:22:54

pixeljetstream

2020-12-18, 10:32:32

Es geht nicht darum ob pdep/pext benötigt wird um SAM überhaupt zu nutzen. Es geht darum wann SAM auch einen wirklich spürbaren Vorteil bringt. Diese Instruktionen sind ein Performancevorteil gegenüber Zen2 und könnte derzeit die Szenarien definieren wo SAM etwas bringt.

Was imo hier passiert ist das Leute versuchen zu rechtfertigen warum vorheriger Zen kein SAM bekommen hat und weil in der Instruktionentabelle diese herausstechen ernennt man sie zum Grund.

Complicated

2020-12-18, 10:48:45

Ist ja auch richtig so. Warum sollte man SAM aktivieren (funktioniert ja auch auf älteren Modellen) um dann weniger Leistung zu bekommen?
Wenn es nichts bringt, dann ist es ein valider Grund es nicht auf Zen2 zu aktivieren - wobei AMD sich hier wirklich einfach aus der Affäre ziehen könnte, indem sie es einfach aktiv schalten und es dem Kunden überlassen - es gibt viele BIOS Optionen die auf dem einen System was bringen und auf dem anderen eben nichts mit der Hardware-Konfiguration. PCIe 4.0 ist auch "aktiv" und bringt nichts wenn die falsche CPU drin steckt, da der Handshake sich auf PCIe 3.0 als gemeinsamen Nenner einigt.

Selbiges gilt übrigens bei jeder GPU/CPU bzgl. Video-Codec und Verschlüsselung. Da stört es scheinbar niemanden, dass solche Feature nicht freigeschaltet werden für ältere Modelle, weil sie dort keine FFUs haben und das ganze deutlich langsamer auf der CPU ausführen.

RitterRost

2020-12-18, 11:19:07

Hier ist ein interessanter Artikel über das BAR Feature.
https://www.patreon.com/posts/44371506
Das klingt auf jeden Fall so, als ob sich das Kopieren von Speicher sehr vereinfacht.

Ob ein Spiel von SAM profitiert und dann noch diese Befehle verwendet? Da müsste man das Programm analysieren - aber Disassembler habe ich seit über 25Jahren nicht mehr benutzt...

Iscaran

2020-12-18, 11:50:30

@RitterRost: Ja rat mal wer den Artikel verlinkt hat ;)
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12519709#post12519709

RitterRost

2020-12-18, 11:54:56

@RitterRost: Ja rat mal wer den Artikel verlinkt hat ;)
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12519709#post12519709

Danke. Hatte ich wohl übersehen.
Ich war dem Link im Twitter-Post gefolgt.

Iscaran

2020-12-18, 13:40:39

Interessanter finde ich dies hier:
https://wccftech.com/asus-enables-amd-smart-access-memory-support-1st-gen-ryzen-cpus-on-b450-motherboards/

Leider bleibt hier immer noch die Frage offen ob es Performance-Gewinne eben nur mit Ryzen5xxx und RDNA2 Karten gibt.
Bei RX580@Ryzen 1700X jedenfalls gibt es ca 0%
Weil:
a) GPU nicht "sinnvoll" mit rBAR (aka SAM) umgehen kann ?
oder
b) weil CPU nur 1700X und kein Intel10xxx oder Ryzen 5xxx ?

Immerhin wissen wir nun - daß man prinzipiell Above 4GB decode, alias resizable BAR (alias SAM?), auch auf älteren Boards/CPUs/GPUs prinzipiell "einschalten" kann - aber obs auch genausoviel bringt wie in der Kombination Ryzen5xxx und RX6xxx ist immer noch offen. Genauso wie die Frage ob dies evtl. technische Hintergründe hat.

Gast

2020-12-18, 16:29:37

Leider bleibt hier immer noch die Frage offen ob es Performance-Gewinne eben nur mit Ryzen5xxx und RDNA2 Karten gibt.
Bei RX580@Ryzen 1700X jedenfalls gibt es ca 0%
Weil:
a) GPU nicht "sinnvoll" mit rBAR (aka SAM) umgehen kann ?
oder
b) weil CPU nur 1700X und kein Intel10xxx oder Ryzen 5xxx ?

Die Frage ist eher ob Resize BAR wirklich aktiv ist.
Mein X470 Board hat mit dem neuesten BIOS-Update auch dafür ein Setting bekommen. Die werden aber als "Off" und "Auto" bezeichnet, und ob "Auto" das wirklich aktiviert wenn kein Zen 3 verbaut ist?

RitterRost

2020-12-18, 16:30:04

Mit "alter" Zen2 CPU und RX6800 gibt es also einen speed-up. https://www.computerbase.de/2020-12/amd-smart-access-memory-renoir-matisse-b450/#update-2020-12-18T15:06

Mal sehen, ob AMD auch ältere GPU Treiber unter Windows für SAM anpasst.
Unter Linux sind ja erste SAM Patches für MESA eingereicht (soweit ich weiß betreffen die alle GPUs ab Polaris).

Iscaran

2020-12-18, 20:30:37

Mal sehen, ob AMD auch ältere GPU Treiber unter Windows für SAM anpasst.
Unter Linux sind ja erste SAM Patches für MESA eingereicht (soweit ich weiß betreffen die alle GPUs ab Polaris).

Ja das wird noch interessant werden. Vor allem wenn die Linux-Community hier Performance-Zuwächse hinbekommt auf älteren GPUs und CPUs, müsste sich AMD mit dem Windows-Treiber auch mehr Mühe geben.

Complicated

2020-12-18, 20:33:26

Ich würde an dieser Stelle sagen: Vorteil Opensource
Wenn Linuxsysteme performancemäßig zugewinnen, wird automatisch Druck gemacht.

Iscaran

2020-12-18, 23:30:08

Oha: das klingt aber eher nach "massiven" Problemen auf "Altkarten" - ob man das einfach durch Treiberfixes hinbiegen kann...

https://www.computerbase.de/forum/threads/amd-smart-access-memory-auch-zen-und-zen-2-beherrschen-den-vram-vollzugriff.1990292/post-25044000
"Habe es nur mit meiner alten RX 480 probiert. Und wie schon erwähnt, wurde Valhalla dadurch unspielbar. Durchnitts-FPS sind auf 5 gefallen. Ob es rein der Treiber Support ist oder die Hardware, beurteile ich nicht. Auf jeden Fall hat SAM es mit der Karte unspielbar gemacht."

Andererseits:RX580@Ryzen 3700X
mit Doom@Vulkan@:
https://www.computerbase.de/forum/threads/amd-smart-access-memory-auch-zen-und-zen-2-beherrschen-den-vram-vollzugriff.1990292/post-25044378
78 FPS mit und ohne SAM...

mit Ion Fury@OpenGL ebenfalls praktisch 0 Gewinn

Und der nächste mit RX5700xt@Ryzen5600 mit Horizon Zero Dawn, meint geringfügig Max FPS zu gewinnen, aber AVG bleibt
https://www.computerbase.de/forum/threads/amd-smart-access-memory-auch-zen-und-zen-2-beherrschen-den-vram-vollzugriff.1990292/post-25044405

RitterRost

2020-12-19, 11:20:47

Das wird der Grund sein, warum AMD das nicht anbieten und supporten will - die haben auch so genug Arbeit für ihre Programmierer...

Hier noch mal von einem AMD Mitarbeiter für Linux:
https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/1223897-request-smart-access-memory-information/page4#post1225606

Auch dort warnt er vor der Nutzung von SAM/BAR mit nicht unterstützten Grafikkarten/Systemen, weil die von AMD nicht getestet werden (außer wahrscheinlich die Hardware-konfiguration von "Marek", einem AMD Programmierer; aber, ich weiß gerade nicht, was er für Hardware hat)

Skysnake

2020-12-19, 13:13:43

Leute ihr könnt hier doch so viel quatschen wie ihr wollt.

Da kann 1000mal SAM von der Hardware und der Firmware supported sein. Wenn der Treibernicht passt und Murks macht dann wird es beliebig langsam/kaputt...

Und IHR könnt das nicht beurteilen. Also damit ist so ziemlich jeder außerhalb von AMD gemeint weil die Treiber halt teilweise ein binary blob sind unter Windows. Zumindest war es das früher...

Im Zweifel musst man nur an einer Stelleeinen Fehler machen oder irgend ne x beliebige nicht triviale Einschränkung haben und schon wird es nichts mit der Mehrperformance...

Ihr könnt jetzt gerne AMD daraus einen Steick drehen dass das nicht für die alte Hardware gebracht wird, aber fair ist das nicht. AMD ist noch immer ein Unternehmen und bei NVIDIA hätte kein Hahn danach gekräht und irgend wie random argument gebracht warum das auch nicht gut so ist....

Sorry aber das ist heuchlerisch.

Der Stand ist wie er ist und das muss man so auch erstmal akzeptieren. Man kann gerne den Wunsch äußern das AMD das auch für ältere Hardware bringt und auch dass das alte AMD das auch gemacht hätte aber mehr auch nicht. Die einzige Stelle wo man ernsthaft meckern kann ist die beschissene Informationspolitik. Da haben sie echt gefallen. Und das nehme ich ihnen auch übel.

Iscaran

2020-12-19, 13:24:23

Ja Bridgman ist da sehr deutlich, das das ganze wohl viele Fallstricke hat, weshalb AMD auch dazu steht das das Feature nur auf Systemen läuft die dafür auch "validiert" sind.

Es KANN natürlich auch auf anderen Laufen, oder auch nicht. Wie man sieht bringt es in der Regel auf nicht validierten Systemen nichts, oder sogar Probleme ein.

Iscaran

2020-12-19, 13:32:20

Nachtrag:

Eine Ryzen 3xxx liefert ganz vergleichbare SAM-Effekte auf einer 6800er wie ein Ryzen 5xxx
@Windows diesmal:
https://www.computerbase.de/forum/threads/amd-smart-access-memory-auch-zen-und-zen-2-beherrschen-den-vram-vollzugriff.1990292/post-25046123

Wenn ich mich nicht verschaut habe sind das +3% bei F1, +2% bei TR und +13% bei FH4. (bezogen auf Average)

CB hat @4k +1% bei F1 mit dem 5xxx Ryzen und der 6800. Und +4% bei TR
https://www.computerbase.de/2020-11/amd-radeon-rx-6800-xt-test/5/

RitterRost

2020-12-19, 13:56:45

Ex3cut3r

2020-12-19, 15:30:31

Jop. Auch Zen 2 profitiert. Verstehe nicht, warum AMD das nur für Zen 3 vermarkten wollte. Bin mal gespannt, wie der Support bei Nvidia aussehen wird.

Complicated

2020-12-19, 15:33:18

Jop. Auch Zen 2 profitiert. Verstehe nicht, warum AMD das nur für Zen 3 vermarkten wollte.Wie kommst du darauf?

misterh

2020-12-19, 18:21:12

nur in 1440P Ultra und 2160 Medium hat was gebracht. Inkl AMD Fix

alte Bios 2816 ohne SAM
https://abload.de/img/test3rakgd.png

neueste Bios 3001 Mod mit SAM
https://abload.de/img/withamdfixo7js6.png

https://www.computerbase.de/forum/threads/cyberpunk-2077-die-community-testet-gpus-und-cpus-in-night-city.1990119/page-28#post-25047479

Iscaran

2020-12-19, 19:31:46

Also wenn ich deine Zahlen alle richtig lese dann macht das meiste ja der AMD Fix aus...die SAM=OFF Daten sind auch OHNE den AMD Fix ?

Alle Werte sind RELATIV zu No SAM (no AMD Fix ?)
SAM=On | SAM=On
no AMD Fix | AMD Fix
1920x1080 Preset Mittel (neu!): 93% 101%
1920x1080 Preset Ultra: 94% 100%
2560x1440 Preset Mittel (neu!): 89% 97%
2560x1440 Preset Ultra: 108% 108%
3840x2160 Preset Mittel: 108% 107%

Scheint also eher eine "Regression" zu geben durch SAM, die dann mittels "Hotfix" gelöst wird.

Performance boost mit Zen2 aber nur in Ultra 1440p und 4k@mittel.

Sind die GPUs evtl. bei den niedrigeren Settings im CPU-Limit und können nicht mehr dazu holen ? Genau HIER wäre jetzt mal ein Gegentest mit einem Ryzen 5xxx interessant.

misterh

2020-12-19, 20:07:48

wäre auch nett zu wissen mit 5000er.

alte bios war ohne SAM und mit AMD Fix

sonst wie im links beide mit SAM nur halt mit und ohne AMD FIx.

HOT

2020-12-20, 22:15:57

Also meine N10 startet nicht mit SAM, habs mal getestet ;). Rechner bootet, aber kein Bild und GraKa-Gepiepse, 1x lang, 3x kurz. CMOS-Reset, Bar wieder aus, keine Probleme.

Iscaran

2020-12-28, 21:50:17

Interessant eine 5700 XT bringt SAM zum laufen in Cyberpunk 2077:
https://www.computerbase.de/forum/threads/aus-der-community-amd-smart-access-memory-im-test-mit-radeon-rx-6800.1992588/post-25083585
+8% Avg.

Vor allem die min. FPS scheinen oft sehr stark anzusteigen mit SAM. (siehe z.B. auch Control mit dieser 5700 XT
https://www.computerbase.de/forum/threads/aus-der-community-amd-smart-access-memory-im-test-mit-radeon-rx-6800.1992588/post-25084981

oder im allgemeinen Review topic:
https://www.computerbase.de/2020-12/amd-smart-access-memory-test-radeon-rx-6800/#update-2020-12-28T18:04

Coxon hat auch einen interessanten Ansatzpunkt geliefert, was nun genau "SAM" macht
https://www.computerbase.de/forum/threads/aus-der-community-amd-smart-access-memory-im-test-mit-radeon-rx-6800.1992588/post-25085094
basierend auf dieser Quelle: https://hardwaresfera.com/en/articulos/resizable-bar/

Der Artikel scheint mir durchaus logisch und von jemand geschrieben der ungefähr auch weiss was er da schreibt.

Demnach ist der Hauptvorteil von SAM wohl wie es Coxon auf CB treffend "verkürzt" darstellt:

Normal sieht die Anfrage so aus:
GPU@CPU@RAM@CPU@VRAM@GPU

mit SAM fällt der Weg kürzer aus:
GPU@CPU@VRAM@GPU

Für Hardware die diese Spezifikation inkludiert hat, bietet das Feature noch mehr Performance. Für HW die es nur zum Teil inkludiert, hat es weniger Vorteile, aber immer noch welche."

Es scheint also hauptsächlich auf den Support des Mainboards hinauszulaufen, welcher den Schalter anbietet, den Rest macht dann Windows und womöglich sogar "ganz ohne GPU-Treiber" ?
Sonst würde das nicht so einfach auch auf z.B. Vega portierbar sein ? => https://www.computerbase.de/forum/threads/aus-der-community-amd-smart-access-memory-im-test-mit-radeon-rx-6800.1992588/post-25085213

EDIT: Aus dem Artikel oben (https://hardwaresfera.com/en/articulos/resizable-bar/):

Die Idee für resize Bar (2008) stammt von HP und AMD:
"As an anecdote, who proposed this solution were Hewlett-Packard and Advanced Micro Devices, come on, HP and AMD. Both companies were the ones that presented the idea to PCI-SIG, who manages the PCI Express standard."

Ebenso interessant - scheinbar ab VEGA dürfte resize Bar (aka SAM) auf AMD GPUs mehr oder weniger laufen:

How long has AMD been working on SAM

Investigating this technology we have come across something quite curious. We have come across a message Christian Konig 2015, where it indicates that it is and a person identified as Alex are "maintainers of the Radeon and Amdgpu kernel drivers for AMD graphics hardware."

Christian Konig is an Open Source developer who works for AMD and who would be responsible for the audio support for HDMI in Radeon HD in the company's open source drivers.

Within said message indicates that "The new generation of hardware has started to support Resizable BAR." This would indicate that possibly the AMD Vega architecture already supported this technology.

Weiterhin interessante Funde sind diese Kommentare zu Intel:

Intel does not officially support this technology on your processors. Although it is known that Haswell architecture released in 2013 already had support for Resizable BAR.

Highlight that MSI has implemented Resizable BAR on one of its motherboards with Z490 chipset. This BIOS is expected to be available soon and the RX 6000 with support for Resizable BAR can be used on motherboards with an Intel processor.

Sehr strange - warum scheinbar ALLE global player diese Technologie kennen - aber seit >10 Jahren im Schrank vermodern lassen ???
"Curiously investigating the subject we have come across presentations from 2009 where Intel already mentioned Resizable BAR. Mahesh Wagh, Intel IO Architect mentions this technology in its presentation in the IDF 2009. Jasmin Ajanovic, Principal Engineer at Intel mentions this technology in its presentation in the 2009 HotChips."

Und nVidia hat bestimmt auch dazu einiges gemacht, sonst wären sie jetzt nicht "sofort" aufgekommen mit ihrem "aber wir können das auch, also bald..."

BlacKi

2020-12-29, 01:59:00

Sehr strange - warum scheinbar ALLE global player diese Technologie kennen - aber seit >10 Jahren im Schrank vermodern lassen ???

weil es auch einbussen gibt. ich denke da muss man optmieren. schlicht anmachen und gut, funktioniert eben nur jenachdem.

kann auch sein, das die spiele selbst darauf angepasst werden müssen und das thema bald gegessen sein wird.

-/\-CruNcher-/\-

2020-12-29, 06:38:12

@Iscaran
Da "vermodert" noch viel mehr in den Schränken das Zauberwort ist Zeitpunkt ;)

Grmbl-Na-Gut

2020-12-29, 10:18:47

Also meine N10 startet nicht mit SAM, habs mal getestet ;). Rechner bootet, aber kein Bild und GraKa-Gepiepse, 1x lang, 3x kurz. CMOS-Reset, Bar wieder aus, keine Probleme.

Ich habe das nach dem Biosupdate nun mit dem 3950x und der 6900 am Laufen.
Ich überlege ob ich das mal mit einer 2080 teste.

Win muss auf einem GPT Datenträger liegen.
CSM muss aus sein im Bios.

Wen man Windows dann Installiert, kommt auch die frage Infos senden an AMD Ja/Nein.

Beim ersten mal ist mir das abgeschmiert und die Einstellungen im Bios wurden Resetet.

Läuft nun aber.

HOT

2020-12-29, 10:44:56

Ich denke, das wird am beta-BIOS gelegen haben. Ist ja auch wieder zurückgezogen worden. So wie ich Biostar kenne, gibts in wenigen Wochen dann direkt das AGESA 1190-BIOS, dann wird es laufen. Sobald da mal was neues kommt, teste ich das noch mal.

Ex3cut3r

2020-12-29, 16:53:44

Kann man "Bar" auch mit einer 2080 anschmeißen?

aufkrawall

2020-12-29, 17:09:28

Es braucht explizite Treiber-Unterstützung und die gibts von NV derzeit noch nicht mal für Ampere.

Hakim

2020-12-29, 17:41:13

Irgendwo (igor?) hatte ich mitbekommen das evt auch die FW auf den Karten das mitmachen muss, und die bisherigen Ampere Karten evt sogar noch ein BIOS Update benötigen

aufkrawall

2021-01-04, 15:14:09

Optimierungen für RADV gelandet: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7979

Gast

2021-01-04, 21:05:43

Irgendwo (igor?) hatte ich mitbekommen das evt auch die FW auf den Karten das mitmachen muss, und die bisherigen Ampere Karten evt sogar noch ein BIOS Update benötigen

Das Problem ist MS.
Aus Kompatibilitätsgründen muss die Grafikkarte immer noch im 32bit Modus starten. Für den 64bit Modus muss sie dann im laufenden Betrieb neustarten und MS besteht darauf, dass der User davon nichts mitbekommen darf, sprich kein Bildausfall oder ähnliches.

Für den Moment des Neustarts muss also die Firmware dafür sorgen, dass am Ausgang ein vernünftiges Bild ankommt, die CPU hat in dem Moment keine Kontrolle über die Grafikkarte.

aufkrawall

2021-01-06, 14:31:07

[HWU] AMD's Killer Feature? SAM, 36 Game Benchmark

https://youtu.be/GS3oY3LVKvU
In Mesa gibts jetzt Toggle für SAM, den man ohne System-Neustart und pro Anwendung nutzen können sollte:
https://gitlab.freedesktop.org/mesa/mesa/-/commit/31240a875c0d6174d8d1389d16572d9d5f872adc
Da fragt man sich, weshalb es das nicht im Windows-Treiber gibt, wenn es zumindest einzelnen Spielen noch nicht so gut schmeckt.

dargo

2021-01-07, 07:58:29

Raff

2021-01-07, 11:33:35

Yep, P0.2 sollte man nicht allzu ernst nehmen, sofern man da nicht 5-10 Runs mittelt. Das gilt insbesondere für CPU-limitierte Szenarien, die idR stark fluktuieren. Im harten Grafiklimit laufen Spiele zwar konstanter, 1-2 Runs reichen aber auch bei den besten Testszenen oft nicht.

MfG
Raff

dargo

2021-01-07, 11:43:53

Eben... was habe ich mir die Zähne dabei ausgebissen. Da startest du 10 Runs und bekommst jedes Mal ein anderes Ergebnis. Und die Fluktuation lag nicht selten bei ~10-15%. :freak: 0,2% low kann man komplett in die Tonne treten (Wink Richtung CB ;)). Selbst bei 1% low bedarf es mehrere Runs.

anddill

2021-01-07, 11:56:03

Das Problem ist MS.
Aus Kompatibilitätsgründen muss die Grafikkarte immer noch im 32bit Modus starten. Für den 64bit Modus muss sie dann im laufenden Betrieb neustarten und MS besteht darauf, dass der User davon nichts mitbekommen darf, sprich kein Bildausfall oder ähnliches.

Für den Moment des Neustarts muss also die Firmware dafür sorgen, dass am Ausgang ein vernünftiges Bild ankommt, die CPU hat in dem Moment keine Kontrolle über die Grafikkarte.

Ahh, deshalb stockt jetzt der Ladekringel kurz bevor der Desktop lädt für ca. 0,3s.

BTB

2021-02-10, 16:52:08

Nvidia und Intel klappt ja auch, bei mir im Bios nennt sich der Spaß "Resize-BAR Support" - die neueren Treiber unterstützen das wohl auch.

Gibt es irgendwo einen Benchmark der das VRam volllaufen lässt? Würde mich mal interessieren, ob und wieviel das bringt.

vinacis_vivids

2021-02-10, 17:10:51

https://abload.de/thumb/superpositionvramtmjee.png (https://abload.de/image.php?img=superpositionvramtmjee.png) https://abload.de/thumb/superpositionvramsampdjxg.png (https://abload.de/image.php?img=superpositionvramsampdjxg.png)

Gast

2021-02-11, 09:55:11

Gibt es irgendwo einen Benchmark der das VRam volllaufen lässt? Würde mich mal interessieren, ob und wieviel das bringt.

Bei vollgelaufenem RAM nicht großartig was.

vinacis_vivids

2021-02-16, 20:28:39

del

BTB

2021-02-16, 20:36:47

Hat VV ja schon im anderen Thread geschrieben. Nvidia klemmt wohl noch? Ich teste später mal den Benchmark, macht der die höheren Auflösung dann virtuell? (Sorry :) keine Ahnung falls das falsch ist)

BTB

2021-02-17, 09:59:41

del

dargo

2021-03-05, 08:05:22

AMD Brings Smart Access Memory (Resizable Bar) To Ryzen 3000 Desktop CPUs, Up To 16% Performance Boost In AAA Games
https://wccftech.com/amd-brings-smart-access-memory-resizable-bar-to-ryzen-3000-desktop-cpus/

dargo

2021-03-06, 07:46:11

JdVoKci1PrQ

vinacis_vivids

2021-03-19, 13:26:34

Bisschen Futter für SAM : RX6800 + 5600X
4-BauUjclg4

Vor allem werden die dips und drops extrem gut abgefangen was man an den 1% pc sieht.
Bei Vulkan RDR2 1440p steigt es von 55,2 fps auf 98,1fps. +77% ;D
Der volle low-lvl CPU-Zugriff auf den VRAM ist crazy shit :eek:
Schaut euch mal die Auslastung der Cores an:
https://youtu.be/4-BauUjclg4?t=896

HisN

2021-03-19, 13:35:14

Na komm schon Nvidia, Ende März war vBios-Update angedacht. Es ist fast Ende März. Ich will auch den Crazy-Vram-Shit.

Raff

2021-03-19, 13:49:06

Bisschen Futter für SAM : RX6800 + 5600X
https://youtu.be/4-BauUjclg4

Vor allem werden die dips und drops extrem gut abgefangen was man an den 1% pc sieht.
Bei Vulkan RDR2 1440p steigt es von 55,2 fps auf 98,1fps. +77% ;D
Der volle low-lvl CPU-Zugriff auf den VRAM ist crazy shit :eek:
Schaut euch mal die Auslastung der Cores an:
https://youtu.be/4-BauUjclg4?t=896

Das ist nie im Leben richtig und reproduzierbar.

MfG
Raff

Linmoum

2021-03-19, 14:43:14

Na komm schon Nvidia, Ende März war vBios-Update angedacht. Es ist fast Ende März. Ich will auch den Crazy-Vram-Shit.Kann man doch schon bei der 3060 bestaunen. Da wird auch mit einer 3080 aufwärts kein großes Wunder mehr geschehen.

Bei NV sieht das einfach nur nach irgendwelchem nachgeschobenen Software-Gefrickel via Treiber/Firmware aus. Dass da dann wenig rumkommt, sollte nicht großartig überraschen.

Raff

2021-03-19, 14:46:50

Wir sind zwar nicht vor Gericht, aber: Im Zweifel für den Angeklagten. ;) Navi 22 profitiert weniger als Navi 21, ergo wird GA104 mehr profitieren als GA106 - und GA102 wird die größten Effekte zeigen. Das liegt an den verlagerten Flaschenhälsen. Nvidia muss rBAR aber schleunigst für weitere APIs und Spiele freigeben, sonst kann man in diversen Indizes eh keine großen Sprünge hinlegen.

MfG
Raff

Ex3cut3r

2021-03-19, 14:46:52

Ein Armutszeugnis von Nvidia. Turing wird es allem Anschein nach, auch gar nicht bekommen. Dazu das miese DX12, was haben die eigentlich all die Jahre dort gemacht? Mining betrieben? ^^

Der 3080 Verkauf hat mir wenigstens eine schöne Summe gebracht, habe aber leider gestern bei AMD gar nix bekommen, und habe es sowieso aufgegeben. Und bei Scalpern kaufe ich aus Prinzip nicht, und die "normalen" Händler haben auch ganz schöne Abzockpreise drin, ich schau im Herbst nochmal, und investiere das Geld vermutlich in was anderem.

Raff

2021-03-19, 14:50:41

Geld gezählt und im stillen Kämmerlein an Deep Learning geforscht. ;) Warum sollten sie sich auch anstrengen, wenn die Konkurrenz schläft? Das ist jetzt anders - und das ist geil. Viele Jahre lang hatten wir das Wettrüsten nur bei den Treiber-Features, wo AMD jedes Jahr vorlegt.

MfG
Raff

w0mbat

2021-03-19, 14:59:50

Für mein Mobo gibt es jetzt auch AGESA 1.2.0.0 mit SAM. In zwei Wochen werde ich das mal in Angriff nehmen, muss Windows neu installieren, da ich es damals noch nicht im UEFI-Modus installiert habe.

Bin schon gespannt ob man wirklich einen Unterschied merkt :)

dargo

2021-03-19, 15:30:04

Wir sind zwar nicht vor Gericht, aber: Im Zweifel für den Angeklagten. ;) Navi 22 profitiert weniger als Navi 21, ergo wird GA104 mehr profitieren als GA106 - und GA102 wird die größten Effekte zeigen. Das liegt an den verlagerten Flaschenhälsen.
Das ist doch kompletter Unsinn. Seit wann interessieren dich plötzlich Flaschenhälse? Wenn du eine CPU testest nimmst du auch 720p und kein 4k. :rolleyes: Wenn Spieler A mit N21 Topdog in 1440p spielt und Spieler B mit N22 Topdog in 1080p... wo genau siehst du da einen großen Unterschied bei den Flaschenhälsen? Im Umkehrschluss kannst du GA106 auch mit 720p durch deine Benchmarks durchjagen damit du stärker im CPU-Limit bist um ggf. größere Vorteile durch rBAR zu sehen.

BTB

2021-03-19, 15:33:23

w0mbat

2021-03-19, 15:43:20

Soweit ich weiß, ja.

Raff

2021-03-19, 15:47:39

Das ist doch kompletter Unsinn. Seit wann interessieren dich plötzlich Flaschenhälse? Wenn du eine CPU testest nimmst du auch 720p und kein 4k. :rolleyes: Wenn Spieler A mit N21 Topdog in 1440p spielt und Spieler B mit N22 Topdog in 1080p... wo genau siehst du da einen großen Unterschied bei den Flaschenhälsen? Im Umkehrschluss kannst du GA106 auch mit 720p durch deine Benchmarks durchjagen damit du stärker im CPU-Limit bist um ggf. größere Vorteile durch rBAR zu sehen.

Letzteres könnte ich - und ich bin sicher, dass das größere Unterschiede zutage fördern würde -, nur ist das halt weder praxisnah, noch habe ich gerade ansatzweise Zeit für so Späße. Es gibt sich dynamisch verschiebende "Soft-Limits" abseits von harten CPU- oder GPU-Rechenleistungslimits.

MfG
Raff

vinacis_vivids

2021-03-19, 15:58:07

Von Ampere würde ich nichts leistungsmäßiges in der Richtung erwarten was direkten VRAM CPU-Zugriff angeht.
SAM bei AMD = SmartAccess Memory
SAM bei NV = Small Access Memory

Der closed-Treiber bei Nvidia hat exklusiven Zugriff auf den Großteil des VRAM, insbesondere den Frame Buffer, wo mit vielen Algorithmen (wie DLSS, Color Compression) und daraus resultierenden Artefakten gerechnet bzw. getrickst wird. Auch hat Nvidia kein Hardware Async Compute, welches die CPU-Eingriffe auf die GPU-Pipeline ohne Verzögerungen erlaubt.

Der Heilige Gral von Nvidia, also der closed-Treiberzugriff zum Speichercontroller inkl. deren Techniken zur Reduktion des Bandbreitenbedarfs fängt an zu bröckeln.

Warum ist SAM bei NV nicht konkurrenzfähig? Es liegt am SC & SI und der unterlegenen 8nm Fertigung, die zuviel Energie beim Zugriff verbraucht. Der direkte Zugriff ist ja grundsätzlich möglich (siehe Mining), zieht allerdings am Powerbudged und senkt den GPU-Takt, was wiederum die Leistung senkt. Ein Nullsummenspiel und für Nvidia nicht zu gewinnen.

y33H@

2021-03-19, 16:18:06

Die Color Compression erzeugt keine Artefakte, da Lossless ...

Raff

2021-03-19, 16:27:02

Das zum einen. Zum anderen senkt auch SAM den Radeon-GPU-Boost, sobald es hilft. Physik. Unbesiegbar.

MfG
Raff

dargo

2021-03-19, 16:55:20

Letzteres könnte ich - und ich bin sicher, dass das größere Unterschiede zutage fördern würde -, nur ist das halt weder praxisnah, noch habe ich gerade ansatzweise Zeit für so Späße.
Ist 720p auch nicht, macht ihr trotzdem bei CPU-Vergleichen. ;)

Das zum einen. Zum anderen senkt auch SAM den Radeon-GPU-Boost, sobald es hilft.
Wen interessiert das wenns am Ende +xx% mehr Performance gibt? :freak: Dieses krampfhafte Versteifen auf irgendwelche Frequenzen habe ich noch nie verstanden. Von mir aus kann die GPU mit 1Mhz boosten wenn das Ergebnis passt.

btw.
Ihr macht auch DLSS Benchmarks. Brauchst nur in 1440p auf DLSS-Performance zu klicken und schon hast du deine 720p. ;) Die mickrigen Zusatzkosten von DLSS alleine sind da schon vernachlässigbar.

Raff

2021-03-19, 17:14:21

Ist 720p auch nicht, macht ihr trotzdem bei CPU-Vergleichen. ;)

Falsche Denkweise. Lies dir das (https://www.pcgameshardware.de/CPU-CPU-154106/News/Prozessor-Benchmarks-Aufloesung-1295967/) bitte mal aufmerksam durch. :)

Wen interessiert das wenns am Ende +xx% mehr Performance gibt? :freak: Dieses krampfhafte Versteifen auf irgendwelche Frequenzen habe ich noch nie verstanden. Von mir aus kann die GPU mit 1Mhz boosten wenn das Ergebnis passt.

Vinacis_vivids hat da oben Unsinn geschrieben, den ich korrigieren wollte (y33H@ hat den anderen Unsinn korrigiert.). :)

btw.
Ihr macht auch DLSS Benchmarks. Brauchst nur in 1440p auf DLSS-Performance zu klicken und schon hast du deine 720p. ;) Die mickrigen Zusatzkosten von DLSS alleine sind da schon vernachlässigbar.

Würde ich so ungenau arbeiten ("Die Kosten für DLSS alleine sind vernachlässigbar"), könnte ich zur Abwechslung mal auf normale Arbeitsstunden kommen. Das passt aber nicht zu Perfektionismus.

MfG
Raff