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
