[RFC PATCH 0/3] new subsystem for compute accelerator devices

[John Hubbard]

On 10/24/22 05:43, Oded Gabbay wrote:

Hi Oded,

The patches make sense to me. I'm still just reading through and looking
for minor issues, but at a high level it seems to match what the LPC
discussions pointed to.

>> What's your opinion on the long-term prospect of DRM vs accel? I assume
>> that over time, DRM helpers will move into accel and some DRM drivers
>> will start depending on accel?
> I don't think that is what I had in mind.
> What I had in mind is that accel helpers are only relevant for accel
> drivers, and any code that might also be relevant for DRM drivers will
> be placed in DRM core code. e.g. GEM enhancements, RAS netlink

Yes. That is how I understood it ("it" being both the LPC discussions,
and this patchset) as well:

     * accel-only code goes in drivers/accel, thus allowing for
       smaller, simpler drivers (as compared to full drm) for that case.

     * graphics and display code still goes in drivers/gpu/drm, because
       it is much too hard to rename or move that directory.

     * code common to both also goes in drivers/gpu/drm.

Looking ahead a bit more:

For full-featured GPUs that do both Graphics and Compute, I expect
that a *lot* of the code will end up in drivers/gpu/drm. Because so
much of setting up for Compute is also really just setting up for
Graphics--that's how it evolved, after all!

And as things are structured now, it looks like those full featured
GPU stacks will also need an aux bus (which I only just now learned
about, but it looks quite helpful here). And also, user space will
need to open both /dev/dri/* and /dev/accel/* nodes, if it needs
access to anything live objects that drivers/accel owns.


thanks,
-- 
John Hubbard
NVIDIA