KhronosGroup / SPIRV-LLVM-Translator

A tool and a library for bi-directional translation between SPIR-V and LLVM IR
Other
467 stars 209 forks source link

Option to perform systematic SPIR-V module validation ? #2263

Open Naghasan opened 8 months ago

Naghasan commented 8 months ago

Hello,

I have been wondering if there is an option is to run the validator on the generated module as I can't find any. The only integration of SPIRV-Tools I'm aware of is the disassemble option and the use of the tools in tests.

If there is no such option, is there a reason behind or just lack of engineering resource ?

MrSidims commented 7 months ago

When SPIR-V tools are installed and the translator is build on top of them - one may also add ; spirv-val in a test (see test/CMakeLists.txt and the appropriate usages in test/ ).

llvm-spirv has some internal validations (see overloaded for each instruction validate() method), but optionally enabling spirv-val by the end of the translation seem to be a good idea. At this point of time we (as translator team in general) are lacking of engineering resource to clean up all known validator issues, but we are doing it from time to time. I believe once it is done we can add the appropriate infrastructure for optional validation.

In addition to that we (now as Intel translator team) do want to upstream every implemented extension to SPIR-V Registry and Headers (unfortunately that is not done yet), so validator can also validate our extensions as well. Once it's done we would have one less blocker for a proper implicit validation.

Naghasan commented 7 months ago

thanks for the answer.

When SPIR-V tools are installed and the translator is build on top of them - one may also add ; spirv-val in a test (see test/CMakeLists.txt and the appropriate usages in test/ ).

Yes, I mentioned that in message. But it is quite different to run the validator in reproduction tests that it is to make the tool validate what it outputs. I'm not saying one better that the other, just 2 different use cases.

Once it's done we would have one less blocker for a proper implicit validation.

I'm well aware of current limitations. If added it has to be an opt-in switch.