<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Oct 23, 2018 at 1:30 PM Gert Wollny <<a href="mailto:gw.fossdev@gmail.com">gw.fossdev@gmail.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">From: Gert Wollny <<a href="mailto:gert.wollny@collabora.com" target="_blank">gert.wollny@collabora.com</a>> 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), and dEQP-GLES31.functional.fbo.srgb_write_control.framebuffer_srgb_unsupported_enum when extension is manually disabled via MESA_EXTENSION_OVERRIDE v2: - always enable the extension when sRGB is supported (Ilia Mirkin). - Correct handling by moving extension initialization to the place where gallium/st actually takes care of this. This also fixes properly disabling the extension via MESA_EXTENSION_OVERRIDE - reinstate check for desktop GL and add check for the extension when creating the framebuffer v3: - Only create sRGB renderbuffers based on Visual.srgbCapable when on desktop GL. v4: - Use PIPE_FORMAT_B8G8R8A8_SRGB to check for the capability, since this is also the format that is used top check for EGL_KHR_gl_colorspace support. virgl on a GLES host usually doesn't provide this format but one can make it available to signal that the host supports this extension. Signed-off-by: Gert Wollny <<a href="mailto:gert.wollny@collabora.com" target="_blank">gert.wollny@collabora.com</a>> --- src/gallium/docs/source/screen.rst | 3 +++ src/mesa/state_tracker/st_extensions.c | 8 +++++- src/mesa/state_tracker/st_manager.c | 37 ++++++++++++++++---------- 3 files changed, 33 insertions(+), 15 deletions(-) diff --git a/src/gallium/docs/source/screen.rst b/src/gallium/docs/source/screen.rst index 0abd164494..da677eb04b 100644 --- a/src/gallium/docs/source/screen.rst +++ b/src/gallium/docs/source/screen.rst @@ -477,6 +477,9 @@ subpixel precision bias in bits during conservative rasterization. 0 means no limit. * ``PIPE_CAP_MAX_VERTEX_ELEMENT_SRC_OFFSET``: The maximum supported value for of pipe_vertex_element::src_offset. +* ``PIPE_CAP_SRGB_WRITE_CONTROL``: Indicates whether the drivers on GLES supports + enabling/disabling the conversion from linear space to sRGB at framebuffer or + blend time. .. _pipe_capf: diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c index 798ee60875..38d6a3ed1d 100644 --- a/src/mesa/state_tracker/st_extensions.c +++ b/src/mesa/state_tracker/st_extensions.c @@ -1167,7 +1167,7 @@ void st_init_extensions(struct pipe_screen *screen, consts->MaxFramebufferSamples = get_max_samples_for_formats(screen, ARRAY_SIZE(void_formats), void_formats, 32, - PIPE_BIND_RENDER_TARGET); + PIPE_BIND_RENDER_TARGET); if (extensions->AMD_framebuffer_multisample_advanced) { /* AMD_framebuffer_multisample_advanced */ @@ -1393,6 +1393,12 @@ void st_init_extensions(struct pipe_screen *screen, } #endif + extensions->EXT_sRGB_write_control = + screen->is_format_supported(screen, PIPE_FORMAT_B8G8R8A8_SRGB, + PIPE_TEXTURE_2D, 0, 0, + (PIPE_BIND_DISPLAY_TARGET | + PIPE_BIND_RENDER_TARGET)); </blockquote><div> </div><div>This is kinda a hack because DISPLAY_TARGET has nothing to do with sRGB. sRGB is a 3D/framebuffer feature, unrelated to the window system. The sRGB property of the format is private within the application and is not visible outside of it. The window system doesn't care what is and isn't sRGB. I think you are just hiding a bug in your driver.</div><div> </div><div>Marek</div></div></div>