Am Dienstag, den 06.11.2018, 15:28 -0500 schrieb Ilia Mirkin:
> On Tue, Nov 6, 2018 at 3:15 PM Gert Wollny <gert.wol...@collabora.com
> > wrote:
> >
> >
> > The extension has the status "not complete" but after reading is it
> > seems to describe what is needed from ARB_framebuffer_sRGB in GLES
> > 3.0,
Well, after starting to hacking it up and reading the finer details it
turns out that EXT_sRGB is not providing what GLES 3.0 needs:
EXT_sRGB says
"""
Accepted by the <format> and <internalformat> parameter of TexImage2D,
and TexImage3DOES. These are also accepted by <format> parameter
of TexSubImage2D and TexSubImage3DOES:
SRGB_EXT 0x8C40
SRGB_ALPHA_EXT 0x8C42
Accepted by the <internalformat> parameter of RenderbufferStorage:
SRGB8_ALPHA8_EXT 0x8C43
"""
whereas GLES 3.0 only knows the internal formats SRGB8 and
SRGB8_ALPHA8 but it doesn't use the unsized SRGB_EXT and SRGB_ALPHA_EXT
at all, and certainaly not as accepted formats.
Also there is
"""
4) What is the expectation for mipmap generation on SRGB textures?
Issue 24 from EXT_texture_sRGB gives two possible ways, will we leave
it similarly undefined, or is this not intended to be supported at all?
No. This in not likely to be used much so for simplicity let's not
require it. This will generate an INVALID_OPERATION error.
"""
which is also in conflict with GLES 3.0.
Which brings me back to what I was talking about yesterday: For
properly calculating GLES 3.0 support a flag is needed that says sRGB
render targets are supported without the need that such a fbo
attachment can switch between linear and sRGB.
Well, I'll think of something and send an RFC
Best,
Gert
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
