[Mesa-dev] [PATCH v2 1/4] mesa: add GREMEDY_string_marker

[Ian Romanick]

On 01/20/2016 11:48 AM, Rob Clark wrote:
> On Wed, Jan 20, 2016 at 2:44 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> On Wed, Jan 20, 2016 at 2:32 PM, Rob Clark <robdclark at gmail.com> wrote:
>>> From: Rob Clark <robclark at freedesktop.org>
>>> diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c
>>> index 9e66109..fc3c6d0 100644
>>> --- a/src/mesa/main/errors.c
>>> +++ b/src/mesa/main/errors.c
>>> @@ -1276,6 +1276,19 @@ _mesa_free_errors_data(struct gl_context *ctx)
>>>     mtx_destroy(&ctx->DebugMutex);
>>>  }
>>>
>>> +void GLAPIENTRY
>>> +_mesa_StringMarkerGREMEDY(GLsizei len, const GLvoid * string)
>>> +{
>>> +   GET_CURRENT_CONTEXT(ctx);
>>> +   if (ctx->Driver.EmitStringMarker) {
>>
>> Traditionally this is done more like
>>
>> if (!ctx->Const.GREMEDY_bla) {
>>   _mesa_error(go away);
>>   return;
>> }
>>
>> assume that EmitStringMarker is set, otherwise it's the driver's fault
>> for enabling this ext and not providing a driver callback.
>>
>> But as discussed on IRC, I don't think we should have the GREMEDY
>> stuff at all in the first place. Would be interested in knowing what
>> others have to say.
>>
> 
> fwiw, the gremedy part is left over from early incarnation of this,
> before I discovered the khr_debug part.  But figured since I needed
> the EmitStringMarker driver entrypoint anyways, it was trivial to keep
> the extension around (hidden by default).  Maybe some old games/etc
> already have support for it.

That's probably fair.  Maybe we could enable it in debug contexts too.
*shrug*

> BR,
> -R