On 17.04.2018 21:11, Ilia Mirkin wrote:
On Tue, Apr 17, 2018 at 1:52 PM, Ian Romanick <i...@freedesktop.org> wrote:
On 04/17/2018 05:19 AM, Ilia Mirkin wrote:
On Mon, Apr 16, 2018 at 11:22 PM, Tapani Pälli <tapani.pa...@intel.com> wrote:
On 17.04.2018 02:42, Ilia Mirkin wrote:
differentiating the case "have NV_image_formats but not
EXT_texture_norm16"?
I had a version that added another boolean but since both of these
extensions require GL ES 3.1 it seemed to me that it would be unlikely to
have platform to support 3.1 but not EXT_texture_norm16 (?)
Then why are there separate enables for this and NV_image_formats in
the gl_extensions object?
Note that doing this properly here is a bit tricky -- it's not like
one would do "#extension GL_EXT_texture_norm16: enable". So you'd have
to check in the GL context for whether it's enabled somehow.
[As an aside, any impl that supports ARB_shader_image_load_store will
support all of this. I don't know what the practical restrictions are
on ES hardware -- Adreno does norm16 just fine, but others might not?]
I guess if this is restricted to GLES 3.1+, it should be fine to skip an
explicit enable. When Tapani asked me about this on IRC, I was thinking
this would be more generally enabled. There's certainly GLES 2.0
hardware in Mesa that cannot do this extension.
The extension itself nominally requires ES 3.1 in the first place.
Adreno A3xx hardware could do it otherwise (it doesn't currently
expose ES 3.1, and it's unlikely it ever will, although I think
technically it could with a kludge here and there).
We could just expose it unconditionally for ES 3.1, and then when some
hardware comes along that can't do it, worry about it then?
Mainly I'm trying to avoid non-working toggles.
FWIW that's fine for me, I'll send a v2 with checks in place for gles31
and add some more tests.
// Tapani
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
