[Mesa-dev] [PATCH 0/3] GREMEDY_string_marker support

[Ilia Mirkin]

On Mon, Aug 17, 2015 at 2:06 PM, Rob Clark <robdclark at gmail.com> wrote:
> On Mon, Aug 17, 2015 at 1:12 PM, Ian Romanick <idr at freedesktop.org> wrote:
>> On 08/10/2015 09:15 AM, Rob Clark wrote:
>>> From: Rob Clark <robclark at freedesktop.org>
>>>
>>> Punch it through mesa and gallium, plus implementation in freedreno to
>>> serve as an example.  Radeon should be able to do a similar thing with
>>> no-op packets.  Not sure about other drivers.
>>
>> The idea behind this extension (and the way the only other
>> implementation of it works) is that the debug tool itself exposes it to
>> the application without the driver knowing.  This allows the developer
>> to set breakpoints on certain messages, etc.
>>
>> Given that usage model, there may be applications that will start
>> calling glStringMarkerGREMEDY as soon as the extension string is there.
>>  After all, you'll on see that in the debugger, so who cares about
>> performance there, right? :(  I think it would be better to not enable
>> the extension by default.  Maybe require a driconf option or debug
>> context or something.
>>
>>> Plan to use this extension from apitrace, to emit call and frame #'s
>>> for draw commands, so I can find the corresponding draw from cmdstream
>>> dump (ie. to debug lockups, incorrect rendering, etc).
>>
>> Clever. :)
>>
>> I think the other way to do this would be to insert a fence with an
>> object label.
>>
>>     GLsync fence = glFenceSync(GL_SYNC_GPU_COMMANDS_COMPLETE, 0);
>>
>>     glObjectPtrLabel(fence, 0, "call ### frame ###");
>
>
> José Fonseca mentioned on apitrace list, when I submitted
> corresponding apitrace patch, KHR_debug..  which already has
> GL_DEBUG_TYPE_MARKER which seems to be intended for this sort of
> usage.
>
> So I was kinda thinking to respin these patches to add calls to
> Driver.EmitStringMarker() in case of GL_DEBUG_TYPE_MARKER.  (Although
> I was a bit unsure if that should be *in addition to* or *instead of*
> the normal codepaths for glDebugMessageInsert())

More generally, the issue is that KHR_debug is not hooked up to
gallium. It'd be really awesome to have that.

  -ilia