Results 1 to 8 of 8

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

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

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

    http://www.phoronix.com/vr.php?view=MTczMTg

  2. #2

    Default

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

  3. #3
    Join Date
    Nov 2010
    Posts
    94

    Default

    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.
    http://lists.freedesktop.org/archive...ne/062633.html



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

    I am not even talking about how invalidate_page is ignore and how
    well this will play with page write back.
    http://lists.freedesktop.org/archive...ne/062646.html

  4. #4
    Join Date
    Feb 2008
    Posts
    1,083

    Default

    Quote 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.
    http://www.phoronix.com/scan.php?pag...tem&px=MTY2NjI

  5. #5
    Join Date
    Feb 2009
    Posts
    374

    Default

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

    Default

    Quote Originally Posted by dungeon View Post
    It was disabled just 2 months ago, so i dont think so



    http://www.phoronix.com/scan.php?pag...tem&px=MTY2NjI
    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. #7
    Join Date
    Jul 2012
    Posts
    147

    Default

    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. #8
    Join Date
    Jan 2009
    Location
    Vienna, Austria; Germany; hello world :)
    Posts
    640

    Default

    support for userptr in radeon just landed:

    http://cgit.freedesktop.org/~agd5f/l...based-on-fixes

    http://cgit.freedesktop.org/~agd5f/l...8068db01d0c444



    intel patches:

    Quote 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 <chris@chris-wilson.co.uk>
    Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
    Cc: "Gong, Zhipeng" <zhipeng.gong@intel.com>
    http://patchwork.freedesktop.org/patch/17966/

Posting Permissions

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