• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

DirectX 12 Update Allows CPU and GPU to Access VRAM Simultaneously

erek

erek

8=D
2FA
Joined
Dec 19, 2005
Messages
17,804
Interesting

"For developers, the feature is already supported by Nvidia, Intel, and AMD drivers. For example, it's already included in Nvidia's latest Game Ready and Studio Drivers (version 531.41 or newer) and Intel A-series/Xe GPUs (with driver 31.0.101.4255 or newer). For AMD GPUs, developers must consult their AMD alliance manager to get a supported driver.


The feature just came out from Microsoft, so don't expect it to be implemented in games anytime soon. Instead, developers will need time to see whether or not it will provide a significant enough performance advantage to make it worthwhile."

nYdgXjvckiuv4uSbgqUMF5-320-80.jpg


Source: https://www.tomshardware.com/news/dx12-optimization-cpu-gpu-access-vram-simultaneously
 
I was never sure what did AMD Sam/Rebar was doing but .......I thought it was doing that...

According to PCGamesN, SAM is AMD’s take on the Resizable BAR PCIe standard, which increases the available bandwidth between the CPU and GPU. Enabling this feature allows the CPU access to the full memory buffer for the GPU instead of being limited to just 256MB

Even chatGPT seem unsure of the difference:
According to Tom’s Hardware, DirectX 12 update allows CPU and GPU to access VRAM simultaneously1. On the other hand, AMD’s SAM (Smart Access Memory) feature allows the CPU to have direct, simultaneous access to GPU memory.

Not sure I can spot the difference.

https://www.tomshardware.com/news/dx12-optimization-cpu-gpu-access-vram-simultaneously
Historically a GPU’s VRAM was inaccessible to the CPU, forcing programs to have to copy large amounts of data to the GPU via the PCI bus. Most modern GPUs have introduced VRAM resizable base address register (BAR) enabling Windows to manage the GPU VRAM in WDDM 2.0 or later.
With the VRAM being managed by Windows, D3D now exposes the heap memory access directly to the CPU! This allows both the CPU and GPU to directly access the memory simultaneously, removing the need to copy data from the CPU to the GPU increasing performance in certain scenarios.

Maybe it is a standardization in DX of AMD feature ? That make it more used in an explicite way by the program instead of relying that the memory controller-bios take advantage of it in automatic way ?

https://gpuopen.com/learn/get-the-most-out-of-smart-access-memory/
From the CPU perspective, this is like UPLOAD memory: it is uncached and write-combined. It is also called the BAR (Base Address Register) after the mechanism used for accessing it. DirectX® 12 currently does not expose this directly.
When SAM is enabled, Vulkan applications are no longer limited to the small aperture and may use significantly more local visible memory.

For DirectX®12, the Radeon driver can apply an optimization to place some resources allocated in the UPLOAD heap in the BAR instead on allocation.

Cannot understand, but maybe it is just supporting the extended ReBar stuff in the regular DX12 library that were already available in Vulkan
 
Last edited:
LukeTbk said:
I was never sure what did AMD Sam/Rebar was doing but .......I thought it was doing that...

According to PCGamesN, SAM is AMD’s take on the Resizable BAR PCIe standard, which increases the available bandwidth between the CPU and GPU. Enabling this feature allows the CPU access to the full memory buffer for the GPU instead of being limited to just 256MB

Even chatGPT seem unsure of the difference:
According to Tom’s Hardware, DirectX 12 update allows CPU and GPU to access VRAM simultaneously1. On the other hand, AMD’s SAM (Smart Access Memory) feature allows the CPU to have direct, simultaneous access to GPU memory.

Not sure I can spot the difference.
Click to expand...

Same, that's why I asked.

It's confusing.
 
I too am curious what this all means in general and specifically for my machine and games.
 
Zarathustra[H] said:
How is this different from the likes of AMD SmartAccess Memory?

View attachment 560969
Click to expand...
Smart Access Memory aka Resizable Bar takes the normal boring 256MB bus and lets the GPU and CPU negotiate something larger, how much larger has some mitigating circumstances but the point is they figure out what will work best and they go with that, and what this ultimately does is reduces the number of trips it takes to get all the requested information cutting down on latency because of the travel time to and from Ram to Vram and back again.

One of the features and benefits of Resizable Bar is that it presents the VRAM to the OS, but you still need to jump through all the traditional permission hoops of moving data across the CPU bus from RAM to VRAM and back again as the CPU can only read and write to system RAM, and not VRAM directly. The Agility SDK in DX12 removes this limitation with some very specific use cases, but it lets the CPU read and write directly to the VRAM in what essentially pools the VRAM and system RAM into a giant heap, much like how the shared memory in the XBox works, so really this cuts down on the need for the CPU to load data to RAM then for the GPU to copy that memory from RAM into VRAM, takes the whole step out.

