[Mesa-dev] [PATCH 11/11] r600/radeonsi/clover: always assume PIPE_SHADER_IR_NATIVE for clover

[Pierre Moreau]

On 2018-02-08 — 12:47, Francisco Jerez wrote:
> Pierre Moreau <pierre.morrow at free.fr> writes:
> 
> > On 2018-02-07 — 12:36, Francisco Jerez wrote:
> >> Pierre Moreau <pierre.morrow at free.fr> writes:
> >> 
> >> > On 2018-02-06 — 20:50, Jan Vesely wrote:
> >> > [snip]
> >> >> > > Happy to here suggestions for solving the current conflict in uses of
> >> >> > > PIPE_SHADER_CAP_PREFERRED_IR.
> >> >> > 
> >> >> > One option could be to:
> >> >> > * look at the preferred IR
> >> >> >   |-> if clover supports it, use it
> >> >> >   |-> else, check if any IR supported by clover are supported by the driver,
> >> >> >       and pick the first one that works
> >> >> > 
> >> >> > Also, clover will be switching (experimentally first) to using SPIR-V as the
> >> >> > canonical IR, for all the compiling and linking internally, before translating
> >> >> > the resulting executable to a representation the driver can handle.
> >> >> 
> >> >> Why? what is this good for? Is the expected path for radeonsi:
> >> >>  clc->llvm->spirv->nir->llvm->isa, or clc->llvm->spirv->llvm->isa ?
> >> >
> >> > It depends how we end up deciding which IR to feed the driver (using
> >> > *_PREFERRED_IR, *_SUPPORTED_IRS, or something else), but the path would be
> >> > clc->llvm->spirv->*->driver or spirv->*->driver depending on how the programs
> >> > are created (resp. clCreateProgramWithSource or clCreateProgramWithIL).
> >> >
> >> 
> >> I thought we had agreed to continue supporting the current "clc->llvm
> >> ir->native binary->driver" path for targets that have an LLVM back-end
> >> (e.g. AMDGPU), so we can just give the pipe driver a binary, and also
> >> allow the application to query and cache programs as native machine
> >> code?
> >
> > Sorry, I must have misunderstood you then. I thought we had agreed to use
> > either SPIR-V or LLVM IR as the “canonical” IR, i.e. we would compile to and
> > link using that IR, and then convert to whatever IR the driver supports. So for
> > example, we compile to SPIR-V, link the different SPIR-V modules together, and
> > if we are creating an executable, we convert the linked module to native
> > machine code and store that in the clover module under the executable section.
> > That way, the driver receives the native code, and when querying for binaries,
> > the native code is returned (or whatever IR the driver supports).
> > For libraries, we want to keep them in SPIR-V/LLVM IR, as they will be used in
> > a linking step at some point.
> >
> 
> I don't think you misunderstood, but it seemed so from your previous
> paragraph. ;)

[snip]

> Why would we ever have to do either of those?  If the driver wants
> SPIR-V or NIR as IR, a SPIR-V input doesn't need to be translated to
> LLVM IR in the first place.  Likewise if the driver wants a native
> binary for an input in CL C, it doesn't need to be converted to SPIR-V
> in the first place.

I totally did misunderstood you, sorry for the spam everyone.
I re-read your initial message, and when you wrote

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

I somehow managed to parse that as a single canonical IR ”for clover” rather
than “for each CL device”… --" Time to fix my mistakes.

Regards,
Pierre
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180208/926953ab/attachment.sig>