On Thu, Jun 7, 2018 at 6:02 PM Jason Ekstrand <ja...@jlekstrand.net> wrote: > > On June 7, 2018 16:47:17 Ilia Mirkin <imir...@alum.mit.edu> wrote: > > > On Thu, Jun 7, 2018 at 7:31 PM, Fritz Koenig <frkoe...@google.com> wrote: > >> On Thu, Jun 7, 2018 at 4:10 PM Ilia Mirkin <imir...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
