[Mesa-dev] [PATCH] gles2: Support for GL_EXT_occlusion_query_boolean

Ilia Mirkin imirkin at alum.mit.edu
Mon Aug 21 05:12:53 UTC 2017

On Mon, Aug 21, 2017 at 12:52 AM, Harish Krupo
<harish.krupo.kps at intel.com> wrote:
> Hi Ilia,
> On 08/18/2017 07:20 PM, Ilia Mirkin wrote:
>> Why the static data changes? Also, I haven't double checked the code, but
>> I'm almost certain this is incomplete. You have to add code disallowing the
>> other enums from being used on es2.
> Thank you for pointing out that code is required to disallow usage of other
> enums in gles2. When adding code to check for gles2 context I ran into an
> other issue. The issue was that when one requests mesa for a gles2 context,
> it actually returns a gles3.1 context. So if the code checks for an es2
> context, it will return false and the enums will be allowed. Could you
> suggest a way out of this?

Contexts are upgraded automatically -- this is allowed by the spec.
You could run with MESA_GLES_VERSION_OVERRIDE=2.0 to force it though.
Also one has to ask the question of whether the *EXT functions should
allow the enums that have been added to the core ES functions. I
suspect so, but it's a reasonable question.

> As for the static data changes, I wasn't exactly sure of the file's usage, I
> saw that the ARB versions of the functions were also present, so I added it
> there. If it is not required, I will remove it in the next version of the
> patch. Could you please explain why it is not needed?

I honestly don't remember all the logic. You'll need to work out what
it's for -- as I recall there are comments. Maybe it affects the list
of exposed symbols for linking, which this does not need to be one of.
But maybe it's for something dispatch-table-related, in which case it
may be necessary. I do know it's not *always* necessary though.


More information about the mesa-dev mailing list