[Mesa-dev] [PATCH] gles2: Support for GL_EXT_occlusion_query_boolean
tapani.palli at intel.com
Mon Aug 21 06:06:32 UTC 2017
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
>>> 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
>>> 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:
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
>>> 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
> Thank you
> Harish Krupo
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
More information about the mesa-dev