On 07/31/2017 02:30 PM, Nicholas Wilson via llvm-dev wrote:> >> On 31 Jul 2017, at 3:23 pm, Neil Henning <ll... at duskborn.com> wrote: > > Moving forward, other than securing the triples spirv32, spirv64, and spirvlogical from LLVM, how can we go about coordinating efforts? I feel that having one backend is a better use of everybody’s time than having three. If we don't get around to anything I’m sure we can organise something at IWOCL.Hi there, any news on coordination? We have customers who are successfully using Mesa in their products, and that are now asking about OpenCL. My current impression is that easiest would be to do what Tom suggested before, and only re-evaluate inclusion in LLVM proper once things are more mature. One path for me would be to take Khronos' or Nic's work and convert it into something that can be packaged by Linux distributions (so it needs to work with the latest LLVM release, with no patches). Another path would be to extend clspv to cover the whole of OpenCL, but I don't know if Codeplay/Google are interested in taking such patches. Is here interest in coordinating efforts? Regards, Tomeu
On 09/27/2017 05:21 AM, Tomeu Vizoso wrote:> On 07/31/2017 02:30 PM, Nicholas Wilson via llvm-dev wrote: >> >>> On 31 Jul 2017, at 3:23 pm, Neil Henning <ll... at duskborn.com> wrote: >> >> Moving forward, other than securing the triples spirv32, spirv64, and spirvlogical from LLVM, how can we go about coordinating efforts? I feel that having one backend is a better use of everybody’s time than having three. If we don't get around to anything I’m sure we can organise something at IWOCL. > > Hi there, > > any news on coordination? We have customers who are successfully using > Mesa in their products, and that are now asking about OpenCL. >What hardware are they using? Note that SPIR-V is not required to run mesa's OpenCL on AMD hardware.> My current impression is that easiest would be to do what Tom suggested > before, and only re-evaluate inclusion in LLVM proper once things are > more mature. > > One path for me would be to take Khronos' or Nic's work and convert it > into something that can be packaged by Linux distributions (so it needs > to work with the latest LLVM release, with no patches). > > Another path would be to extend clspv to cover the whole of OpenCL, but > I don't know if Codeplay/Google are interested in taking such patches. > > Is here interest in coordinating efforts? >I recommend using clspv, in addition to having a clang-based driver for compiling OpenCL C, it exposes the LLVM IR -> SPIR-V passes via a header, so it should be easy to integrate it into existing compilation pipelines. It also is easy to package as it is already a stand-alone project. -Tom> Regards, > > Tomeu >
On 27 September 2017 at 18:25, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> wrote:> On 09/27/2017 05:21 AM, Tomeu Vizoso wrote: >> On 07/31/2017 02:30 PM, Nicholas Wilson via llvm-dev wrote: >>> >>>> On 31 Jul 2017, at 3:23 pm, Neil Henning <ll... at duskborn.com> wrote: >>> >>> Moving forward, other than securing the triples spirv32, spirv64, and spirvlogical from LLVM, how can we go about coordinating efforts? I feel that having one backend is a better use of everybody’s time than having three. If we don't get around to anything I’m sure we can organise something at IWOCL. >> >> Hi there, >> >> any news on coordination? We have customers who are successfully using >> Mesa in their products, and that are now asking about OpenCL. >> > > What hardware are they using? Note that SPIR-V is not required to run > mesa's OpenCL on AMD hardware.We have seen most direct interest on Adreno.>> My current impression is that easiest would be to do what Tom suggested >> before, and only re-evaluate inclusion in LLVM proper once things are >> more mature. >> >> One path for me would be to take Khronos' or Nic's work and convert it >> into something that can be packaged by Linux distributions (so it needs >> to work with the latest LLVM release, with no patches). >> >> Another path would be to extend clspv to cover the whole of OpenCL, but >> I don't know if Codeplay/Google are interested in taking such patches. >> >> Is here interest in coordinating efforts? >> > > I recommend using clspv, in addition to having a clang-based driver > for compiling OpenCL C, it exposes the LLVM IR -> SPIR-V passes via > a header, so it should be easy to integrate it into existing > compilation pipelines. > > It also is easy to package as it is already a stand-alone project.Noted, thanks for the recommendation. Regards, Tomeu
> On 27 Sep 2017, at 8:21 pm, Tomeu Vizoso <tomeu.vizoso at collabora.com> wrote: > > Hi there, > > any news on coordination? We have customers who are successfully using > Mesa in their products, and that are now asking about OpenCL.None yet, I’m still waiting for IWOCL to spearhead the coordination.> My current impression is that easiest would be to do what Tom suggested > before, and only re-evaluate inclusion in LLVM proper once things are > more mature. > > One path for me would be to take Khronos' or Nic's work and convert it > into something that can be packaged by Linux distributions (so it needs > to work with the latest LLVM release, with no patches).Mine works with LLVM trunk at the moment. I think all it would take would be to roll back the fixes to make and add it to the build system to make it work with 5.0. The code generator is a regular (well for the purposes of a front end developer) backend so should be very easy to integrate. It does lack an OpenCL C front end though, you would need to forward port Khronos’ one.> Another path would be to extend clspv to cover the whole of OpenCL, but > I don't know if Codeplay/Google are interested in taking such patches. > > Is here interest in coordinating efforts? > > Regards, > > TomeuDefinitely although I’m a bit busy at the moment. I hope you can make it to IWOCL. Nic
On 28 September 2017 at 00:52, Nicholas Wilson via llvm-dev <llvm-dev at lists.llvm.org> wrote:> >> On 27 Sep 2017, at 8:21 pm, Tomeu Vizoso <tomeu.vizoso at collabora.com> wrote: >> >> Hi there, >> >> any news on coordination? We have customers who are successfully using >> Mesa in their products, and that are now asking about OpenCL. > > None yet, I’m still waiting for IWOCL to spearhead the coordination. > >> My current impression is that easiest would be to do what Tom suggested >> before, and only re-evaluate inclusion in LLVM proper once things are >> more mature. >> >> One path for me would be to take Khronos' or Nic's work and convert it >> into something that can be packaged by Linux distributions (so it needs >> to work with the latest LLVM release, with no patches). > > Mine works with LLVM trunk at the moment. > I think all it would take would be to roll back the fixes to make and add it to the build system to make it work with 5.0. > The code generator is a regular (well for the purposes of a front end developer) backend so should be very easy to integrate. It does lack an OpenCL C front end though, you would need to forward port Khronos’ one.Finally took some time to find out how hard would be to put Khronos' LLVM-SPIRV into a shape that could be used by Mesa, and it didn't turn that bad: https://gitlab.collabora.com/tomeu/llvm-spirv I basically took Khronos' master branch, rewrote history to remove anything not SPIRV-specific, and applied on top Nic's changes to match LLVM 6.0. Also borrowed some build system changes from clspv.>> Another path would be to extend clspv to cover the whole of OpenCL, but >> I don't know if Codeplay/Google are interested in taking such patches.Doesn't look like that would be the case: https://github.com/google/clspv/issues/63>> Is here interest in coordinating efforts? >> >> Regards, >> >> Tomeu > > Definitely although I’m a bit busy at the moment. I hope you can make it to IWOCL.Will look at being there. For the moment I'm going to count on using this fork as a starting point so I can start my work on Mesa/Clover/Freedreno. Everybody else is welcome to contribute changes towards making it suitable for inclusion in LLVM, but I need it to not regress in the meantime. Regards, Tomeu