linux-kernel - Re: [RFC PATCH 0/3] new subsystem for compute accelerator devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c22bd93e-8bd2-6865-711a-37aeadbca7f9@nvidia.com>
Date:   Mon, 24 Oct 2022 19:21:52 -0700
From:   John Hubbard <jhubbard@...dia.com>
To:     Oded Gabbay <ogabbay@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>
CC:     David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>,
        "Arnd Bergmann" <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        <linux-kernel@...r.kernel.org>, <dri-devel@...ts.freedesktop.org>,
        "Jason Gunthorpe" <jgg@...dia.com>,
        Alex Deucher <alexander.deucher@....com>,
        "Maarten Lankhorst" <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Yuji Ishikawa <yuji2.ishikawa@...hiba.co.jp>,
        Jiho Chu <jiho.chu@...sung.com>,
        Daniel Stone <daniel@...ishbar.org>,
        Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com>,
        Jeffrey Hugo <quic_jhugo@...cinc.com>,
        Christoph Hellwig <hch@...radead.org>,
        Kevin Hilman <khilman@...libre.com>,
        Jagan Teki <jagan@...rulasolutions.com>,
        Jacek Lawrynowicz <jacek.lawrynowicz@...ux.intel.com>,
        Maciej Kwapulinski <maciej.kwapulinski@...ux.intel.com>
Subject: Re: [RFC PATCH 0/3] new subsystem for compute accelerator devices

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