[Mesa-dev] [PATCH 1/2] mesa : MESA_framebuffer_flip_y extension

[Kristian Høgsberg]

On Thu, Jun 7, 2018 at 6:02 PM Jason Ekstrand <jason at jlekstrand.net> wrote:
>
> On June 7, 2018 16:47:17 Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>
> > On Thu, Jun 7, 2018 at 7:31 PM, Fritz Koenig <frkoenig at google.com> wrote:
> >> On Thu, Jun 7, 2018 at 4:10 PM Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> >>>
> >>> It's slightly different than what you've specified, but can't you
> >>> achieve this with GL_ARB_clip_control / GL_EXT_clip_control ?
> >>
> >> It can be, but there is a lot of extra work that needs to be done to
> >> get ReadPixels to work correctly.  It would be preferable to have the
> >> driver handle all of that work.
> >
> > A bit more prior art research:
> >
> > GL_MESA_pack_invert - specifies this precisely for glReadPixels.
> >
> > Your version of the spec needs more information. What does "flipped"
> > mean? Does it affect gl_FragCoord / gl_SamplePosition /
> > interpolateAtOffset? Does it affect the winding?

The effect of this extension is mostly not visible from GL - the
corner case where it is is if you take a texture from a flipped fbo
and bind to a non-flipped FBO. I think it makes more sense to specify
as not affecting anything, except for the pixels in the buffer ending
up upside down. That's more robust than listing all the state that it
does modify under the hood to achieve that and is more future proof
wrt extensions that add state that depends on coordinate system
polarity.

The use case in question is WebGL rendering in Chrome, which renders
to an FBO with the normal GL orientation. The end result is a buffer
that is upside down as far as KMS is concerned. We want to use the
buffer on a KMS plane, but not all display controllers support
y-flipping. We could (and tried) use all the extensions listed above
to flip the rendering, but got stuck on glReadPixels. If we have to
use a mesa extension to achieve this, I'd much rather depend on this
simple extension that just activates functionality already present
(and tested on each CI run). We also don't have to rewrite WebGL
visible state (viewports, scissor etc), which make this all much
simpler.

> > Might help to say that this is designed to undo the winsys flipping
> > relative to fbo rendering.
>
> More designed to emulate winsys flipping on a texture that isn't flipped.
> Basically, everything is "like normal" except that the result of your
> rendering is flipped vertically in the texture.  It's a bit wired but
> that's the idea.

It's kinda interesting how we ended up in this situation... mesa has
always flipped winsys FBOs and not user FBOs, but there's no overhead
in just flipping all FBOs, and back before we started importing X
pixmaps and EGLImages and binding to FBOs, there was no way to know
which way the user FBO was oriented in memory. So I don't think it was
ever necessary to distinguish between user and winsys FBOs, at least
not for coordinate orientation. Then we started rendering to external
buffers, and the non-flippedness of user FBOs leaked out and became de
facto convention, which we probably can't change now.

So today we have this situation where applications that render to a
winsys FBO work as they've always done, compositors or other apps that
knowingly render to a user FBO and then present the result externally
(eg KMS) just render upside down. And then WebGL, which has the
traditional GL orientation but render through an FBO to an EGLImage.

Kristian