[Mesa-dev] [PATCH 1/2] mesa: GL_EXT_texture_norm16 extension plumbing
Ilia Mirkin
imirkin at alum.mit.edu
Tue Apr 17 18:11:33 UTC 2018
On Tue, Apr 17, 2018 at 1:52 PM, Ian Romanick <idr at 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.palli at 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.
-ilia
More information about the mesa-dev
mailing list