[Mesa-dev] [PATCH v4 3/6] mesa/es3.1: enable GL_ARB_texture_multisample for GLES 3.1

[Tapani Pälli]

On 06/26/2015 01:06 AM, Ilia Mirkin wrote:
> On Thu, Jun 25, 2015 at 4:22 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> On Thu, Jun 25, 2015 at 5:08 AM, Marta Lofstedt
>> <marta.lofstedt at linux.intel.com> wrote:
>>> From: Marta Lofstedt <marta.lofstedt at intel.com>
>>>
>>> v4 : only expose GL_ARB_texture_multisample enums
>>> for gles 3.1 and desktop GL.
>>
>> I was suspicious of this logic. Based on my reading of the code, what
>> your ARB_texture_multisample_es31 thing does is expose those enums
>> when *either* the driver enables ARB_texture_multisample *or* the
>> current context is ES3.1.
>>
>> ARB_draw_indirect_es31 has the same problem, btw.

I'm not sure I understand the issue. It should work fine with 'OR', if 
we have either of these then we expose the enum?

>> I could have misread the get.c extra_ext() logic, but I don't think I
>> have. As far as I can tell there's no way to (generically) AND these
>> things.

Why do we need AND? If you have 3.1 context then you *need* to support 
this enum. There is no such condition where you would have gles 3.1 
context but not the enum, right?


>> What you really need to do is create a whole new [GL, GL_CORE, ES31]
>> section in get_hash_params and update get_hash_generator.py
>> accordingly.
>
> An alternative, BTW, is to just say "screw it" and expose the enums in
> GL ES 3.0. In that case, just move the enums into a section that
> includes GLES3. I'm not sure how big of a deal it is. But your current
> patches are definitely wrong.

We do this, but we have explicit version check against version 3.1.

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


// Tapani