[Mesa-dev] [PATCH v2 00/22] Introducing SPIR-V support to clover

[Tomeu Vizoso]

On 24 January 2018 at 08:19, Tomeu Vizoso <tomeu.vizoso at collabora.com> wrote:
> On 01/24/2018 12:03 AM, Karol Herbst wrote:
>>
>> On Tue, Jan 23, 2018 at 11:46 PM, Francisco Jerez <currojerez at riseup.net>
>> wrote:
>>>
>>> Pierre Moreau <pierre.morrow at free.fr> writes:
>>>
>>>> On 2018-01-23 — 14:02, Francisco Jerez wrote:
>>>>>
>>>>> Karol Herbst <kherbst at redhat.com> writes:
>>>>>
>>>>>> there seem to be some patches missing?
>>>>>>
>>>>>> On Tue, Jan 23, 2018 at 1:33 AM, Pierre Moreau <pierre.morrow at free.fr>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> * Before, when linking different modules together, you knew that all
>>>>>>> modules
>>>>>>>    would use the same IR, as all were created using
>>>>>>> clCreateProgramWithSource,
>>>>>>>    therefore the linker could just call the linking function
>>>>>>> corresponding to
>>>>>>>    the target’s preferred IR. But with the introduction of
>>>>>>>    clCreateProgramWithIL(KHR)?, we can now end up in a case where we
>>>>>>> try to link
>>>>>>>    a module using NIR as IR (created through
>>>>>>> clCreateProgramWithSource, assuming
>>>>>>>    that is the driver’s preferred IR), with another module using
>>>>>>> SPIR-V as IR
>>>>>>>    (created through clCreateProgramWithIL). How do we handle such a
>>>>>>> case: should
>>>>>>>    we translate the SPIR-V to NIR and use a NIR linker on them, or
>>>>>>> convert NIR
>>>>>>>    to SPIR-V and use the SPIR-V linker? NIR and LLVM IR can be
>>>>>>> handled
>>>>>>>    relatively easily, but what about TGSI?
>>>>>>>
>>>>>>
>>>>>> I think we will never be able to convert all IRs into any other IR, so
>>>>>> that I would suggest to leave those IRs unconverted until they get
>>>>>> linked together and there the code can decide on a common IR for
>>>>>> linking. So if we get source code, we can parse it to llvm IR and
>>>>>> leave it like that until it gets linked. Converting back and forth
>>>>>> would require us to write all those conversion paths and I am assume
>>>>>> this wouldn't be worth the trouble.
>>>>>>
>>>>>
>>>>> I think it would be more straightforward to compile source programs
>>>>> into
>>>>> SPIRV if the driver supports it (or if it supports any other IR that
>>>>> could possibly be translated from SPIRV after link time, e.g. NIR or
>>>>> maybe even TGSI).  That means that there is a single canonical IR for
>>>>> each CL device and we don't need to deal with linking different
>>>>> combinations of IRs together.  If the driver doesn't support SPIRV nor
>>>>> any of the IRs derived from it, it better support LLVM IR instead, so
>>>>> we
>>>>> can just use that as canonical IR within the state tracker, and
>>>>> possibly
>>>>> accept the same representation as input to clCreateProgramWithIL()
>>>>> instead of SPIRV.
>>>>
>>>>
>>>> “On top of” SPIR-V, not “instead of”, as SPIR-V is the only IL which is
>>>> mandatory to support, according to the specification.
>>>
>>>
>>> That's right, but it just means that devices that have LLVM as canonical
>>> IR don't get support for cl_khr_il_program for the time being, until
>>> Khronos' SPIRV-to-LLVM converter gets upstreamed.
>>>
>>
>> we could use tomeus out of tree llvm-spirv module though, but this
>> would also need some maintenance. It would be a better solution than
>> using that llvm-spirv fork from khronos
>
>
> Though I still cannot commit at the moment to maintain it, there's so many
> people whose plans could benefit from it, that maybe it won't be such a
> problem to maintain such a "packagable" fork until it gets merged in LLVM
> proper.

Hi,

there's a renewed push within Khronos to upstream the LLVM-SPIRV
converter to LLVM proper.

The plan is to ask for inclusion in the tools/ subdirectory in pretty
much its current form.

I'll be keeping an eye on it and will try to get an idea of when we
should expect it to land in LLVM.

Regards,

Tomeu