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