[Bug 795518] gldownload: DMABuf export is broken on Intel

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=795518

Daniel Stone <daniel at fooishbar.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel at fooishbar.org

--- Comment #2 from Daniel Stone <daniel at fooishbar.org> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.