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 -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
