Announcement

Collapse
No announcement yet.

GL_AMD_pinned_memory Lands In Mesa

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

  • GL_AMD_pinned_memory Lands In Mesa

    Phoronix: GL_AMD_pinned_memory Lands In Mesa

    Support for the GL_AMD_pinned_memory OpenGL extension has landed within Mesa and is implemented for the R600g and RadeonSI Gallium3D drivers. This patch series also lands the Userptr support for the open-source AMD graphics drivers on the user-space side...

    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
    kernel 3.18 required

    Originally posted by Phoronix
    This feature will be part of the Mesa 10.6 release in about three months.
    Note that this extension "GL_AMD_pinned_memory" relies on the "userptr" support which landed in the kernel version 3.18 (http://kernelnewbies.org/Linux_3.18#...9d94445953570b).

    But I don't know if there is a minimal libdrm version too to enable this extension.

    Comment


    • #3
      Is there any use for this when you already have ARB_buffer_storage, except supporting older applications that may only know the pinned memory extension?

      Comment


      • #4
        Originally posted by Kraut View Post
        Is there any use for this when you already have ARB_buffer_storage, except supporting older applications that may only know the pinned memory extension?
        The difference seems to be that the application can allocate the memory itself, fill it, and then pass to the driver without copies.

        Comment


        • #5
          Originally posted by mannerov View Post
          The difference seems to be that the application can allocate the memory itself, fill it, and then pass to the driver without copies.
          Well, you have persistent mapping with ARB_buffer_storage. And from the application side it is not a big difference if you get the memory pointer by malloc or some gl call.

          Comment


          • #6
            Originally posted by Kraut View Post
            Is there any use for this when you already have ARB_buffer_storage, except supporting older applications that may only know the pinned memory extension?
            From the point of view of someone writing a new application, no. Both extensions cover the same ground.

            Comment


            • #7
              Originally posted by Kraut View Post
              Is there any use for this when you already have ARB_buffer_storage, except supporting older applications that may only know the pinned memory extension?
              Mabye it's a prep for OGL-Next. AMD and NV both have Pinned Memory and if they both do the same thing as ARB buffer storage then there would be no need for the duplicity mucking up the OGL-N API.

              Comment


              • #8
                AFAIK ARB_buffer_storage allows the usage of HSA while userptr is only a sort of DMA.

                Comment


                • #9
                  Originally posted by Kemosabe View Post
                  AFAIK ARB_buffer_storage allows the usage of HSA while userptr is only a sort of DMA.
                  From a hardware perspective, it's the same. You are just mapping system pages into the GPU GART aperture. The only difference is who allocated the memory. With the userptr interface, you are pinning user malloced memory and mapping it into the GART. For "regular" GART memory, the kernel driver allocates the pages and they are mapped into the GART. Neither has anything to do with HSA.

                  Comment


                  • #10
                    Originally posted by agd5f View Post
                    From a hardware perspective, it's the same. You are just mapping system pages into the GPU GART aperture. The only difference is who allocated the memory. With the userptr interface, you are pinning user malloced memory and mapping it into the GART. For "regular" GART memory, the kernel driver allocates the pages and they are mapped into the GART. Neither has anything to do with HSA.
                    I read this about a week ago somewhere: "buffer_storage as a preparation for upcoming DX12 and glNext. Targeting APUs and architectures with shared memory .. blabla HSA ... blaba" or similar on a gaming website showing some rendering techniques ^^. But i believe in your variant.
                    I wished i had some expertise on this topic but sadly i'll never archieve this most likely.

                    Comment

                    Working...
                    X