This is something that should work very nicely with DDR5 and its channel-splitting abilities, even DDR4 now exists at a point where the 64-bit bus width is too large, it takes more time to fill that bus than it takes to travel back and forth, furthermore with consumer systems limited to only 2 memory channels it forces longer wait times as it means only 2 processes can ever be talking to memory at a time. Level 1 tech has some good resources discussing the memory channel and controller issues with large core counts, I could rant for a while on 128 GB of ram on a Ryzen 7000 and how much it sucks you can't do it easily.

TLDR;
SMA/ResBar negotiates a larger bus between the CPU and GPU
DX12 Agility uses ResBar to have D3D manage RAM and VRAM creating a heap memory pool that the CPU can directly access removing a lot of traffic from the bus, which SMA/ResBar negotiated a larger size for.

For more information:
https://devblogs.microsoft.com/directx/preview-agility-sdk-1-710-0/
 
Lakados said:
SMA/ResBar negotiates a larger bus between the CPU and GPU
Click to expand...
Not to nitpick, but the bus doesn't change size. What's changed is the size of the window representing how much VRAM the CPU can see at once. If the CPU needs to send 1GB of data to VRAM, it can normally only send 1/4 of that, then it has to move the window, move the next 256MB, and so on. It's analogous to EMS back in the day. Rebar makes the window bigger.

The Microsoft blog post Tom's references says "With the VRAM being managed by Windows, D3D now exposes the heap memory access directly to the CPU! This allows both the CPU and GPU to directly access the memory simultaneously, removing the need to copy data from the CPU to the GPU increasing performance in certain scenarios."

To me this new feature sounds more like the equivalent of giving the CPU DMA to the VRAM without an intervening buffer.
 
1_rick said:
Not to nitpick, but the bus doesn't change size. What's changed is the size of the window representing how much VRAM the CPU can see at once. If the CPU needs to send 1GB of data to VRAM, it can normally only send 1/4 of that, then it has to move the window, move the next 256MB, and so on. It's analogous to EMS back in the day. Rebar makes the window bigger.

The Microsoft blog post Tom's references says "With the VRAM being managed by Windows, D3D now exposes the heap memory access directly to the CPU! This allows both the CPU and GPU to directly access the memory simultaneously, removing the need to copy data from the CPU to the GPU increasing performance in certain scenarios."

To me this new feature sounds more like the equivalent of giving the CPU DMA to the VRAM without an intervening buffer.
Click to expand...
Well yeah the Bus bandwidth is a function of hardware, but the frame size... is that the right word? limit of 256MB being changed to something larger here is the important part, it's not quite direct memory access to the VRAM buffer but yeah sure close enough but yes it removes the need for using system ram as a buffer removing 2 full trips across the bus for loading certain datasets into VRAM.
 
This just looks like DX12 exposing a way to interact with BAR on supported systems.

AKA you're getting a pointer to GPU memory that the CPU accesses over PCI-E. CPU latency will be terrible of course.

Here there is an notice saying a CPU visible memory pool cannot be backed by GPU memory. I'm guessing this is effectively what you can now do.
https://learn.microsoft.com/en-us/windows/win32/api/d3d12/ne-d3d12-d3d12_memory_pool
 
A lot of measurabator talk here what is the estimated increase in FPS?
 
It should help cut down on stuttering and frametime issues. Especially with ports from consoles, where memory is simultaneously shared, with a dedicated bus, and a lot less wait states, etc.
 
chameleoneel said:
It should help cut down on stuttering and frametime issues. Especially with ports from consoles, where memory is simultaneously shared, with a dedicated bus, and a lot less wait states, etc.
Click to expand...

To me this just sounds like a more convenient abstraction layer. Even if your CPU can access GPU memory via a direct pointer (which by the way is already possible with SVM/HMM on Linux at least - probably Windows has something similar?), that address still has to be translated from the CPUs virtual address space to the physical VRAM (PCIe space) address which means page fault handling by the OS. More importantly the data still has to be copied/moved and that involves crossing the PCIe boundary (DMA, GPU copy kernel, etc.) ie. latency. Maybe there is some speed benefit somewhere here, but quite frankly I don't see how this is necessarily faster than existing explicit copies. More convenient for a programmer - yes (well maybe - because now a simple, innocent `auto y = *x` could mean a huge latency penalty if you're sloppy with keeping track of CPU vs GPU pointers), but faster in and of itself - probably not.

