From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [PATCH 18/18] drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl Date: Tue, 23 Oct 2012 10:50:10 -0700 Message-ID: <87vce16pt9.fsf@eliezer.anholt.net> References: <1350666204-8101-1-git-send-email-chris@chris-wilson.co.uk> <1350666204-8101-18-git-send-email-chris@chris-wilson.co.uk> <20121022152110.6c983c10@jbarnes-desktop> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1037327491==" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Daniel Vetter , Jesse Barnes Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org --===============1037327491== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Daniel Vetter writes: > On Tue, Oct 23, 2012 at 12:21 AM, Jesse Barnes wrote: >> On Fri, 19 Oct 2012 18:03:24 +0100 >> Chris Wilson 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? --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlCG2NIACgkQHUdvYGzw6vcPNgCdG6p1q5pouKAbycZbVfGum74m M/IAni9A0RX23yNEaEEc8k1ZoztCp2pu =M8Qb -----END PGP SIGNATURE----- --=-=-=-- --===============1037327491== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx --===============1037327491==--