Results 1 to 7 of 7

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

  1. #1
    Join Date
    Jan 2007
    Posts
    14,294

    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
    52

    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
    752

    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
    366

    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
    128

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

Posting Permissions

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