On 01/24/2018 12:03 AM, Karol Herbst wrote:
On Tue, Jan 23, 2018 at 11:46 PM, Francisco Jerez <curroje...@riseup.net> wrote:
Pierre Moreau <pierre.mor...@free.fr> writes:
On 2018-01-23 — 14:02, Francisco Jerez wrote:
Karol Herbst <kher...@redhat.com> writes:
there seem to be some patches missing?
On Tue, Jan 23, 2018 at 1:33 AM, Pierre Moreau <pierre.mor...@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.
Besides Mesa, there's interest from compiler writers such as D and Volt.
Regards,
Tomeu
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
