<!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 10, 2021 08:55:55 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">On 10/05/2021 02:11, Jason Ekstrand 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">On May 9, 2021 12:12:36 Martin Peres <martin.peres@free.fr> wrote:</div> <div dir="auto"><br></div> <blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #9933CC; 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 #669900; 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 #669900; 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 dir="auto"><br></div> <div dir="auto">Yes, landing GuC support may be the first step in removing execlist </div> <div dir="auto">support. The inevitable reality is that GPU scheduling is coming and </div> <div dir="auto">likely to be there only path in the not-too-distant future. (See also </div> <div dir="auto">the ongoing thread with AMD about fences.) I'm not going to pass </div> <div dir="auto">judgement on whether or not this is a good thing. I'm just reading the </div> <div dir="auto">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 </div> <div dir="auto">GuC?" may soon be, "you get to use your GPU." We're not there yet and, </div> <div dir="auto">again, I'm not necessarily advocating for it, but that is likely where </div> <div dir="auto">things are headed.</div> </blockquote> <div dir="auto"><br></div> <div dir="auto">This will be a sad day, especially since it seems fundamentally opposed </div> <div dir="auto">with any long-term support, on top of taking away user freedom to </div> <div dir="auto">fix/tweak their system when Intel won't.</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">A firmware-based submission model isn't a bad design IMO and, aside from </div> <div dir="auto">the firmware freedom issues, I think there are actual advantages to the </div> <div dir="auto">model. Immediately, it'll unlock a few features like parallel submission </div> <div dir="auto">(more on that in a bit) and long-running compute because they're </div> <div dir="auto">implemented in GuC and the work to implement them properly in the </div> <div dir="auto">execlist scheduler is highly non-trivial. Longer term, it may (no </div> <div dir="auto">guarantees) unlock some performance by getting the kernel out of the way.</div> </blockquote> <div dir="auto"><br></div> <div dir="auto">Oh, I definitely agree with firmware-based submission model not being a </div> <div dir="auto">bad design. I was even cheering for it in 2015. Experience with it made </div> <div dir="auto">me regret that deeply since :s</div> <div dir="auto"><br></div> <div dir="auto">But with the DRM scheduler being responsible for most things, I fail to </div> <div dir="auto">see what we could offload in the GuC except context switching (like </div> <div dir="auto">every other manufacturer). The problem is, the GuC does way more than </div> <div dir="auto">just switching registers in bulk, and if the number of revisions of the </div> <div dir="auto">GuC is anything to go by, it is way too complex for me to feel </div> <div dir="auto">comfortable with it.</div></blockquote></div><div dir="auto"><br></div><div dir="auto">It's more than just bulk register writes. When it comes to load-balancing multiple GPU users, firmware can theoretically preempt and switch faster leading to more efficient time-slicing. All we really need the DRM scheduler for is handling implicit dma_fence dependencies between different applications.</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><blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #0099CC; padding-left: 0.75ex;"> <blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #9933CC; 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 dir="auto"><br></div> <div dir="auto">I'd like to address this one specifically as it's become something of a </div> <div dir="auto">speciality of mine the past few weeks. The current bonded submission </div> <div dir="auto">model is bad. It provides a plethora of ways for a client to back itself </div> <div dir="auto">into a corner and doesn't actually provide the guarantees the media </div> <div dir="auto">driver needs for its real-time high-resolution decode. It's bad enough </div> <div dir="auto">we're seriously considering ripping it out, backwards compatibility or </div> <div dir="auto">not. The good news is that very little that your average desktop user </div> <div dir="auto">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 </div> <div dir="auto">forward. (We should have landed parallel submit the first time around.) </div> <div dir="auto">It isn't full of corners and does let us provides actual parallel </div> <div dir="auto">execution guarantees. It also gives the scheduler the information it </div> <div dir="auto">needs to reliably provide those guarantees. ></div> <div dir="auto">If we need to support the parallel submit API with the execlist </div> <div dir="auto">back-end, that's totally possible. The choice to only implement the </div> <div dir="auto">parallel submit API with GuC is a pragmatic one. We're trying to get </div> <div dir="auto">upstream back on it's feet and get all the various up-and-coming bits of </div> <div dir="auto">hardware enabled. Enabling the new API in the execlist back-end makes </div> <div dir="auto">that pipeline longer.</div> </blockquote> <div dir="auto"><br></div> <div dir="auto">I feel your pain, and wish you all the best to get GEM less complex</div> <div dir="auto">and more manageable.</div> <div dir="auto"><br></div> <div dir="auto">So, if I understood correctly, the plan is just to regress 4K+ video </div> <div dir="auto">decoding for people who do not enable GuC scheduling, or did not also </div> <div dir="auto">update to a recent-enough media driver that would support this new </div> <div dir="auto">interface? If it is indeed only for over 4K videos, then whatever. If it </div> <div dir="auto">is 4K, it starts being a little bad, assuming graceful fallback to </div> <div dir="auto">CPU-based decoding. What's the test plan for this patch then? The patch </div> <div dir="auto">in its current form is definitely not making me confident.</div></blockquote></div><div dir="auto"><br></div><div dir="auto">My understanding is that it's only >4k that's affected; we've got enough bandwidth on a single VCS for 4K. I'm not sure where the exact cut-off is (it may be a little higher than 4k) but real-time 4k should be fine and real-time 8k requires parallel submit. So we're really not cutting off many use-cases. Also, as I said above, the new API can be implemented with the execlist scheduler if needed. We've just pragmatically deprioritized it.</div><div dir="auto"><br></div><div dir="auto">--Jason</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><blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #0099CC; padding-left: 0.75ex;"> <blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #9933CC; padding-left: 0.75ex;"> <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 dir="auto"><br></div> <div dir="auto">The IGT changes, as I understand them, are entirely around switching to </div> <div dir="auto">the new parallel submit API. There shouldn't be a major effect to most </div> <div dir="auto">users.</div> </blockquote> <div dir="auto"><br></div> <div dir="auto">Right, this part I followed, but failed to connect it to the GuC... </div> <div dir="auto">because I couldn't see why it would be needed (execlist requiring a lot </div> <div dir="auto">more work).</div> <div dir="auto"><br></div> <div dir="auto">I sincerely wish for the GuC to stay away from upstream because of the </div> <div dir="auto">above concerns (which are yet to be addressed), but if Intel were to </div> <div dir="auto">push forward with the plan to drop execlist, I can foresee a world of </div> <div dir="auto">trouble for users... That is of course unless the GuC were to be open </div> <div dir="auto">sourced, with people outside of Intel able to sign their own builds or </div> <div dir="auto">run unsigned. Failing that, let's hope the last 6 years were just a bad </div> <div dir="auto">start, and the rapid climb in major version of the GuC will magically </div> <div dir="auto">stop! I hope execlists will remain at feature parity with the GuC when </div> <div dir="auto">possible... but deplore the increase in validation needs which will only </div> <div dir="auto">hurt users in the end.</div> <div dir="auto"><br></div> <div dir="auto">Thanks for your honest answer,</div> <div dir="auto">Martin</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">--Jason</div> </blockquote> </blockquote> </div><div dir="auto"><br></div> </div></body> </html>