<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 12, 2023 at 11:17 AM Matthew Brost <<a href="mailto:matthew.brost@intel.com">matthew.brost@intel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Jan 12, 2023 at 10:54:25AM +0100, Lucas De Marchi wrote:<br>
> On Thu, Jan 05, 2023 at 09:27:57PM +0000, Matthew Brost wrote:<br>
> > On Tue, Jan 03, 2023 at 12:21:08PM +0000, Tvrtko Ursulin wrote:<br>
> > > <br>
> > > On 22/12/2022 22:21, Matthew Brost wrote:<br>
> > > > Hello,<br>
> > > ><br>
> > > > This is a submission for Xe, a new driver for Intel GPUs that supports both<br>
> > > > integrated and discrete platforms starting with Tiger Lake (first platform with<br>
> > > > Intel Xe Architecture). The intention of this new driver is to have a fresh base<br>
> > > > to work from that is unencumbered by older platforms, whilst also taking the<br>
> > > > opportunity to rearchitect our driver to increase sharing across the drm<br>
> > > > subsystem, both leveraging and allowing us to contribute more towards other<br>
> > > > shared components like TTM and drm/scheduler. The memory model is based on VM<br>
> > > > bind which is similar to the i915 implementation. Likewise the execbuf<br>
> > > > implementation for Xe is very similar to execbuf3 in the i915 [1].<br>
> > > ><br>
> > > > The code is at a stage where it is already functional and has experimental<br>
> > > > support for multiple platforms starting from Tiger Lake, with initial support<br>
> > > > implemented in Mesa (for Iris and Anv, our OpenGL and Vulkan drivers), as well<br>
> > > > as in NEO (for OpenCL and Level0). A Mesa MR has been posted [2] and NEO<br>
> > > > implementation will be released publicly early next year. We also have a suite<br>
> > > > of IGTs for XE that will appear on the IGT list shortly.<br>
> > > ><br>
> > > > It has been built with the assumption of supporting multiple architectures from<br>
> > > > the get-go, right now with tests running both on X86 and ARM hosts. And we<br>
> > > > intend to continue working on it and improving on it as part of the kernel<br>
> > > > community upstream.<br>
> > > ><br>
> > > > The new Xe driver leverages a lot from i915 and work on i915 continues as we<br>
> > > > ready Xe for production throughout 2023.<br>
> > > ><br>
> > > > As for display, the intent is to share the display code with the i915 driver so<br>
> > > > that there is maximum reuse there. Currently this is being done by compiling the<br>
> > > > display code twice, but alternatives to that are under consideration and we want<br>
> > > > to have more discussion on what the best final solution will look like over the<br>
> > > > next few months. Right now, work is ongoing in refactoring the display codebase<br>
> > > > to remove as much as possible any unnecessary dependencies on i915 specific data<br>
> > > > structures there..<br>
> > > ><br>
> > > > We currently have 2 submission backends, execlists and GuC. The execlist is<br>
> > > > meant mostly for testing and is not fully functional while GuC backend is fully<br>
> > > > functional. As with the i915 and GuC submission, in Xe the GuC firmware is<br>
> > > > required and should be placed in /lib/firmware/xe.<br>
> > > <br>
> > > What is the plan going forward for the execlists backend? I think it would<br>
> > > be preferable to not upstream something semi-functional and so to carry<br>
> > > technical debt in the brand new code base, from the very start. If it is for<br>
> > > Tigerlake, which is the starting platform for Xe, could it be made GuC only<br>
> > > Tigerlake for instance?<br>
> > > <br>
> > <br>
> > A little background here. In the original PoC written by Jason and Dave,<br>
> > the execlist backend was the only one present and it was in semi-working<br>
> > state. As soon as myself and a few others started working on Xe we went<br>
> > full in a on the GuC backend. We left the execlist backend basically in<br>
> > the state it was in. We left it in place for 2 reasons.<br>
> > <br>
> > 1. Having 2 backends from the start ensured we layered our code<br>
> > correctly. The layer was a complete disaster in the i915 so we really<br>
> > wanted to avoid that.<br>
> > 2. The thought was it might be needed for early product bring up one<br>
> > day.<br>
> > <br>
> > As I think about this a bit more, we likely just delete execlist backend<br>
> > before merging this upstream and perhaps just carry 1 large patch<br>
> > internally with this implementation that we can use as needed. Final<br>
> > decession TDB though.<br>
> <br>
> but that might regress after some time on "let's keep 2 backends so we<br>
> layer the code correctly". Leaving the additional backend behind<br>
> CONFIG_BROKEN or XE_EXPERIMENTAL, or something like that, not<br>
> enabled by distros, but enabled in CI would be a good idea IMO.<br>
> <br>
> Carrying a large patch out of tree would make things harder for new<br>
> platforms. A perfect backend split would make it possible, but like I<br>
> said, we are likely not to have it if we delete the second backend.<br>
> <br>
<br>
Good points here Lucas. One thing that we absolutely have wrong is<br>
falling back to execlists if GuC firmware is missing. We def should not<br>
be doing that as it creates confusion.<br></blockquote><div><br></div><div>Yeah, we certainly shouldn't be falling back on it silently. That's a recipe for disaster. If it stays, it should be behind a config option that's clearly labeled as broken or not intended for production use. If someone is a zero-firmware purist and wants to enable it and accept the brokenness, that's their choice.</div><div><br></div><div>I'm not especially attached to the execlist back-end so I'm not going to insist on anything here RE keeping it.</div><div><br></div><div>There is more to me starting with execlists than avoiding GuC, though. One of the reasons I did it was to prove that the same core Xe scheduling model [3] doesn't depend on firmware. As long as your hardware has some ability to juggle independent per-context rings, you can get the same separation and it makes everything cleaner. If this is the direction things are headed (and I really think it is; I need to blog about it), being able to do the Xe model on more primitive hardware which lacks competent firmware-based submission is important. I wanted to prototype that to show that it could be done.</div><div><br></div><div>I also kinda wanted to prove that execlists didn't have to be horrible like in i915. You know, for funzies....</div><div><br></div><div>--Jason</div><div><br></div><div>[3]: <a href="https://lists.freedesktop.org/archives/dri-devel/2023-January/386381.html">https://lists.freedesktop.org/archives/dri-devel/2023-January/386381.html</a></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I kinda like the idea hiding it behind a config option + module<br>
parameter to use the backend so you really, really need to try to be<br>
able to use it + with this in the code it make us disciplined in our<br>
layering. At some point we will likely another supported backend and at<br>
that point we may decide to delete this backend.<br>
<br>
Matt<br>
<br>
> Lucas De Marchi<br>
> <br>
> > <br>
> > Matt<br>
> > <br>
> > > Regards,<br>
> > > <br>
> > > Tvrtko<br>
</blockquote></div></div>