[Mesa-dev] What is EGL_EXT_image_dma_buf_import image orientation as a GL texture?

[Pekka Paalanen]

Hi all,

I was working on Weston when I noticed that the
weston-simple-dmabuf-intel demo shows the window content in different
orientations depending on whether it is composited with GL or directly
scanned out. Obviously something is a miss. Then I went out to find
what the orientation should be according to specs, rather than just
flipping the y-invert flag in Weston without thinking.

The buffer is drawn with manual pixel-poking via mmap, and as a raw
memory buffer, the image origin (orientation) is at top-left. When this
is passed as a dmabuf to Weston and direct to scanout without any
attempts in y-flipping (imported through GBM -> drmAddFB2), the image
on the screen is on the same orientation as I would expect by reading
the pixel-poking code. So that looks good to me.

However, when the dmabuf is imported as an EGLImage and then composited
from a GL texture, the orientation flips. The image on screen is
y-inverted. Because Weston's GL-renderer works assuming the GL texture
coordinate orientation, it y-inverts the texture coordinates when the
image does *not* want y-flip. The dmabuf imported image is not flagged
with y-invert, hence the problem. I could easily fix that by just
toggling the flag, but I am not sure that's actually right.

The above means, that the pixel 0,0 at top-left corner of the buffer
ends up at GL texture coordinates 0,0. GL texture coordinates are
specified to have origin at the bottom-left. This is the conflict.
Importing the dmabuf semantically y-flips it.

Is the Mesa implementation correct or not?

I didn't find anything to answer that question. I skimmed through
https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
https://www.khronos.org/registry/gles/extensions/OES/OES_EGL_image_external.txt
Did I miss something?

Does it even matter if Mesa was incorrect, since it is now the de facto
spec, and presumably everyone has adjusted their implementations and
programs to match that already?

For comparison, doing an import of a (wl_drm) wl_buffer as an EGLImage
via EGL_WL_bind_wayland_display extension makes the image in GL texture
coordinate orientation. That is, the EGL query for the y-invert flag
returns the flag such, that the texture coordinate origin is at the
bottom-left of the image. This matches the GL spec and the assumption
in Weston's GL-renderer, so the image appears the right way up.

I'm tracking the issue so far at:
https://phabricator.freedesktop.org/T7475


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160613/f88d4b5f/attachment-0001.sig>