Am Freitag, den 19.10.2018, 14:27 -0400 schrieb Ilia Mirkin: > On Fri, Oct 19, 2018 at 12:45 PM Gert Wollny <[email protected] > 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 > [email protected] > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
