[Piglit] [PATCH 1/2] KHR_debug: Support GLES2

[Fabian Bieler]

On 2014-03-12 19:51, Felipe Tonello wrote:
> Hi Fabian,
>
> On Tue, Mar 11, 2014 at 5:24 PM, Fabian Bieler <fabianbieler at fastmail.fm> wrote:
>> Hello!
>>
>> Sync objects, vertex arrays, queries, transform feedback objects and sampler
>> objects are not supported by gles2.
>
> Ok. But then how would this extension work with GLES2? I don't see
> anywhere in the spec saying what's the minimum requirement for OpenGL
> ES. It only states that requires OpenGL 1.1.
>
> For exemple, glObjectPtrLabel requires a sync object. So only this
> type of call will not work with OpenGL ES 2.0? Or the whole extension?
I'm pretty sure the extension is supposed to work with ES 2, too 
(according to the spec the OpenGL ES WG approved it in June 2012 which 
actually precedes the public release of the GLES 3 spec by a month). 
Also, I think there are still lots of ES 2 apps in development. Denying 
them access to this extension just because the usual "If the GL is 
OpenGL ES 2.0, all references to [...] are deleted" phrase was omitted 
from the spec seems silly to me.

glObjectPtrLabel could be dropped instead of being included as a useless 
entry-point in that case, although given that in Mesa ES 2 and ES 3 
share an api implementation this may not matter to us. (I don't know if 
there are drivers in Mesa that support ES 2 but not ES 3.)
>
>> ProgramPipeline objects and display lists are only supported by desktop gl.
>> #ifdef-hell, here we go again ;)
>>
>> Sorry for not picking up on these problems in my first review.
>
> No problem. :)
>
>>
>> Be sure to test sync objects in gles3 regardless of the presence of the
>> GL_ARB_sync extension.
>
> Ok. Also based on the documentation glFenceSync() is from OpenGL 3.2
> even without the extension. So I can probably send this small patch
> for now.
I'm afraid I'm not following. What small patch are you talking about?
>
>>
>> Also you may want to use the PFNGL*PROC types for the function pointers
>> (e.g.: PFNGLOBJECTLABELPROC), but I'm not sure that would actually improve
>> readability, so leaving these as-is is fine by me. :)
>
> I don't like the OpenGL way of naming callbacks either. :)
>
> Felipe
>