Announcement

Collapse
No announcement yet.

Gallium3D Gets Accelerated PBO Texture Uploads

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

  • Gallium3D Gets Accelerated PBO Texture Uploads

    Phoronix: Gallium3D Gets Accelerated PBO Texture Uploads

    AMD's Nicolai Hähnle has taken over where KDE developer Fredrik Höglund left off in working on accelerated texture uploads from Pixel Buffer Objects for Gallium3D drivers. This is a change just not for the Radeon Gallium3D drivers but for all of the drivers using the Mesa state tracker...

    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
    What does it means on "accelerated"? How a upload can be accelerated? Does it means " faster"? Accelerated usually means "done in/by the hardware"

    Comment


    • #3
      Wonderful, my respect for AMD is growing as they collaborate on making the platform better. They trust their product.

      Originally posted by andrei_me View Post
      What does it means on "accelerated"? How a upload can be accelerated? Does it means " faster"? Accelerated usually means "done in/by the hardware"
      I think they mean that the hardware does direct DMA reads, rather than the system pushing the buffer actively over the PCIe ports. Not sure though.

      Comment


      • #4
        This is the 3rd performance related patchset Nicolai Hähnle has submitted recently.

        It's great to see AMD is starting to focus on performance for their OSS drivers.

        Comment


        • #5
          Originally posted by andrei_me View Post
          What does it means on "accelerated"? How a upload can be accelerated? Does it means " faster"? Accelerated usually means "done in/by the hardware"
          From the OpenGL.org wiki:
          In standard pixel transfer operations, the pixel transfer functions are not permitted to return until the client-side memory is no longer in use. For uploading (pixel unpack), this means that, at a minimum, the OpenGL implementation must copy the memory into an internal buffer in order to do an asynchronous DMA transfer. For downloading (pixel pack), this is much worse, as the entire download operation must take place immediately. If the source of the download is still in use, like a render target, this forces a partial or full flush.

          By allowing OpenGL to manage the memory used as the source or destination of pixel transfer operations, OpenGL is able to avoid explicit synchronization until the user accesses the buffer object. This means that the application can be doing other things while the driver is downloading or uploading pixel data. Fence sync objects can be used to ask whether the process is complete without stalling the CPU
          All opinions are my own not those of my employer if you know who they are.

          Comment


          • #6
            Progress..

            The goal for AMD should really be to get SteamOS stamp of approval, sure it's small fry atm but its gotta look real bad when even Valve discards AMD hardware under Linux!

            Comment


            • #7
              Basically, what happens when using PBO uploads and using them well: You write your images to a mapped buffer and make glTextureSubImageXD read from that buffer instead of the main memory. Same for downloads - write image data to a buffer, wait for the operation to finish and then just read the mapped buffer.

              One big advantage is that there is no explicit synchronization (especially important for downloads) and that there are no GL calls involved when accessing an already mapped buffer, so you can actually do that in a separate thread. Currently, this is horribly slow on Mesa (though it does work), so it's great news they are working on it - don't know if any games are using this feature, but if they do, they'll probably gain a decent amount of performance.
              Last edited by VikingGe; 19 January 2016, 07:01 AM.

              Comment


              • #8
                This is great and now there's also a chance that we will see the ARB_shader_image_load_store extension.
                Also ARB_shader_atomic_counters is getting closer http://lists.freedesktop.org/archive...ry/104070.html http://lists.freedesktop.org/archive...ry/105134.html
                I think that OpenGL4.2 is getting closer for gallium drivers.

                Comment


                • #9
                  Thanks for the good work, Nicolai. Also very pleasant to see that this is cross-vendor work, so the benefit affects all sorts of hardware, even some thing usually found on ARMs.
                  Stop TCPA, stupid software patents and corrupt politicians!

                  Comment


                  • #10
                    I was already glad about AMD, but now I'm even gladder

                    It's quite a surprise for me to hear that PBO wasn't implemented yet in Mesa. I'm running all my games on an old HD 6870 (r600g) and they run quite well, so I thought this kind of "easy" optimization must already be in. I'm fairly sure it's used in a lot of games and, if it is indeed, we're going to see major improvements, I tell you!

                    Originally posted by Nille_kungen View Post
                    This is great and now there's also a chance that we will see the ARB_shader_image_load_store extension.
                    Also ARB_shader_atomic_counters is getting closer http://lists.freedesktop.org/archive...ry/104070.html http://lists.freedesktop.org/archive...ry/105134.html
                    I think that OpenGL4.2 is getting closer for gallium drivers.
                    It makes quite some time I haven't seen any commits in docs/GL3.txt, I think it's the longest period without any announcement in here. I suppose mesa devs are focusing on stability and optimizations, which is great too!

                    Comment

                    Working...
                    X