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

Daniele Ceraolo Spurio daniele.ceraolospurio at intel.com
Wed Jan 6 17:21:16 UTC 2021

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).


> -Chris

More information about the Intel-gfx mailing list