[Mesa-dev] [PATCH 13/14] egl: Track EGL_KHR_debug state when going through EGL API calls

[Adam Jackson]

On Wed, 2016-09-14 at 12:08 +0100, Emil Velikov wrote:

> Thanks for reminding me - eglQueryAPI should never throw an error,
> indeed. Since EGL_KHR_debug is applicable for functions_do_ throw an
> error, one should leave the API out of the spec text shouldn't they ?

I mean, sure, but this patch is against Mesa, not the spec.

> This is precisely what I'm talking about - one cannot relate the error
> label to a {surface,context,display} object that is yet to be found.
> As such the object label (and friends) should be related to the
> current thread.

I see your point, I'm just not sure what you want done about it. My
reading of the spec is that there are two ways an implementation can
handle this:

a) "The primary object should be the object the function operates on,
see table 13.2 which provides the recommended mapping between functions
and their primary object."

Note "recommended", which suggests the primary object could be
something else.

b) "<objectLabel> will contain the label attached to the primary object
of the message; Labels will be NULL if not set by the application.
[...] This <objectLabel> may be NULL even though the application
labeled the object. This is because it is possible an error was raised
while executing the command before the primary object was validated,
therefore its label can not be included in the callback."

This suggests that if the primary object can't be validated, then a
NULL label will be used.

Now to me, option b seems more conservative. Debug callbacks need to be
prepared for null object labels due to mandatory spec language. They
need to be prepared for unexpected primary objects only due to optional
spec language. And option b is the approach this patch takes,
entrypoints that error before the primary object is validated will
invoke the callback with a null object label.

If we want to amend the spec language, great, that's a fine idea, and
Khronos bugzilla is → that way. But even if we did, I think the
implementation in this patch (well, v3 of it) can be said to conform to
the spec as it currently exists, and that such amendment should not
invalidate existing implementations.

- ajax