On 14 September 2016 at 15:00, Adam Jackson <a...@redhat.com> 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.
>
Fully agree - this is not something we need to address in mesa.
>> 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.
>
Again, fully agree - it's not something we should address in mesa.
Just checking that our understanding of the spec aligns and it [the
spec] leaves an open question. Then again... seems like I've missed
"recommended" which effectively gives implementations flexibility to
answer do things in a way they seem fit.
Thanks !
Emil
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
