Re: [PATCH 00/16] Intel FPGA Device Drivers

[Jerome Glisse]

On Mon, Apr 17, 2017 at 11:22:08AM -0500, Alan Tull wrote:
> On Mon, Apr 17, 2017 at 10:57 AM, Jerome Glisse <jglisse@xxxxxxxxxx> wrote:
> > On Mon, Apr 17, 2017 at 10:35:01AM -0500, Alan Tull wrote:
> >> On Fri, Apr 14, 2017 at 3:49 PM, Jerome Glisse <jglisse@xxxxxxxxxx> wrote:
> >>
> >> Hi Jerome,
> >>
> >> > On Fri, Apr 14, 2017 at 12:48:17PM -0700, Luebbers, Enno wrote:
> >> >> On Wed, Apr 12, 2017 at 11:37:49AM -0400, Jerome Glisse wrote:
> >> >> > On Wed, Apr 12, 2017 at 07:46:19AM -0700, Moritz Fischer wrote:
> >> >> > > On Wed, Apr 12, 2017 at 6:29 AM, Jerome Glisse <jglisse@xxxxxxxxxx> wrote:
> >> >> > >
> >> >> > > > It is like if on GPU we only had close source compiler for the GPU
> >> >> > > > instructions set. So FPGA is definitly following different rules than
> >> >> > > > open source upstream GPU kernel driver abides to.
> >>
> >> Sorry, not a GPU guy, can you point me to something that documents
> >> this policy of 'only opensource compilers for GPU'?  I looked under
> >> linux/Documentation and didn't see anything.
> >
> > https://lists.freedesktop.org/archives/dri-devel/2010-July/001828.html
> 
> This starts out saying:
> 
> "Now this is just my opinion as maintainer of the drm, and doesn't
> reflect anyone or any official policy"
> 
> > There is no explicit mention about compiler
> 
> You are right about that, there is no mention about compiler.
> 
> > but trust me it is included
> > in everyones mind. You can ask Dave i am sure he would reject a driver
> > with everything open except the shader compiler.
> 
> How would that work?  Before the GPU driver is accepted, an open
> toolchain also needs to be submitted?
> 
> It's worth it to check out the responses since they not overwhelmingly
> positive and tend to rather be outlining the complicating factors.
> Many if not most say essentially that his stance was simplistic and
> unproductive, slamming the door on the people from whom the solution
> would come.  And keep in mind, this wasn't about what you've made it
> out to be in the first place; this is about open/closed source GPU
> drivers, not toolchains.

You are mixing thing. I say no driver without open source userspace.
For GPU this means something like a mesa driver and mesa driver include
a compiler but not in the form you expect (it is does not provide what
i would call a toolchain). But it can be something else. It could be
a standalone opencl implementation with what we call a finalizer (ie
something that goes from some intermediate representation down to the
hardare ISA).

So if you go look back at new driver submission like Adreno or Vivante.
They provided link to the open source driver they submited to mesa along
their kernel patchset posting.

For FPGA this would mean a tool that can map something like VHDL,Verilog
or even something lower level like a list of lut equation with a netlist
between them (and flip-flop and other blocks). So mapping this down to
the bitstream. It is call a toolchain for FPGA so that's the word i did
use.

> >> The current patchset doesn't have anything to do with FPGA toolchains
> >> but you're using this patchset as a platform to talk about toolchain
> >> issues.
> >
> > Well Intel inclusion of FPGA triggered my curiosity and when that patchset
> > came accross my inbox i did wonder where the open source userspace was and
> > went looking for it to no avail. So this isn't against a specific patchset
> > but more broadly against the whole drivers/fpga/ story. Sorry if this was
> > not clear.
> >
> >
> >> It sounds like you are opposed to any kernel support of loading images
> >> on FPGAs until all vendors have opensource toolchains.
> >
> > Yes that is what i am saying. They are different standard in the kernel
> > and i would rather have one clear standard about driver needing proper
> > open source userspace to go along with any upstream driver.
> 
> Deleting drivers/fpga wouldn't be a step forward to the openness you seek.

I am not saying let delete this. Ok it is there, i dislike that fact, but
it is there. I am asking: is this allowed for FPGA ? If so why ? Do everyone
understand the risks of accepting this ? ...

Now if community believe that we should only accept kernel code with open
source userspace bits then community can say no more changes to drivers/fpga
until you have said open source bits. That would send a clear signal.

Silently accepting drivers/fpga/ with no clear rules leave everyone in the
dark. People that wish to see only driver with open source userspace knows
that company will be happy to stay in this status quo and won't do anything
toward open source. Thinking differently would be utterly naive. A company
will not do something unless there is a clear incentive to do so.

Cheers,
Jérôme