On Tue, 18 May 2021 at 06:10, Thomas Zimmermann <tzimmermann@xxxxxxx> wrote: > > Hi > > Am 17.05.21 um 21:32 schrieb Daniel Stone: > > Hi, > > > > On Mon, 17 May 2021 at 20:12, Thomas Zimmermann <tzimmermann@xxxxxxx> wrote: > >> Am 17.05.21 um 09:40 schrieb Daniel Vetter: > >>> 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.
