Questions about libdrm_intel and way to share physical memory between CPU and GPU

[Eric Anholt]

On Thu, 2 Jun 2011 19:42:03 +0100, Alan Cox <alan at lxorguk.ukuu.org.uk> wrote:
> On Sat, 28 May 2011 09:54:01 +0100
> Chris Wilson <chris at chris-wilson.co.uk> wrote:
> 
> > On Fri, 27 May 2011 14:37:45 -0700, "Segovia, Benjamin" <benjamin.segovia at intel.com> wrote:
> > > Hello gurus,
> > > 
> > > I have two question mostly regarding libdrm_intel
> > > 
> > > 1/ What is the difference between drm_intel_bo_map and drm_intel_gem_bo_map_gtt ?
> > bo_map uses the CPU domain, and so is CPU linear (needs sw detiling).
> > bo_gtt_map uses the uncached [WC] GTT domain, and so is GPU linear
> > (detiling is performed by the hardware using a fence).
> > 
> > > 2/ Will it be possible (or is it already possible) to directly share a regularly allocated piece of physical memory? Typical use case is the following one using OpenCL API:
> > 
> > Yes. I've proposed a vmap interface to bind user-pages into the GTT,
> > similar to a completely unused bit of TTM functionality.
> 
> It seems to me that stolen memory and other things could all be sorted
> out somewhat if the GEM layer and GEM as shmemfs backing were split apart
> a bit. A 'privately backed' GEM object wouldn't be able to support
> flink() but I can't find much else that would break ?
> 
> Wondering about this for things like the GMA500, and also to get back all
> that memory the i9xx driver burns on a PC.

I'd much rather be able to just hand that memory off to the kernel to
use along with everything else and have there be nothing magic about it.
But as I recall, the mtrr mappings of that memory was often goofy, so it
may take some work to clean it up.
-------------- 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/dri-devel/attachments/20110603/c296ad8e/attachment.pgp>