Re: [PATCH 18/18] drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl

[Jesse Barnes <jbarnes@virtuousgeek.org>]

On Fri, 19 Oct 2012 18:03:24 +0100
Chris Wilson <chris@chris-wilson.co.uk> wrote:

> 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).
> 
> v2: Compile with CONFIG_MMU_NOTIFIER

I want to understand the root-only nature of this better.

Is locking complexity the only reason we can't treat these pages like
normal BOs which can be swapped out from under us as long as they're
not pinned into the GTT?  Or are there other complications in managing
the refcount for these pages?

Reminds me: do we also check our bo allocations against the current
task's address space, data, file size, locked memory, file count,
and rss limits?  I dug into the shmem code at one point and seem to
remember that we didn't.  If not, it might be a good thing to add under
a new config option at some point.

-- 
Jesse Barnes, Intel Open Source Technology Center