Announcement

Collapse
No announcement yet.

CS Memory Accounting For Radeon Gallium3D

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

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

    Comment


    • #3
      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


      • #4
        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 (?)

        Comment


        • #5
          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.

          Comment


          • #6
            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; 31 January 2013, 10:10 PM.
            Test signature

            Comment


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

              Comment

              Working...
              X