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

[Kyle Brenneman]

Note that the primary object can still be meaningful even on a function 
that's defined to never throw an error. Those functions could still send 
a WARN or INFO level message if they had reason to, just not a CRITICAL 
or ERROR level. Until any of those are added to Mesa, though, it's an 
academic distinction.

-Kyle

On 09/14/2016 08:00 AM, Adam Jackson wrote:
> 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
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev