Am Mittwoch, den 17.10.2018, 12:56 -0400 schrieb Ilia Mirkin:
> On Wed, Oct 17, 2018 at 12:39 PM Gert Wollny <gw.foss...@gmail.com>
> wrote:
> >
> > From: Gert Wollny <gert.wol...@collabora.com>
> >
> > With this patch the extension EXT_sRGB_write_control is enabled for
> > gallium drivers that support sRGB formats as render targets.
> >
> > Tested (and pass) on r600(evergreen) and softpipe:
> >
> > dEQP-
> > GLES31.functional.fbo.srgb_write_control.framebuffer_srgb_enabled*
> >
> > with "MESA_GLES_VERSION_OVERRIDE=3.2" (the tests needlessly check
> > for this)
> >
> > Signed-off-by: Gert Wollny <gert.wol...@collabora.com>
> > ---
> > src/mesa/state_tracker/st_manager.c | 17 +++++++++--------
> > 1 file changed, 9 insertions(+), 8 deletions(-)
> >
> > diff --git a/src/mesa/state_tracker/st_manager.c
> > b/src/mesa/state_tracker/st_manager.c
> > index ceb48dd490..562b12a1ef 100644
> > --- a/src/mesa/state_tracker/st_manager.c
> > +++ b/src/mesa/state_tracker/st_manager.c
> > @@ -457,14 +457,12 @@ st_framebuffer_create(struct st_context *st,
> > * format such that util_format_srgb(visual->color_format) can
> > be supported
> > * by the pipe driver. We still need to advertise the
> > capability here.
> > *
> > - * For GLES, however, sRGB framebuffer write is controlled only
> > by the
> > - * capability of the framebuffer. There is
> > GL_EXT_sRGB_write_control to
> > - * give applications the control back, but sRGB write is still
> > enabled by
> > - * default. To avoid unexpected results, we should not
> > advertise the
> > - * capability. This could change when we add support for
> > - * EGL_KHR_gl_colorspace.
> > + * For GLES, however, sRGB framebuffer write is initially only
> > controlled
> > + * by the capability of the framebuffer, but with
> > GL_EXT_sRGB_write_control
> > + * control is given back to the applications. Similar to
> > desktop GL
> > + * support for this extension depends EXT_framebuffer_sRGB.
> > */
> > - if (_mesa_is_desktop_gl(st->ctx)) {
> > + {
> > struct pipe_screen *screen = st->pipe->screen;
> > const enum pipe_format srgb_format =
> > util_format_srgb(stfbi->visual->color_format);
> > @@ -475,8 +473,11 @@ st_framebuffer_create(struct st_context *st,
> > PIPE_TEXTURE_2D, stfbi-
> > >visual->samples,
> > stfbi->visual->samples,
> > (PIPE_BIND_DISPLAY_TARGET |
> > - PIPE_BIND_RENDER_TARGET)))
> > + PIPE_BIND_RENDER_TARGET)))
> > {
> > mode.sRGBCapable = GL_TRUE;
> > + /* Exposing this as extension is only needed on GLES */
> > + st->ctx->Extensions.EXT_sRGB_write_control =
> > !_mesa_is_desktop_gl(st->ctx);
>
> Having weird dependencies in extension enables creates a lot of
> confusion. I'd just flip it to true.
My resasoning here was that this is a GLES only extension, but I now
see that this is acctually done via the extension table.
Thanks for all the pointers.
Gert
>
> > + }
> > }
> >
> > _mesa_initialize_window_framebuffer(&stfb->Base, &mode);
> > --
> > 2.18.1
> >
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
