ATI's Ring Bus Memory Controller and Vista

[Geo]

The early roadmaps that we have all the 16-1-1-1 etc. numbers from states Virtual Memory for R520 (and "NO VM" for RV515).

Come to think of it, if I'm not mistaken, the thread where you dropped the first RB hint was a VM thread. . .

 

[arjan de lumens]

How could this work with resources in system memory? The CPU manages its own PTEs (with OS support) so the OS would have to update the GPU's PTEs if the CPU's table was updated. Ideally, the two tables would be updated simultaneously to prevent race conditions.

With a GPU that can modify page tables and paged memory, you would presumably mark off the affected pages as unavailable to the CPU for as long as the GPU has access to them. Once the GPU is idle, you can re-translate the modified page table back to the format that the CPU expects and access the memory pages from the CPU side again.

 

[OpenGL guy]

With a GPU that can modify page tables and paged memory, you would presumably mark off the affected pages as unavailable to the CPU for as long as the GPU has access to them. Once the GPU is idle, you can re-translate the modified page table back to the format that the CPU expects and access the memory pages from the CPU side again.

I don't think this will work well in a multicontext environment.

 

[DemoCoder]

Having two copies of every managed texture is not very efficient, and even impractical in some cases.

I think burning main memory is alot cheaper than burning bus bandwidth and inserting roundtrips. Rather than simply marking a page empty, "page out" now has to wait for the page to be copied back to main memory, with all of the synchronization and signaling that may entail, followed by a page-in. So now we have two operations both with round trips.

I never in my mind imagined the point of VM on the GPU was to create some kind of pseudo-UMA architecture to save on main memory footprint as well. Seems better for the CPU to reload from a swap file on disk than having the GPU load it back. Atleast you can overlap disk I/O and GPU. I think main memory is dirt cheap enough.

 

[psurge]

OpenGL guy - can you post a more detailed explanation of what exactly a virtual address from the point of view of the GPU is?

Am I correct in thinking that the GPU page table contains entries that map a "GPU virtual address" to either
- physical address of local (on-board) memory
- virtual address in system memory

(or does the GPU actually have to map to physical system memory)?

 

[db]

http://download.microsoft.com/downl...41f2-893d-a6f2295b40c8/DW04018_WINHEC2004.ppt

 

[rwolf]

There is no apriori reason why mapped memory must be writable. The principle problem with memory on GPUs to date is not using too much framebuffer, but using too many art assets.

You don't "swap them out" to main memory. There is a copy in main memory already.

So when you do an ALT-TAB in Windows Vista between Unreal Tournament 2010 and the 3D desktop what do you think happens. The contents of the GPU frambuffer are swapped out to memory or disk. The GPU under vista will be a shared device. The advantages of swapping things in and out is that only used resources will be in the GPU's memory. You could have only the parts of a large texture that are being drawn paged into GPU memory while the rest of the texture is in the system ram.

 

[DemoCoder]

So when you do an ALT-TAB in Windows Vista between Unreal Tournament 2010 and the 3D desktop what do you think happens. The contents of the GPU frambuffer are swapped out to memory or disk.

I personally don't care much about Vista (I will be full screen gaming, and ALT-TAB should just invalidate the buffer and potentially cause the app to refresh everything) I don't think the FB should be VM'ed. What's the big deal with losing one frame, when the app can react and rerender? Why copy 10+MB of data back to main memory for safe keeping, when that data is transient and gone after 1/60th of a second anyway? Maybe the Vista desktop itself is a special case due to compositing, where loss of the desktop FB might force all windows to be rerendered which itself might thrash the VM system.

The GPU under vista will be a shared device. The advantages of swapping things in and out is that only used resources will be in the GPU's memory. You could have only the parts of a large texture that are being drawn paged into GPU memory while the rest of the texture is in the system ram.

Paging in part of a large read only texture orthogonal to do with swap out. If system ram contains the complete texture, you don't need swap out. You swap in pieces to the GPU as needed, and the GPU drops the pieces it needs the least to make room for more pages.

Swap out for read-only resources just saves system memory. It's just a poor man's UMA. But hey, why not go further! Why doesn't Vista use GPU VRAM as an additional PAGE FILE for Operating System virtual memory, before using disk? Why doesn't Microsoft Office "page out" into GPU VRAM?

By the time Vista and DX10 VM equipped cards ship, the average DX10 PC will probably have a gigabytes or two of main memory standard. Blowing 500mb of system RAM shouldn't be a problem, unless you want to run multiple copies of UE3.

 

[rwolf]

What will be interesting is how VM will be handled with SLI and Xfire.

 

[Colourless]

Getting rid of D3DERR_DEVICELOST and D3DERR_DEVICENOTRESET saves a lot of headaches. With the Operating System managing buffers intelligently it's just makes things easier for developers. This is of course exactly what Microsoft has done with D3D10 and Vista. No more TestCooperativeLevel() anymore.