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

[Tapani Pälli]

On 08/21/2017 08:47 AM, Harish Krupo wrote:
> Hi Ilia,
> 
> On 08/21/2017 10:42 AM, Ilia Mirkin wrote:
>> 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.
>>
> 
> Ok, works with the evironment variable. What should be done in this 
> scenario? Should we wait for others?

I've send v2 of the Piglit test I did that includes enum test against 
enum from ARB_occlusion_query:

https://lists.freedesktop.org/archives/piglit/2017-August/022858.html

IMO we should guard against ARB enums, this can be done just to check if 
we are on ES/desktop.

Additionally we could (or should?) check 
GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN which comes with ES 3.0 in case 
context version is < 3.0.



>>>
>>> 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.
>>
> 
> Ok, I will go through the code, try to understand and see if it is 
> required.
> 
> Thank you
> 
> Regards
> Harish Krupo
> 
>>    -ilia
>>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev