[Intel-gfx] [PATCH 2/5] drm/i915/guc: do not dump execlists state with GuC submission

[Daniele Ceraolo Spurio]

On 1/6/2021 11:43 AM, Chris Wilson wrote:
> Quoting Daniele Ceraolo Spurio (2021-01-06 17:21:16)
>>
>> On 1/5/2021 6:55 PM, Chris Wilson wrote:
>>> Quoting Daniele Ceraolo Spurio (2021-01-06 02:32:28)
>>>> On 1/5/2021 4:58 PM, Chris Wilson wrote:
>>>>> Quoting Daniele Ceraolo Spurio (2021-01-05 23:19:44)
>>>>>> GuC owns the execlists state and the context IDs used for submission, so
>>>>>> the status of the ports and the CSB entries are not something we control
>>>>>> or can decode from the i915 side, therefore we can avoid dumping it. A
>>>>>> follow-up patch will also stop setting the csb pointers when using GuC
>>>>>> submission.
>>>>>>
>>>>>> GuC dumps all the required events in the GuC logs when verbosity is set
>>>>>> high enough.
>>>>> Would not be worth including, or is it not very helpful for debugging
>>>>> curious engine stalls?
>>>> GuC is going to reset the engine if it stalls, so we should get the GuC
>>>> logs and the engine state included in the error state.
>>> Here we would be focusing on "why hasn't a request been submitted/executed".
>>> A bad request is usually self-evident, but a missing one is tricky.
>> Agreed, but I still don't think we could use the CSB info even if we
>> dumped it. We currently can't map CSB events in GuC submission mode to
>> specific contexts, because the ctx IDs used by the GuC do not map to the
>> ones used by i915. We've asked the GuC team to expose a way to do such a
>> mapping, but that's still under discussion. In the meantime we plan to
>> add a few traces to make sure the requests reach the GuC and use the GuC
>> logs for what goes on inside the FW (GuC logs include the context IDs it
>> uses for submission and all CSB events on high verbosity).
> I was more reflecting on what could be here instead. Details of the ctb?
> It would be great to have a snapshot of some relevant guc state, merely
> wonder if we could extract anything from the log automatically. As well
> as the usual what have we submitted to the guc.
> -Chris

Just realized I hadn't replied to this. We're still discussing with the 
GuC team about what type of GuC status we can extract and/or ask GuC to 
provide.
Request list aside, most of the i915-side of the GuC info is going to be 
global (single ctb channel, single submission queue into GuC), so it'll 
likely end up in a different printer function.

Daniele