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