Results 1 to 7 of 7

Thread: CS Memory Accounting For Radeon Gallium3D

  1. #1
    Join Date
    Jan 2007
    Posts
    15,699

    Default CS Memory Accounting For Radeon Gallium3D

    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

  2. #2
    Join Date
    Aug 2009
    Location
    Russe, Bulgaria
    Posts
    543

    Default

    So...what is the gain from this? Michael, this news could be understood only be J.Glisse and co.

  3. #3
    Join Date
    Jan 2010
    Location
    Somewhere in Kansas.
    Posts
    294

    Default

    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.

  4. #4
    Join Date
    Nov 2008
    Location
    Old Europe
    Posts
    938

    Default

    Quote Originally Posted by ua=42 View Post
    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 (?)

  5. #5
    Join Date
    Oct 2008
    Posts
    3,251

    Default i think it's a performance gain?

    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.

  6. #6
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,579

    Default

    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.
    Last edited by bridgman; 01-31-2013 at 10:10 PM.

  7. #7
    Join Date
    Aug 2008
    Posts
    91

    Default

    Quote Originally Posted by bridgman View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •