On Fri, 17 Jun 2016 11:44:34 -0400 Rob Clark robdclark@gmail.com wrote:
On Fri, Jun 17, 2016 at 9:31 AM, Pekka Paalanen ppaalanen@gmail.com wrote:
On Fri, 17 Jun 2016 08:26:04 -0400 Rob Clark robdclark@gmail.com wrote:
On Fri, Jun 17, 2016 at 3:59 AM, Pekka Paalanen ppaalanen@gmail.com wrote:
On Thu, 16 Jun 2016 10:40:51 -0400 Rob Clark robdclark@gmail.com wrote:
On Mon, Feb 25, 2013 at 6:54 AM, Tom Cooksey tom.cooksey@arm.com wrote:
Hi All,
The final spec has had enum values assigned and been published on Khronos:
http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_imp...
Thanks to all who've provided input.
May I also pull your attention to a detail with the existing spec and Mesa behaviour I am asking about in https://lists.freedesktop.org/archives/mesa-dev/2016-June/120249.html "What is EGL_EXT_image_dma_buf_import image orientation as a GL texture?" Doing a dmabuf import seems to imply an y-flip AFAICT.
I would have expected that *any* egl external image (dma-buf or otherwise) should have native orientation rather than gl orientation. It's somewhat useless otherwise.
In that case importing dmabuf works differently than importing a wl_buffer (wl_drm), because for the latter, the y-invert flag is returned such that the orientation will match GL. And the direct scanout path goes through GBM since you have to import a wl_buffer, and I haven't looked what GBM does wrt. y-flip if anything.
I didn't read it carefully yet (would need caffeine first ;-)) but EGL_KHR_image_base does say "This extension defines a new EGL resource type that is suitable for sharing 2D arrays of image data between client APIs" which to me implies native orientation. So that just sounds like a mesa bug somehow?
That specific sentence implies nothing about orientation to me. Furthermore, the paragraph continues:
"Although the intended purpose is sharing 2D image data, the underlying interface makes no assumptions about the format or purpose of the resource being shared, leaving those decisions to the application and associated client APIs."Might "format" include orientation?
How does "native orientation" connect with "GL texture coordinates"? The latter have explicitly defined orientation and origin. For use in GL, the right way up image is having the origin in the bottom-left corner. An image right way up is an image right way up, regardless which corner is the origin. The problem comes when you start using coordinates.
Do you just get that w/ i965? I know some linaro folks have been using this extension to import buffers from video decoder with freedreno/gallium and no one mentioned the video being upside down.
Intel, yes, but since this happens *only* for the GL import path and direct scanout is fine without y-flipping, I bet people just flipped y and did not think twice, if there even was a problem. I just have a habit of asking "why". ;-)
well, if possible, try with one of the gallium drivers?
A good idea, I just need to do it at home with nouveau... which means I probably won't be getting there any time soon.
I'm honestly not 100% sure what it is supposed to be according to the spec, but I do know some of the linaro folks were doing v4l2dec -> glimagesink with dmabuf with both mali (I think some ST platform?) and freedreno (snapdragon db410c), and no one complained to me that the video was upside down for one or the other. So I guess at least gallium and mali are doing the same thing. No idea if that is the same thing that i965 does.
Thanks, pq
BR, -R
After all, using GL with windows and FBOs and stuff you very often find yourself upside down, and I suspect people have got the habit of just flipping it if it does not look right the first time. See e.g. the row-order of data going into glTexImage2D...
If the answer is "oops, well, dmabuf import is semantically y-flipping when it should not, but we cannot fix it because that would break everyone", I would be happy with that. I just want confirmation before flipping the flip flag. :-)
Thanks, pq