On Fri, May 14, 2021 at 12:11:56PM +0100, Tvrtko Ursulin wrote: > > On 06/05/2021 20:13, Matthew Brost wrote: > > Basic GuC submission support. This is the first bullet point in the > > upstreaming plan covered in the following RFC [1]. > > > > At a very high level the GuC is a piece of firmware which sits between > > the i915 and the GPU. It offloads some of the scheduling of contexts > > from the i915 and programs the GPU to submit contexts. The i915 > > communicates with the GuC and the GuC communicates with the GPU. > > > > GuC submission will be disabled by default on all current upstream > > platforms behind a module parameter - enable_guc. A value of 3 will > > enable submission and HuC loading via the GuC. GuC submission should > > work on all gen11+ platforms assuming the GuC firmware is present. > > Some thoughts mostly relating to future platforms where GuC will be the only > option, and to some extent platforms where it will be possible to turn it on > for one reason or another. > > Debuggability - in the context of having an upstream way/tool for capturing > and viewing GuC logs usable for attaching to bug reports. > Agree. We have discussed this internally as an upstream requirement for quite sometime. > Currently i915 logs, can provide traces via tracepoints and trace printk, > and GPU error capture state, which provides often sufficient trail of > evidence to debug issues. > If we do this right, we should have something the same with GuC submission. > We need to make sure GuC does is not a black box in this respect. By this I > mean it does not hide a large portion of the execution flows from upstream > observability. > > This could mean a tool in IGT to access/capture GuC logs and update bug > filing instructions. > We have a few internal tools decode the GuC logs. One of these tools will be open sourced and on a public repo. We just need to decide which tool and make sure that tool works across all the distros. > Leading from here is probably the need for the GuC firmware team to cross > the internal-upstream boundary and deal with such bug reports on upstream > trackers. Upstream GuC is unlikely to work if we don't have such plan and > commitment. > I think we can land this code first as it is going be disabled by default. Certainly once we turn it on by default we need to have everything in place that you mention in this email. > Also leading from here is the need for GPU error capture to be on par from > day one which is I believe still not there in the firmware. > We are missing a register dump from the GuC on reset. No other way to say this than this has been huge miss by the i915 / GuC teams. This is something we absolutely need and it hasn't gotten done. I'll push on this and hopefully we can land this feature soon. > Another, although unrelated, missing feature on my wish list is firmware > support for wiring up accurate engine busyness stats to i915 PMU. I believe > this is also being worked on but I don't know when is the expected delivery. > This is landing this week I believe. Next upstream post should include an updated GuC firmware + code in the i915 that hooks into the PMU stats. Matt > If we are tracking a TODO list of items somewhere I think these ones should > be definitely considered. > > Regards, > > Tvrtko
