Mir on vmwgfx

Thomas Hellstrom thellstrom at vmware.com
Tue Nov 5 17:47:55 UTC 2013

On 11/05/2013 04:00 PM, Alexandros Frantzis wrote:
> 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().

Alexandros, unfortunately casting a dumb buffer to an accelerated GBM 
buffer is as much of an API
violation as the other way around, and works on some drivers for the 
same reason, but may stop working at
any point in time. I don't think any patches utilizing this approach 
will ever make it upstream.

The APIs for accelerated buffers deliberately try to avoid mmap. The 
reason is that there are coherency
problems. In some cases cache flushes, in other cases, like vmwgfx, 
expensive data transfers.

Imagine someone mmaping and writing a single character on a 3200x1200 
canvas, then try to make an
accelerated buffer out of this. Obviously a 3200x1200 texsubimage for 
each character will yield unacceptable performance,
A non-coherent driver will likewise need to perform a 3200x1200 cache 
flush or data transfer which will also yield
unacceptable performance. The correct solution here is a character size 
texSubImage or writePixels operation. If performed on the
server this means some form of damage tracking being communicated with 
the buffer, like Wayland does.

> 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"?

Unfortunately I don't think this is an option for us. Even if we'd 
ignore the API violation, without some form of synchronization 
information telling us transfer directions and dirty regions it would be 
too inefficient.


> Thanks,
> Alexandros

More information about the Mir-devel mailing list