<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <body> <div dir="auto"> <div dir="auto"><span style="font-size: 12pt;">On May 9, 2021 12:12:36 Martin Peres <martin.peres@free.fr> wrote:</span></div><div id="aqm-original" style="color: black;"> <div><br></div> <blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #808080; padding-left: 0.75ex;"> <div dir="auto">Hi,</div> <div dir="auto"><br></div> <div dir="auto">On 06/05/2021 22:13, Matthew Brost wrote:</div> <blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #0099CC; padding-left: 0.75ex;"> <div dir="auto">Basic GuC submission support. This is the first bullet point in the</div> <div dir="auto">upstreaming plan covered in the following RFC [1].</div> <div dir="auto"><br></div> <div dir="auto">At a very high level the GuC is a piece of firmware which sits between</div> <div dir="auto">the i915 and the GPU. It offloads some of the scheduling of contexts</div> <div dir="auto">from the i915 and programs the GPU to submit contexts. The i915</div> <div dir="auto">communicates with the GuC and the GuC communicates with the GPU.</div> </blockquote> <div dir="auto"><br></div> <div dir="auto">May I ask what will GuC command submission do that execlist won't/can't </div> <div dir="auto">do? And what would be the impact on users? Even forgetting the troubled </div> <div dir="auto">history of GuC (instability, performance regression, poor level of user </div> <div dir="auto">support, 6+ years of trying to upstream it...), adding this much code </div> <div dir="auto">and doubling the amount of validation needed should come with a </div> <div dir="auto">rationale making it feel worth it... and I am not seeing here. Would you </div> <div dir="auto">mind providing the rationale behind this work?</div> <div dir="auto"><br></div> <blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #0099CC; padding-left: 0.75ex;"> <div dir="auto"><br></div> <div dir="auto">GuC submission will be disabled by default on all current upstream</div> <div dir="auto">platforms behind a module parameter - enable_guc. A value of 3 will</div> <div dir="auto">enable submission and HuC loading via the GuC. GuC submission should</div> <div dir="auto">work on all gen11+ platforms assuming the GuC firmware is present.</div> </blockquote> <div dir="auto"><br></div> <div dir="auto">What is the plan here when it comes to keeping support for execlist? I </div> <div dir="auto">am afraid that landing GuC support in Linux is the first step towards </div> <div dir="auto">killing the execlist, which would force users to use proprietary </div> <div dir="auto">firmwares that even most Intel engineers have little influence over. </div> <div dir="auto">Indeed, if "drm/i915/guc: Disable semaphores when using GuC scheduling" </div> <div dir="auto">which states "Disable semaphores when using GuC scheduling as semaphores </div> <div dir="auto">are broken in the current GuC firmware." is anything to go by, it means </div> <div dir="auto">that even Intel developers seem to prefer working around the GuC </div> <div dir="auto">firmware, rather than fixing it.</div></blockquote></div><div dir="auto"><br></div><div dir="auto">Yes, landing GuC support may be the first step in removing execlist support. The inevitable reality is that GPU scheduling is coming and likely to be there only path in the not-too-distant future. (See also the ongoing thread with AMD about fences.) I'm not going to pass judgement on whether or not this is a good thing. I'm just reading the winds and, in my view, this is where things are headed for good or ill.</div><div dir="auto"><br></div><div dir="auto">In answer to the question above, the answer to "what do we gain from GuC?" may soon be, "you get to use your GPU." We're not there yet and, again, I'm not necessarily advocating for it, but that is likely where things are headed.</div><div dir="auto"><br></div><div dir="auto">A firmware-based submission model isn't a bad design IMO and, aside from the firmware freedom issues, I think there are actual advantages to the model. Immediately, it'll unlock a few features like parallel submission (more on that in a bit) and long-running compute because they're implemented in GuC and the work to implement them properly in the execlist scheduler is highly non-trivial. Longer term, it may (no guarantees) unlock some performance by getting the kernel out of the way. </div><div dir="auto"><br></div><div dir="auto"><br></div><div id="aqm-original" style="color: black;" dir="auto"><blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #808080; padding-left: 0.75ex;"> <div dir="auto">In the same vein, I have another concern related to the impact of GuC on </div> <div dir="auto">Linux's stable releases. Let's say that in 3 years, a new application </div> <div dir="auto">triggers a bug in command submission inside the firmware. Given that the </div> <div dir="auto">Linux community cannot patch the GuC firmware, how likely is it that </div> <div dir="auto">Intel would release a new GuC version? That would not be necessarily </div> <div dir="auto">such a big problem if newer versions of the GuC could easily be </div> <div dir="auto">backported to this potentially-decade-old Linux version, but given that </div> <div dir="auto">the GuC seems to have ABI-breaking changes on a monthly cadence (we are </div> <div dir="auto">at major version 60 *already*? :o), I would say that it is </div> <div dir="auto">highly-unlikely that it would not require potentially-extensive changes </div> <div dir="auto">to i915 to make it work, making the fix almost impossible to land in the </div> <div dir="auto">stable tree... Do you have a plan to mitigate this problem?</div> <div dir="auto"><br></div> <div dir="auto">Patches like "drm/i915/guc: Disable bonding extension with GuC </div> <div dir="auto">submission" also make me twitch, as this means the two command </div> <div dir="auto">submission paths will not be functionally equivalent, and enabling GuC </div> <div dir="auto">could thus introduce a user-visible regression (one app used to work, </div> <div dir="auto">then stopped working). Could you add in the commit's message a proof </div> <div dir="auto">that this would not end up being a user regression (in which case, why </div> <div dir="auto">have this codepath to begin with?).</div></blockquote></div><div dir="auto"><br></div><div dir="auto">I'd like to address this one specifically as it's become something of a speciality of mine the past few weeks. The current bonded submission model is bad. It provides a plethora of ways for a client to back itself into a corner and doesn't actually provide the guarantees the media driver needs for its real-time high-resolution decode. It's bad enough we're seriously considering ripping it out, backwards compatibility or not. The good news is that very little that your average desktop user does depends on it: basically just real-time >4K video decode.</div><div dir="auto"><br></div><div dir="auto">The new parallel submit API is much better and should be the path forward. (We should have landed parallel submit the first time around.) It isn't full of corners and does let us provides actual parallel execution guarantees. It also gives the scheduler the information it needs to reliably provide those guarantees.</div><div dir="auto"><br></div><div dir="auto">If we need to support the parallel submit API with the execlist back-end, that's totally possible. The choice to only implement the parallel submit API with GuC is a pragmatic one. We're trying to get upstream back on it's feet and get all the various up-and-coming bits of hardware enabled. Enabling the new API in the execlist back-end makes that pipeline longer.</div><div dir="auto"><br></div><div dir="auto"><br></div><div id="aqm-original" style="color: black;" dir="auto"><blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #808080; padding-left: 0.75ex;"><div dir="auto"></div> <div dir="auto">Finally, could you explain why IGT tests need to be modified to work the </div> <div dir="auto">GuC [1], and how much of the code in this series is covered by </div> <div dir="auto">existing/upcoming tests? I would expect a very solid set of tests to </div> <div dir="auto">minimize the maintenance burden, and enable users to reproduce potential </div> <div dir="auto">issues found in this new codepath (too many users run with enable_guc=3, </div> <div dir="auto">as can be seen on Google[2]).</div></blockquote></div><div dir="auto"><br></div><div dir="auto">The IGT changes, as I understand them, are entirely around switching to the new parallel submit API. There shouldn't be a major effect to most users.</div><div dir="auto"><br></div><div dir="auto">--Jason</div> </div></body> </html>