Re: [RFC] New dma_buf -> EGLImage EGL extension - Final spec published!

[Pekka Paalanen <ppaalanen@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4628 bytes --]

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_import.txt
> >> >> >
> >> >> > 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  


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev