User Ptr Support Proposed For AMD's Radeon DRM Driver

[phoronix]

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

[oibaf]

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

[Mat2]

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/archives/dri-devel/2014-June/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/archives/dri-devel/2014-June/062646.html

[dungeon]

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?page=news_item&px=MTY2NjI

[benmoran]

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?

[oibaf]

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.

[Brane215]

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

[kernelOfTruth]

support for userptr in radeon just landed:

http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.17-rebased-on-fixes

http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-3.17-rebased-on-fixes&id=f9ae35dd88317344633a99b50e8068db01d0c444

intel patches:

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

http://patchwork.freedesktop.org/patch/17966/