On Tue, 18 May 2021 at 06:10, Thomas Zimmermann [off-list ref] wrote:

Hi

Am 17.05.21 um 21:32 schrieb Daniel Stone:

quoted

Hi,

On Mon, 17 May 2021 at 20:12, Thomas Zimmermann [off-list ref] wrote:

quoted

Am 17.05.21 um 09:40 schrieb Daniel Vetter:

quoted

We have, it's called drivers/gpu. Feel free to rename to drivers/xpu or
think G as in General, not Graphisc.

I hope this was a joke.

Just some thoughts:

AFAICT AI first came as an application of GPUs, but has now
evolved/specialized into something of its own. I can imagine sharing
some code among the various subsystems, say GEM/TTM internals for memory
management. Besides that there's probably little that can be shared in
the userspace interfaces. A GPU is device that puts an image onto the
screen and an AI accelerator isn't.

But it isn't. A GPU is a device that has a kernel-arbitrated MMU
hosting kernel-managed buffers, executes user-supplied compiled
programs with reference to those buffers and other jobs, and informs
the kernel about progress.

KMS lies under the same third-level directory, but even when GPU and
display are on the same die, they're totally different IP blocks
developed on different schedules which are just periodically glued
together.

I mentioned this elsewhere: it's not about the chip architecture, it's
about the UAPI. In the end, the GPU is about displaying things on a
screen. Even if the rendering and the scanout engines are on different
IP blocks. (Or different devices.)

The fact that one can do general purpose computing on a GPU is a
byproduct of the evolution of graphics hardware. It never was the goal.

But then we would have a subsystem for AI accelerators excluding GPUs,
do we then start to layer that subsystem onto drivers/gpu? at which
point why bother.

The thing is UAPI and stack architecture are important, but what is
more important than any of that is that there is a place where the
people invested in the area can come together outside of company
boundaries and discuss ideas and bounce designs around each other to
come to an agreement without the overheads of company interactions.
dri-devel + mesa have managed this for graphics but it's taken years
and we are still fighting that battle within major companies who even
when they know it produces good results can't drag themselves to give
up control over anything unless given no other choice.

I expect the accel teams in these companies need to step outside their
productization timelines and powerpoints and start discussing uAPI
designs with the other companies in the area. Until that happens I
expect upstreaming any of these should be a default no.

Dave.