I also don't think CPU and GPU are (cache) coherent if the GPU is PCIe attached - APUs with shared memory space are a completely different matter and are coherent.
 
socK said:
Probably literally zero on average outside of very niche cases
Click to expand...
Not quite, the heap memory from the Agility SDK very closely matches that of the Xbox, this should greatly simplify the porting process between the two systems, for all the similarities between the CPU and GPU the vastly different memory configuration is a large pain to work around, especially when working in DX12.
DX12, Vulkan, and C++, all require manual memory management, you can develop APIs and Libraries of wrappers to hide it but it still needs to get done, and accommodating the differences between the consoles and PCs is not an easy one and the optimizations for one are detrimental to the other.
The Agility SDK essentially solves this incongruity, as it basically emulates the console memory configuration inside the PC.
The design itself has a lot of advantages primarily with latency and reducing the workload on the CPU memory controller, which is a sticking point with me and the only thing I really don't like about the current Ryzen lineup, but when used it does a lot towards freeing up the CPU and the GPU from doing fetch requests which result in visible FPS dips when you are running either the CPU or GPU at 100% as the interrupt process quite literally stops them from working on whatever it was doing before.
Overall this is a good thing, requiring RAM and VRAM to duplicate data is inefficient and things are fast enough now that the process is a hindrance, not a benefit.
 
It doesn't emulate anything, it just lets you do something that DX12 didn't expose. Vulkan allowed it, and NVAPI provided a way. Don't know if AGS did.

The idea here is that you avoid the GPU copy engine. You get to avoid some memory and synchronization overhead.
Code: 
Then:
CPU:             CPU write     -> Write combined cache -> System Memory
GPU copy engine: System memory -> PCI-E bus            -> Vram

Now:
CPU:             CPU write     -> Write combined cache -> PCI-E bus -> VRAM

You don't get a free lunch for nothing in every case with this option. CPU readbacks from this memory will be absolutely terrible performance wise on PC unless you're dealing with integrated graphics. If you're looking for fast uploads, you're almost certainly going to get back a pointer to write combined memory, and reads will kill.

If you read, all the caches need to get flushed - which has a performance penalty, and then you're still going over the PCI-E bus on top of that and latency is awful.
 
socK said:
It doesn't emulate anything, it just lets you do something that DX12 didn't expose. Vulkan allowed it, and NVAPI provided a way. Don't know if AGS did.

The idea here is that you avoid the GPU copy engine. You get to avoid some memory and synchronization overhead.
Code: 
Then:
CPU:             CPU write     -> Write combined cache -> System Memory
GPU copy engine: System memory -> PCI-E bus            -> Vram

Now:
CPU:             CPU write     -> Write combined cache -> PCI-E bus -> VRAM

You don't get a free lunch for nothing in every case with this option. CPU readbacks from this memory will be absolutely terrible performance wise on PC unless you're dealing with integrated graphics. If you're looking for fast uploads, you're almost certainly going to get back a pointer to write combined memory, and reads will kill.

If you read, all the caches need to get flushed - which has a performance penalty, and then you're still going over the PCI-E bus on top of that and latency is awful.
Click to expand...
Does the GPU have to flush its caches (iirc at least AMD doesn’t have a “invalidate single cacheline” insn - so it’s the whole cache) when the CPU writes directly to VRAM using this mechanism? I don’t think that’s the case with the GPU copy engine since it’s coherent with itself - also the copy engine can run asynchronously so there’s some benefit to using it. To be honest I am much more familiar with the GPU compute side vs real-time graphics so I’m probably missing a whole bunch here.
 
schoolslave said:
Does the GPU have to flush its caches (iirc at least AMD doesn’t have a “invalidate single cacheline” insn - so it’s the whole cache) when the CPU writes directly to VRAM using this mechanism? I don’t think that’s the case with the GPU copy engine since it’s coherent with itself - also the copy engine can run asynchronously so there’s some benefit to using it. To be honest I am much more familiar with the GPU compute side vs real-time graphics so I’m probably missing a whole bunch here.
Click to expand...

You are basically using the CPU as a copy engine. Ideally from another thread. So it's kinda asynchronous to a degree. No idea if this is always a win. It definitely might be possible for it not to be and the GPU copy engine will be more efficient.

You're almost certainly hitting write combined memory first on non-UMA hardware when you try to write through to VRAM like this. The goal is to try and avoid the shitload of bus transactions that would drown you in overhead otherwise.

It looks implementation defined, but seems like the DX12 upload heaps generally winds up as both write combined and coherent (on PC at least). In this case, I think a flush has to happen on a read to stay coherent. Don't see how anything else would be the case until you start getting back into UMA territory.
 
You must log in or register to reply here.
Back
Top