DRM/DRI Update

Thomas White taw at bitwiz.org.uk
Wed May 6 16:23:31 CEST 2009

On Wed, 6 May 2009 14:22:46 +0200
Nicola Mfb <nicola.mfb at gmail.com> wrote:

> I asked this for a long time as some tests blitting from video memory
> to video memory shows unacceptable high cpu time, while it should be
> near to 0.
> Yelding userspace should brings up average speed of device and realize
> some nice and smooth scrolling widgets even without dri.

Very true, busy-waiting like this is really bad.  An ioctl which sleeps
until rendering is complete seems to be the conventional solution where a
synchronisation point between the CPU and GPU is required.  A template for
such an ioctl is in my DRM interface specification, but not implemented yet.

The abstraction of memory allocation and command queue management
provided by DRM actually allows us a more elegant solution for cases where
this kind of synchronisation isn't immediately required.  The kernel knows
which memory buffers are referred to by a particular command sequence, so can
take the necessary care that those buffers stay in place for long enough.  In
fact, with the memory management abstracted via GEM, userspace neither knows
nor cares where the buffers actually are at any given moment.

Even if a process decides it needs access to that buffer a bit later on,
before the rendering is quite finished, it can use the "wait" ioctl - as an
argument, it takes a buffer handle to wait on.


More information about the devel mailing list