No announcement yet.

User Ptr Support Proposed For AMD's Radeon DRM Driver

  • Filter
  • Time
  • Show
Clear All
new posts

  • User Ptr Support Proposed For AMD's Radeon DRM Driver

    Phoronix: User Ptr Support Proposed For AMD's Radeon DRM Driver

    Christian K?nig has proposed user pointer support for the Radeon DRM driver to match the Intel driver's recent feature...

  • #2
    Is there a plan on enabling --enable-r600-llvm-compiler by default?


    • #3
      NAK, this is kind of an horror show. I should probably take a look at
      Intel code too.

      First registering one notifier per bo is a bad idea, it is not what you
      want to do.

      So in light of the radeon patch to add user ptr, i took a look at
      intel code and it is time to put an end to this non sense. It
      violate so many mm assumptions that it just not a doable options.

      So Intel code only register a range_start callback that means that
      any gup or other i915 activities that happens just after this call
      back returns as no idea what so ever of it might get. It might get
      the old pages that are about to change or the new pages.

      For the use case where the gpu is only reading thing from those
      buffer this is fine. But the use case where gpu gonna writte to
      them and then user space expect to be able to access what the gpu
      wrote through its userspace mapping it will be like any games in
      a casino. You will never ever win in the end. You are bound to
      loose. Just no way around that.

      So let just stop that non sense. Wake up from our dream and move

      I am not even talking about how invalidate_page is ignore and how
      well this will play with page write back.


      • #4
        Originally posted by oibaf View Post
        Is there a plan on enabling --enable-r600-llvm-compiler by default?
        It was disabled just 2 months ago, so i dont think so

        Building Mesa with --enable-r600-llvm-compiler is currently not recommended for anyone who doesn't want to work on fixing those issues.


        • #5
          I wonder if this is more or less useful with APUs - specifically the HUMA ones. Those are supposed to share common memory already, aren't they?


          • #6
            Originally posted by dungeon View Post
            It was disabled just 2 months ago, so i dont think so

            It was made effective on OpenGL when the compile flag is enabled + env variable is set. I suggest to enable by default the compile flag, so in OpenGL still is not enabled unless the env variable is set. IIRC the compile flag will also enable it in OpenCL.


            • #7
              Maybe it's done shoddy, but the idea seems very interesting to me, lbeight admittedly I am not familiar with the matter.

              Coherency has it costs, so it might be advantageos to be able to make CPU work with old-style non-Huma GPU, even if it would require change in MMU code...


              • #8
                support for userptr in radeon just landed:



                intel patches:

                Originally posted by Chris Wilson
                By exporting the ability to map user address and inserting PTEs
                representing their backing pages into the GTT, we can exploit UMA in order
                to utilize normal application data as a texture source or even as a
                render target (depending upon the capabilities of the chipset). This has
                a number of uses, with zero-copy downloads to the GPU and efficient
                readback making the intermixed streaming of CPU and GPU operations
                fairly efficient. This ability has many widespread implications from
                faster rendering of client-side software rasterisers (chromium),
                mitigation of stalls due to read back (firefox) and to faster pipelining
                of texture data (such as pixel buffer objects in GL or data blobs in CL)

                v2: Compile with CONFIG_MMU_NOTIFIER
                v3: We can sleep while performing invalidate-range, which we can utilise
                to drop our page references prior to the kernel manipulating the vma
                (for either discard or cloning) and so protect normal users.
                v4: Only run the invalidate notifier if the range intercepts the bo.
                v5: Prevent userspace from attempting to GTT mmap non-page aligned buffers
                v6: Recheck after reacquire mutex for lost mmu.
                v7: Fix implicit padding of ioctl struct by rounding to next 64bit boundary.
                v8: Fix rebasing error after forwarding porting the back port.
                v9: Limit the userptr to page aligned entries. We now expect userspace
                to handle all the offset-in-page adjustments itself.
                v10: Prevent vma from being copied across fork to avoid issues with cow.
                v11: Drop vma behaviour changes -- locking is nigh on impossible.
                Use a worker to load user pages to avoid lock inversions.
                v12: Use get_task_mm()/mmput() for correct refcounting of mm.

                NB: We still have performance concerns over the use of the linear lists
                and unfiltered notifies in mmu_notifier which do not scale to our use
                case, where we may have many thousands of objects being tracked.

                Signed-off-by: Chris Wilson <[email protected]>
                Cc: Tvrtko Ursulin <[email protected]>
                Cc: "Gong, Zhipeng" <[email protected]>