[Bug 111140] Buffer corruption with Chromium on gnome-shell (wayland) after taking a screenshot

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=111140

--- Comment #14 from Lionel Landwerlin <lionel.g.landwerlin at linux.intel.com> ---
(In reply to Jonas Ådahl from comment #9)
> (In reply to Lionel Landwerlin from comment #8)
> > So looking at the way mutter bind the dmabuf shared with chromium to a 2D
> > texture, it does so through cogl_egl_texture_2d_new_from_image().
> > That function seems to rely on GL_OES_EGL_image_external extension :
> > https://www.khronos.org/registry/EGL/extensions/EXT/
> > EGL_EXT_image_dma_buf_import.txt
> > 
> > The extension has this bit in the spec :
> > 
> > 
> >     There is no support for most of the functions that manipulate
> >     other texture targets (e.g. you cannot use gl*Tex*Image*() functions with
> >     TEXTURE_EXTERNAL_OES).

Duh! I pointed to the wrong spec...
Here is the good one :
https://www.khronos.org/registry/OpenGL/extensions/OES/OES_EGL_image_external.txt

> > 
> > That makes me think what mutter is doing is illegal.
> 
> Does gl*Tex*Image() here imply glGetTexImage() too then you mean? Does
> reading from it mean "manipulate"?

My reading of manipulate goes for both read/write operations.
Essentially anything that could alter the metadata associated with the texture
(size, format and those hidden compression settings).

I agree that the spec is a bit vague on this point and I'm not 100% sure what
was the intent.
I could image we could allow glGet*Image* in the driver but that would
essentially be replicating what you would otherwise do in the application (e.g.
blit to an offscreen buffer and read that one back).

The problem is that the driver does a bunch of tracking on what you do with the
texture and puts it in the most sensible disposition for what it's used.
Once that goes out of sync with what the other processes have, we're in
trouble.

> 
> Either way, I created
> https://gitlab.gnome.org/GNOME/mutter/merge_requests/687 that should avoid
> reading directly from it. It didn't reproduce with or without it, so if
> anyone that can reproduce it can give it a test I'd appreciate it.

That fixes the problem on my side too. Thanks!

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20190716/5f38cf6b/attachment.html>