[Mesa-dev] [PATCH v3 2/3] mesa/st: enable EXT_sRGB_write_control for drivers that support it

[Gert Wollny]

Am Freitag, den 19.10.2018, 14:27 -0400 schrieb Ilia Mirkin:
> On Fri, Oct 19, 2018 at 12:45 PM Gert Wollny <gert.wollny at collabora.c
> om> wrote:
> > 
> > Am Freitag, den 19.10.2018, 08:25 -0400 schrieb Ilia Mirkin:
> > > I don't think a PIPE_CAP is the answer here... I think you're on
> > > the right track with format checks and whatnot.
> > 
> > The problem is that with an GLES host, the checked sRGB format
> > might be supported by virgl, but not EXT_sRGB_write_control, so the
> > guest will
> 
> Perhaps virglrenderer should not expose e.g. PIPE_DISPLAY_TARGET for
> srgb if it doesn't support EXT_sRGB_write_control.
Given that sRGB is supported on a GLES host I'm wondering what would be
the implications of disabling PIPE_BIND_DISPLAY_TARGET for sRGB. My
guess is that it would downgrade functionality, - after all the flag is
supposedly related to *flush_front_buffer*, and has nothing whatsoever
to do with the ability to switch FRAMEBUFFER_SRGB, so I don't see that
not exposing this flag would be a good solution. 

> The extensions exposed should be a function of what the driver
> supports. 
Of course, but the question is how to properly communicate what the
driver can or can't do. 

> What is so special about EXT_sRGB_write_control that each driver must
> determine individually for just that one extension that can't be
> derived from the supported formats and bind flags?
The problem is not the extension as such, but the way virgl works. The
host driver can be anything, and even though it might support the
equivalent of PIPE_BIND_DISPLAY_TARGET for sRGB, that doesn't mean that
it necessarily exposes EXT_sRGB_write_control, and this wouldn't be a
bug. Unfortunately, the only proper way to handle the guest using this
extension is to do the same calls on the host, so I need to communicate
 the ability to do that call to the guest, and virgl needs to
communicate this to gallium. One way could be not exposing
PIPE_BIND_DISPLAY_TARGET, the other way would be another CAP. 

In summary, if I can somehow confirm that not exposing
PIPE_BIND_DISPLAY_TARGET for sRGB doesn't downgrade functionality, then
 fine, this is the solution I'd choose, but otherwise I don't see a way
around another CAP.

Best,
Gert

> 
>   -ilia
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev