Mir on vmwgfx

Thomas Hellstrom thellstrom at vmware.com
Wed Nov 6 08:08:11 UTC 2013

On 11/05/2013 09:54 PM, Alexandros Frantzis wrote:
> On Tue, Nov 05, 2013 at 06:47:55PM +0100, Thomas Hellstrom wrote:
> [snip]
>>> 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.
> [snip]
> I think that being able to use accelerated buffers with linearly
> accessible pixels (in the DRI case: dumb drm buffers with associated
> DRIimages) should at least be an option, even if there is no guarantee
> of general support. All major implementations support it relatively
> efficiently at the moment, and although it's clear that using buffers in
> such a way may come with a performance penalty, or not be possible at
> all in some cases, I don't think we should preclude it from the API
> completely.

I understand your point, but the APIs look the way they look for a reason:
Instead of relying on mmaping a huge buffer, like old X, a modern 
should be smarter and use the preferred API method to transfer pixel
data to the accelerator. This is not just something that happened to be 
the way it is,
It's preceded and agreed upon by discussions by the various driver 
and It wouldn't surprise me if this access path will be blocked even 
with the major
drivers developers once they find out about it.

The GBM WRITE buffers are intended for cursors, and as such it's legal 
for a driver
to block read access, and even if they don't drivers may and will 
probably put these buffers in
write-combined or uncacheable memory which will make things like 
software compositing
painfully slow. I took a brief look at the Wayland code and they are 
using shmem + damage tracking
to handle this, and IMO that seems like a good choice. Another reason is 
that shmem can handle processor
cache coherency problems efficiently, whereas dumb buffers generally 
can't. They'd probably need to rely on
coherent (uncached) memory for this.

Also I think it's important to deal with this now, because once software 
Mir clients that have no idea about
damage tracking start to emerge, and if this usage path gets blocked, 
this issue will be immediately raised
from a vmware problem to a serious Mir performance problem.

I'm trying to tell you this as politely as I can, but I urge you to 
rework this path.

>> 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.
> Regardless of the GBM API concerns, I imagine that if a DRI
> implementation doesn't support the aforementioned operation it should
> report a failure, e.g., when trying to create the DRIimage for a dumb
> DRM buffer. If the VMware driver works this way then it would be easy
> for Mir to handle the error and fall back to some other supported
> method, e.g., a plain dumb buffer plus glTex{Sub}Image2D().
> Is this behavior feasible/reasonable from the VMware driver's
> perspective?

I think vmware will already error here, (if the error is propagated up 
the DRI stack, that is), and we could probably
work something more efficient out, but damage tracking is needed.

> Thanks,
> Alexandros

More information about the Mir-devel mailing list