On 2018-02-08 — 12:47, Francisco Jerez wrote: > Pierre Moreau <pierre.mor...@free.fr> writes: > > > On 2018-02-07 — 12:36, Francisco Jerez wrote: > >> Pierre Moreau <pierre.mor...@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
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
