[Intel-gfx] [PATCH 21/21] drm/i915: Introduce vmap (mapping of user pages into video memory) ioctl

Chris Wilson chris at chris-wilson.co.uk
Tue Apr 19 08:20:47 CEST 2011


Thanks for excellent comments... Skipping to the end for a quick response:

On Mon, 18 Apr 2011 16:58:17 +0200, Daniel Vetter <daniel at ffwll.ch> wrote:
> I have hopes that we might be able to subsume that use-case into the
> single-shot use-case by beefing up pwrite/read with a blt variant that
> does the right thing for 2d/tiled buffers (and also handles stride
> mismatches). That feels a bit more generally useful, which is why I lean a
> bit towards it. On the other hand we might turn vmap on it's head and
> create an shm id out of a bo for X to use (if X shm turns out to be the
> only user for such a thing).

This is where I started: a new 2D pread/pwrite ioctl that used the BLT if
it so desired.

This was flawed in my use cases by the synchronous nature of the API I
used. When I thought about introducing async versions, I realised that it
became so much simpler if I moved the entirety of the serialisation into
userspace and vmap was born. And then I realised that a vmap bo could be
used in places other than simple BLT uploads and downloads.

Meanwhile, I'm intrigued by the idea of integrating SHM and bo... The use
case is a bit narrow though, latter protocol designs already use the bo as
the natural transport.

Anyway, it looks like my next task is see if vmap is a workable interface
for Mesa as well. I'd much prefer spending another couple of months
addressing your comments and widening the use cases, so I can drop this
patch for this merge window.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre



More information about the Intel-gfx mailing list