On Tue, Jan 03, 2023 at 12:21:08PM +0000, Tvrtko Ursulin wrote: > > On 22/12/2022 22:21, Matthew Brost wrote: > > Hello, > > > > This is a submission for Xe, a new driver for Intel GPUs that supports both > > integrated and discrete platforms starting with Tiger Lake (first platform > > with > > Intel Xe Architecture). The intention of this new driver is to have a fresh > > base > > to work from that is unencumbered by older platforms, whilst also taking the > > opportunity to rearchitect our driver to increase sharing across the drm > > subsystem, both leveraging and allowing us to contribute more towards other > > shared components like TTM and drm/scheduler. The memory model is based on > > VM > > bind which is similar to the i915 implementation. Likewise the execbuf > > implementation for Xe is very similar to execbuf3 in the i915 [1]. > > > > The code is at a stage where it is already functional and has experimental > > support for multiple platforms starting from Tiger Lake, with initial > > support > > implemented in Mesa (for Iris and Anv, our OpenGL and Vulkan drivers), as > > well > > as in NEO (for OpenCL and Level0). A Mesa MR has been posted [2] and NEO > > implementation will be released publicly early next year. We also have a > > suite > > of IGTs for XE that will appear on the IGT list shortly. > > > > It has been built with the assumption of supporting multiple architectures > > from > > the get-go, right now with tests running both on X86 and ARM hosts. And we > > intend to continue working on it and improving on it as part of the kernel > > community upstream. > > > > The new Xe driver leverages a lot from i915 and work on i915 continues as we > > ready Xe for production throughout 2023. > > > > As for display, the intent is to share the display code with the i915 > > driver so > > that there is maximum reuse there. Currently this is being done by > > compiling the > > display code twice, but alternatives to that are under consideration and we > > want > > to have more discussion on what the best final solution will look like over > > the > > next few months. Right now, work is ongoing in refactoring the display > > codebase > > to remove as much as possible any unnecessary dependencies on i915 specific > > data > > structures there.. > > > > We currently have 2 submission backends, execlists and GuC. The execlist is > > meant mostly for testing and is not fully functional while GuC backend is > > fully > > functional. As with the i915 and GuC submission, in Xe the GuC firmware is > > required and should be placed in /lib/firmware/xe. > > What is the plan going forward for the execlists backend? I think it would > be preferable to not upstream something semi-functional and so to carry > technical debt in the brand new code base, from the very start. If it is for > Tigerlake, which is the starting platform for Xe, could it be made GuC only > Tigerlake for instance? >
A little background here. In the original PoC written by Jason and Dave, the execlist backend was the only one present and it was in semi-working state. As soon as myself and a few others started working on Xe we went full in a on the GuC backend. We left the execlist backend basically in the state it was in. We left it in place for 2 reasons. 1. Having 2 backends from the start ensured we layered our code correctly. The layer was a complete disaster in the i915 so we really wanted to avoid that. 2. The thought was it might be needed for early product bring up one day. As I think about this a bit more, we likely just delete execlist backend before merging this upstream and perhaps just carry 1 large patch internally with this implementation that we can use as needed. Final decession TDB though. Matt > Regards, > > Tvrtko
