Printable View
Phoronix: CS Memory Accounting For Radeon Gallium3D
With the Radeon Gallium3D driver (and Mesa/Gallum3D drivers in generally) finally moving on to properly handling more visually demanding and modern OpenGL games and other workloads, it's time for CS memory accounting to be implemented within the open-source driver...
http://www.phoronix.com/vr.php?view=MTI4OTM
So...what is the gain from this? Michael, this news could be understood only be J.Glisse and co.
It sounds like they've developed a fairly accurate estimate of memory usuage. The reason this is important is to make sure to not add more stuff to the memory than it can hold. Adding more stuff to the memory than it can hold causes problems (I'm not sure what problems it would cause exactly, could mean video could lock up, slow down, etc. ).
As too what CS stands for... I have no idea.
command stream (?)Quote:
Originally Posted by ua=42
CS = Command stream, or else Command submission.
It sounds like they are ensuring that each call that gets sent to the kernel can fit onto the GPUs memory at 1 time.
My guess is that should reduce memory contention on the GPU - where textures stream in to replace other textures, which are immediately required again.
But that could be completely wrong.
Put a big "I think..." around all this, but...
CS = Command Submission -- userspace driver passes a buffer full of PM4 commands to the kernel driver.
The command buffer includes "relocs", basically references to data buffer handles. Each of those handles needs to be locked down in video memory or GART memory before the command buffer is passed to the GPU, and the commands need to be patched with the buffer addresses that point to the buffer wherever it ends up being pinned.
It's possible for the commands in the buffer to reference a set of buffers which, when pinned, require more physical memory than is actually available. I don't know all of the possible symptoms, but I imagine the most common is doing a lot of work to pin all of the buffers referenced by the command buffer and then *still* running out of memory and have to either wait for memory to be freed (not sure if this is practical) or discard the contents of the command buffer.
At first glance the code appears to calculate a quick estimate of total memory requirements before any of the relocs are processed, giving the kernel driver an early heads-up that processing this buffer will probably fail.
I think the kernel actually rejects the command submission when it finds there's not enough memory and then rendering glitches as a result. Could be wrong though.Quote:
Originally Posted by bridgman