Daniel Vetter <daniel at ffwll.ch> writes: > On Tue, Oct 23, 2012 at 12:21 AM, Jesse Barnes <jbarnes at virtuousgeek.org> wrote: >> On Fri, 19 Oct 2012 18:03:24 +0100 >> Chris Wilson <chris at 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? > > Essentially the complication in pinning tons of memory that we don't > control, and hence might upset other kernel mm parts (like page > migration). For native objects we can always fix this by intercepting > more of the vm callbacks for the shmem backing storage (i.e. gemfs). > But for foreing storage we need to use the mmu_notifiers, and atm > those expect that a pte shootdown is synchronous (which we can't do), > so there's some work left to get done imo. So, the code isn't done, and the solution is to push it as root-only? Seriously? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20121023/cf669c29/attachment.pgp>
