[Mesa-dev] [PATCH] Make single-buffered GLES representation internally consistent

[Gurchetan Singh]

Hi Ilia,

Setting it correctly initially is more messy.  At least in my use case, we
know the context type from EGL_RENDERABLE_TYPE before the framebuffer is
created.  We would need to add the context information to the visual used
by _mesa_initialize_window_framebuffer.  That requires including
main/mtypes.h in the EGL part of the source tree, which nobody else does
and leads to build system issues.

We could also make the change in _mesa_make_current instead of get.c, but
once again we'll be flipping the original value.  I'll send a modified
patch shortly unless somebody has any other ideas.

On Mon, Jun 27, 2016 at 7:55 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:

> On Mon, Jun 27, 2016 at 6:30 PM, Gurchetan Singh
> <gurchetansingh at chromium.org> wrote:
> > Hi Ilia,
> >
> > The changes for get.c where prompted by the es3fIntegerStateQueryTests
> (see
> > modules/gles3/functional/es3fIntegerStateQueryTests.cpp in the dEQP
> tree).
> > Specifically, these few lines:
> >
> >>> const GLint validInitialValues[] = {GL_BACK, GL_NONE};
> >>> m_verifier->verifyIntegerAnyOf(m_testCtx, GL_READ_BUFFER,
> >>> validInitialValues, DE_LENGTH_OF_ARRAY(validInitialValues));
> >>> expectError(GL_NO_ERROR);
> >
> > We initially set ColorReadBuffer to GL_FRONT in
> > _mesa_initialize_window_framebuffer for single-buffered configs.
>
> So ... could we initialize it to GL_BACK for GLES and avoid this pain?
> Unfortunately I have no idea what the implications of that would be.
>
> >
> > We could also make sure the context is single-buffered in get.c to
> further
> > avoid bugs.  Let me know if that works for you and I'll send a modified
> > patch.
> >
> > I do agree it is a bit hacky ... I'd definitely be interested in
> alternative
> > solutions.
>
> If you're flipping the value in the getter, you might as well set that
> to be the value from the very beginning. However I don't know what the
> effects of that are.
>
>   -ilia
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160628/38b4ab65/attachment-0001.html>