Re: [MAINTAINER SUMMIT] User-space requirements for accelerator drivers

[Dave Airlie <airlied@gmail.com>]

On Mon, 13 Sept 2021 at 05:48, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> Hi Dave,
>
> On Mon, Sep 13, 2021 at 05:13:05AM +1000, Dave Airlie wrote:
> > On Sat, 11 Sept 2021 at 07:10, Jonathan Corbet <corbet@lwn.net> wrote:
> > >
> > > There has been a regular disagreement in recent years about whether
> > > drivers for accelerators (such as for the Habana Gaudi device) should be
> > > subject to the same requirements as GPU drivers when it comes to the
> > > availability of a free implementation of the user-space side.  It flared
> > > up again recently:
> > >
> > >    https://lwn.net/Articles/867168/
> > >
> > > Happily, the Habana situation in particular seems to be resolving
> > > itself:
> > >
> > >    https://lwn.net/ml/linux-kernel/CAFCwf119s7iXk+qpwoVPnRtOGcxeuZb3rnihf6NWWoVT-4ODHA@mail.gmail.com/
> > >
> > > But even there it is clear that the fundamental question has not yet
> > > been resolved.
> > >
> > > This seems like the sort of question that the maintainer summit exists
> > > to address.  Specifically, we could discuss:
> > >
> > >  - Under which circumstances should the kernel community require the
> > >    existence of freely licensed user-space code that exercises all
> > >    functionalities of a proposed kernel driver or feature?
> > >
> > >  - Are there internal kernel interfaces, such as DMA-BUF or P2PDMA, that
> > >    are only available to drivers with a free user-space implementation?
> > >    Do we need an EXPORT_SYMBOL_USERSPACE_GPL()?
> > >
> > >  - What constitutes an acceptable user-space implementation in cases
> > >    where these restrictions apply?
> > >
> > > I suspect that more clarity (and fewer arguments) on these questions
> > > would be welcome both within and beyond the development community.
> > >
> > > Thanks,
> >
> > Can everyone take a read of:
> >
> > https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
> >
> > I think in order to clean the signal/noise ratio up in here, some
> > education effort might help people realise how non-trivial these
> > things are.
> >
> > 1. These drivers are not one or two ioctls that a few selftests and a
> > small test app can cover. It's like saying LTP is all we need to
> > define the uAPI for the kernel and if anyone does something LTP
> > doesn't cover the app is broken. These systems are generally complex,
> > multithreaded and multiuser uAPIs, involving command streams recorded
> > in userspace being submitted to the devices. They interact with memory
> > management and can cause unfindable deadlocks across the system if
> > designed incorrectly. Documentation or kselftests aren't going to cut
> > it here.
> >
> > 2. In my experience we don't build communities by merging everything,
> > we build them by saying No more and pushing back on companies with
> > education and cross-vendor cooperation. Responsible kernel maintenance
> > shouldn't end at the kernel boundaries. If you aren't the person to
> > help enforce a userspace for a driver you are being asked to merge,
> > then don't merge it, but try and engage the vendor with the
> > communities of interest in the kernel who already deal in those areas.
> >
> > 3. The pressures on these companies to merge things into Linux isn't
> > altruistic or even that they necessarily want to be in the Linux
> > kernel upstream. They are being told by Red Hat, Facebook, Google or
> > someone else that they need an upstream driver. They will generally
> > engage at a minimal level to get past that blockage and then
> > disengage. Having a clear set of rules (or a place to discuss those
> > rules, for new subsystems) and a gentle pushback helps develop
> > communities by unlocking funding within those larger areas. As Laurent
> > has said this isn't free, but just putting things into the kernel and
> > not caring about userspace hasn't built any Linux communities in the
> > accelerator areas.
> >
> > That said I started writing a cleaned up version of the above document
> > which is more generic that other subsystems could sign on to. I was
> > going to engage with a coalition of like-minded maintainers rather
> > than trying to gain consensus among a herd of cats to see if we can
> > draw clearer lines in the sand that cross more subsystems so the
> > experience of drivers/gpu doesn't go unwasted but also isn't just
> > bypassed by subsystem hunting.
> >
> > https://cgit.freedesktop.org/~airlied/linux/log/?h=wip-open-source-userspace
>
> Thank you for that effort. Could you add camera ISPs to the list with
> FPGAs, DSPs and ML accelerators ?

I'll add that to the next iteration, thanks.

>
> You mention Level0 in that document. I assume you don't mean the
> OpenStreetMap editor ?

https://spec.oneapi.io/level-zero/latest/core/INTRO.html

It's like a vulkan for OpenCL effort, they've already managed to put
things in the API that are close to impossible to make work on the
Linux kernel properly, again because Intel internally thought they had
better experts than the kernel, but we are trying to get that all
fixed up.

Dave.