Date:   Mon, 17 Apr 2017 11:22:08 -0500
From:   Alan Tull <atull@...nel.org>
To:     Jerome Glisse <jglisse@...hat.com>
Cc:     "Luebbers, Enno" <enno.luebbers@...el.com>,
        Moritz Fischer <moritz.fischer@...us.com>,
        Wu Hao <hao.wu@...el.com>, linux-fpga@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "Kang, Luwei" <luwei.kang@...el.com>,
        "Zhang, Yi Z" <yi.z.zhang@...el.com>
Subject: Re: [PATCH 00/16] Intel FPGA Device Drivers

On Mon, Apr 17, 2017 at 10:57 AM, Jerome Glisse <jglisse@...hat.com> 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@...hat.com> 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@...hat.com> 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.

>
>
>> 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.

>
> Beside when it comes to FPGA i am still puzzle on why no one release info
> on the bitstream. They all provide details documentation on the internal
> (LUT, flip-flop, logic block layout and connection, memory block, ...).
> So there is nothing hidden in the bitstream. I am guessing the only good
> reason i can think of is to make it harder to map a bitstream back to
> VHDL/Verilog/...
>
> Cheers,
> Jérôme

Powered by blists - more mailing lists