GNOME Bugzilla – Bug 795518
gldownload: DMABuf export is broken on Intel
Last modified: 2018-11-03 12:05:38 UTC
It would seem that Mesa/Intel recently enabled titling or frame buffer compression on the exported DMABuf, and that broke this pipeline: gst-launch-1.0 gltestsrc ! glcolorconvert ! gldownload ! waylandsink Though, right now, we just create EGLImage from texture, which then export whatever internal format was internally chosen. The way the export method work, is that we get to know the format at exportation time: https://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/gst-libs/gst/gl/egl/gsteglimage.c#n516 But right now we pass NULL/NULL for the format/modifiers pair. I propose to read and validate these value for now, and just fail the export if it there is a modifiers, or if the format does not match the expected one. If we figure-out how to add modifiers support in GStreamer later, we could revisit and enable this again.
The output says it's tiled, but the Mesa API says it's not: Format AB24 modififers 0 So we also hit a mesa regression here.
Yeah. Previously Intel would only pick X-tiling for these formats, and provide a linear view of that. It now provides Y-tiling, which does not get transparently detiled. The export function doesn't support modifiers - it hardcodes 0 which is not invalid but in fact explicitly linear, so was just as broken for X-tiling. It also doesn't support multi-plane buffers, so even if you were to fix the modifier bit then it would break for compressed buffers. This is a regression in the strict sense of the word, but there is no requirement for arbitrary memory allocated by Mesa to be exportable at all. Drivers are completely within their rights to allocate memory which is _not_ describable to external components - tiling/compression/etc formats which are only hardware accessible. Adding support for modifiers won't fix that, and you'll just see exotic breakage on more complex hardware like AMD and NVIDIA. You can even paint yourself into this corner with Intel if you try. I know this isn't the answer you want to hear, but the answer remains the same: the export-dmabuf extension was only ever intended as a very short-term hack for very specific usage, and that it's broken isn't surprising. Some of it is fixable, some of it will never be fixable. The long-term solution is external allocation and import into GL, e.g. through GBM.
Created attachment 371396 [details] [review] eglimage: Fail exportation if a modififer is used We don't support modififers and that would result in bad image being displayed. Note that this fix does not fix the issue because Mesa fails at reporting that a modififer is used.
Well, gst_eglExportDMABUFImageQueryMESA() can fail and should fail in whatever case the format cannot be represented by (fd, fourcc, modififers) trio. Regardless if the API sucks or not does not matter, it should be implement properly. Btw, bool eglExportDMABUFImageMESA () { return false; } Seems totally fine implementation imho if that's all that this API can provide. If this support is in GStreamer is because someone is using it, I only cleanup and merged the provided code.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/441.