Daniel Vetter <[email protected]> writes: > On Tue, Oct 23, 2012 at 12:21 AM, Jesse Barnes <[email protected]> > wrote: >> On Fri, 19 Oct 2012 18:03:24 +0100 >> Chris Wilson <[email protected]> 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?
pgpZOiC6AwtUX.pgp
Description: PGP signature
_______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
