If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

CS Memory Accounting For Radeon Gallium3D

01-31-2013, 03:10 PM

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...

Comment

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.

Comment

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. ).

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.

Comment

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.

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.