LLVM-SPIRV-Backend
LLVM-SPIRV-Backend copied to clipboard
KhronosGroup
Does it support Vulkan as well?
Nice to see this effort I've mainly 2 questions for this:
- Is Vulkan support planned? (Since https://github.com/KhronosGroup/SPIRV-LLVM-Translator exists and doesn't have Vulkan support)
- Any ideas on how "complete" this effort is right now?
As far as I know:
- Vulkan support development is planned not earlier than we implement OpenCL functionality comparable to the Translator in LLVM IR to SPIR-V conversion.
- Currently, no Vulkan specific features are supported. Some tests may pass but we haven't even tried such tests.
@iliya-diyachkov Thanks for replying
May I ask, from the mailing list
Current LIT pass rate is 60% and the plan is to have a full conformance before promoting to the production backend
Does that include Vulkan-flavored SPIRV or is it 60% for the OpenCL flavored SPIRV?
@VarLad this pass rate was calculated taking into account all LIT tests that are currently in our repository (https://github.com/KhronosGroup/LLVM-SPIRV-Backend/tree/feature/spirv-backend-llvm14/llvm/test/CodeGen/SPIRV) however I think all the tests are OpenCL flavored.
Can you give some informations about what is missing for vulkan support and a short summery how the code is structured? Where are the locations in the code that need to be adjusted?
In fact, I don't know what is exactly missing, because we are not currently using/testing Vulkan input in this project. Probably Vulkan specific memory model, capabilities, operands and operations are not supported well.
If you want to contribute to Vulkan support, I would suggest using test-driven approach, i.e. at first we need to find (or form) an appropriate set of tests and a reference tool which correctly converts the tests to SPIR-V. Then we try to convert tests using the backend, compare the result with the output of the reference tool, and correct the backend if necessary.
Most of the SPIRV backend sources are located in llvm/lib/Target/SPIRV, they are organized in the same way as in other llvm backends. Thus, to support Vulcan, you will need to modify the files in this directory.
Anyway you are welcome to ask more questions and participate in the project.
Where can I find the already written tests for the opencl part of the backend?
I will also try to find some students interested in helping with this undertaking once I got a better understanding of what actually needs to be done. Transforming unstructured control flow to structured control flow (which will probably be necessary) for instance sounds like an interesting topic.
Where can I find the already written tests for the opencl part of the backend?
You can find all the LIT tests in llvm/test/CodeGen/SPIRV/. We are targeting SPIRV for opencl, but I think most of the tests are generic to SPIRV. Later, Vulkan-specific tests may be added to llvm/test/CodeGen/SPIRV/vulkan.
Transforming unstructured control flow to structured control flow (which will probably be necessary) for instance sounds like an interesting topic.
I'm not sure that this task should be implemented in the backend. Anyway at first we need to investigate (on relevant tests) which functionality is missing and what is already working.
I'm not sure that this task should be implemented in the backend. Anyway at first we need to investigate (on relevant tests) which functionality is missing and what is already working.
If I understood it correctly we want to translate LLVM IR to SPIRV. At which point do we handle differences? Do we generate a SPIRV tailored LLVM IR, or do we use the general LLVM IR and differences are then taken care of when doing the LLVM IR -> SPIRV step?
Regarding the directx compiler that will be integrated into llvm. Does this mean, devs are currently only working on the hlsl frontend and the dxil target for llvm, and for the SPIRV target this repo will be used. Or do they work on a separate SPIRV implementation?
If I understood it correctly we want to translate LLVM IR to SPIRV...
The backend operates as all other backends, i.e. it consumes LLVM IR and produces asm/obj output, which in our case is SPIRV IR in text/object format. GlobalISel framework is used for this translation (see reference info in https://llvm.org/docs/GlobalISel/index.html).
Regarding the directx compiler that will be integrated into llvm...
I did not discuss it with the devs, but implementing another SPIRV backend is a lot of extra work, so I don't think they're going to do it. We use this repo for current development, but we have already started upstreaming the backend to llvm-project repo (however it's not fully copied there yet).
By the way there is fully functional LLVM <-> SPIRV translation tool (https://github.com/KhronosGroup/SPIRV-LLVM-Translator). We use it as a reference tool. But this is a standalone application, not integrated into llvm.