On Thu, Jan 05, 2023 at 09:27:57PM +0000, Matthew Brost wrote:
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.
but that might regress after some time on "let's keep 2 backends so we
layer the code correctly". Leaving the additional backend behind
CONFIG_BROKEN or XE_EXPERIMENTAL, or something like that, not
enabled by distros, but enabled in CI would be a good idea IMO.
Carrying a large patch out of tree would make things harder for new
platforms. A perfect backend split would make it possible, but like I
said, we are likely not to have it if we delete the second backend.
Lucas De Marchi
Matt
Regards,
Tvrtko
