Mir on vmwgfx

[Alexandros Frantzis]

On Tue, Nov 05, 2013 at 03:17:49PM +0100, Thomas Hellstrom wrote:
> On 11/05/2013 02:55 PM, Alexandros Frantzis wrote:
[snip]
> >The main use case for this is to allow direct surface pixel access for
> >clients that either can't, or prefer not to use GL to render, while
> >still keeping compositing performant.
> >
> >In an early Mir server implementation, when the server had to deal with
> >"dumb" buffers it just mmap-ed the pixel data and uploaded them to a
> >texture with glTexImage2D(), so that the compositor could use them.
> >However, it turned out that this was very slow. To speed up things, we
> >added a backing DRIimage to the "dumb" gbm buffer, so that we could use
> >glEGLImageTargetTexture2DOES() with it to populate the texture (like we
> >do for non-dumb buffers), which is significantly faster.
> 
> I still don't quite understand how you get the pixel data in the
> dumb buffer to the DRIimage?

When creating a dumb GBM buffer we create a DRIimage associated with the
dumb DRM buffer using DRI's createImageFromName(). After that we treat the
GBM buffer as a normal non-dumb buffer as far as rendering is concerned:
we create an EGLImage using the GBM buffer object as the native pixmap
type, and "upload" the data with glEGLImageTargetTexture2DOES().

> On the glTexImage2D() approach, did you try ordinary shmem sharing
> rather than a dumb GBM buffer?
> It might have been that the GBM buffer was residing in uncached
> memory, which makes reading painfully slow.

This was a long time ago, and I don't remember if I tried using shmem
to share the data. I will keep that in mind, though, if we need to
implement a glTexImage2D() fallback.

> >If this is just a matter of reduced performance in the VMware driver for
> >this use case, then perhaps we should wait to see if it's actually a
> >problem before adding a special case for it in Mir. On the other hand,
> >if it is a matter of complicating the VMware driver excessively, we can
> >try to find a way to accommodate this elegantly in Mir. Would the
> >first approach (mmap-ing the dumb buffer and using glTexImage2D()) be
> >a better match for the VMware drivers?
> 
> In this case glTexImage2D() might be better since GBM dumb buffers
> reside in cached memory. However,
> it would be desirable only to copy the data that has been dirtied by
> the client. Our X server driver uses this approach.

As a first step, can we ignore this until it proves to be a performance
problem, or does even a simple implementation of supporting DRIimage for
dumb buffers fall into "complicating the VMware driver excessively"?

Thanks,
Alexandros