[llvm-dev] [SPIR-V] SPIR-V in LLVM

Tomeu Vizoso via llvm-dev llvm-dev at lists.llvm.org
Wed Sep 27 12:05:45 PDT 2017


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


More information about the llvm-dev mailing list