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? >> What advantages does it bring to any target? why can't the targets that >> are not natively supported by llvm just consume llvm IR and do the >> necessary translations on driver side? > > What disadvantages does it bring to have clover take care of the translation > (for IRs that are easily translatable from LLVM IR/SPIR-V)? It already has all > the dependencies needed, the translation is implemented in a single common > place, and if you don’t want OpenCL you do not need to still depend on LLVM > (except for the drivers for AMD cards). > Maybe that the translation is unnecessary and is going to create more than zero work for the pipe driver to obtain a binary? >> > So once >> > spirv_to_nir supports OpenCL SPIR-V (which I believe is being worked on by >> > Rob >> > Clark for freedreno, and Karol Herbst for Nouveau), RadeonSI could start >> > accepting even OpenCL kernels as NIR. >> >> Why would anyone want that? > > In case it simplifies the code in the driver; I haven’t looked at that code > though. It was only a suggestion, and meant that for RadeonSI, there could no > longer be a conflict between the IR fed from OpenCL and the one from OpenGL, > which was one of the problem addressed in this patch. > As long as we use PIPE_SHADER_CAP_SUPPORTED_IRS to enumerate the IRs the driver is willing to accept I don't think there is a real conflict, the pipe driver can just set both bits and have the state tracker choose which one to provide. >> what is the expected path from CLC? if you >> need the external spirv tools package, why not use it in the other >> direction and keep LLVM IR as clover preferred representation? >> note that libclc is distributed in target specific LLVM IR. > > I am not entirely sure what the interaction with libclc should be, as I am > only > starting to look into it. Possibly we would add a spir[64] target to it and > use > that. > Yeah, I think having a spir-v target-(un)specific implementation of libclc would be a pretty reasonable plan. > We could indeed use LLVM IR instead of SPIR-V, as mentioned by Francisco Jerez > in his reply to “[PATCH v2 00/22] Introducing SPIR-V support to clover” on the > 23rd of January 2018 (I don’t have a direct link as this is one of the emails > which did not get archived), which shouldn’t change much apart from having: > > * clc->(compile)->llvm->(link)->llvm->(translate to driver IR) > * spirv->llvm->(link)->llvm->(translate to driver IR) > > instead of > > * clc->(compile)->spirv->(link)->spirv->(translate to driver IR) > * spirv->(link)->spirv->(translate to driver IR) > > (For drivers using NIR, the translation would be either llvm->spirv->nir or > spirv->nir; I don’t think there is a llvm->nir pass, but I could be mistaken.) > > However, with OpenCL 2.2 you can specialise constants, so if we use LLVM IR, > we > would either need to > 1. keep a hash map from SPIR-V IDs to LLVM IR variables/functions and edit the > LLVM module; > 2. convert back to SPIR-V (and hope that the SPIR-V IDs didn’t change), > specialise, and convert back again to LLVM IR. > Or, if we use SPIR-V, we just do the specialisation directly. > I don't think constant specialization changes the picture at all, AFAIUI they only apply to kernels that are written in SPIR-V in the first place, and require a rebuild to take effect, so we could handle them in exactly the same way regardless of whether the SPIR-V is being translated into LLVM IR during compilation or whether it's being used as program representation internally by clover. > Also, OpenCL C++ is only supported through clCreateProgramWithIL(), which will > give us a SPIR-V binary. > > Regards, > Pierre > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
