Which version of the code did you build? The Unknown command line argument '-no-implicit-module' Makes me think you’re trying a newer example with an old build, either build at HEAD or look for an example in the repo at the same revision as your build.
Note that there are two examples in this file, and the --split-input-file will process them by splitting on // -----, this is fine because the test does serialization and deserialization. Otherwise the result may not be a valid spirv module (it’ll output the two in a two).
mlir-translate seems to be happy to deserialize for me, I can’t tell if we generate invalid bytecode or if there is an issue with the spirv-dis tool here. @antiagainst or @kuhar may be able to help?
I deleted one of the modules and it was working fine.
Yes the serializer and deserializer is meant to work on only a single spirv.module op.
I noticed that you mentioned you are playing with fragment shaders, great! But keep in mind that right now we are mainly using MLIR SPIR-V code generation for compute use cases (Vulkan compute, OpenCL); graphics support is not complete. You will likely hit other issues. If that happens, don’t hesitate to reach out!
But keep in mind that right now we are mainly using MLIR SPIR-V code generation for compute use cases
Huh that’s good to know.
I’m actually interested in if I can convert mlir → vulkan → glsl and run in webgl so I’d not be surprised if I just give up midway through haha
You will likely hit other issues. If that happens, don’t hesitate to reach out!
Thank you so much. I want to do mlir → spirv → glsl
But in order to get the glsl I want, I tried to do the reverse(glsl → spirv → mlir) with a very simple shader to get an understanding of what I should be doing.
frag.frag
#version 460
out vec4 FragColor;
in vec3 ourColor;
void main()
{
FragColor = vec4(ourColor, 1.0);
}
frag.spv(compiled glsl with naga and disassembled with spirv-dis)
While I’m not sure exactly what above issue is, I guess it’s related null-support in glsl.
Since reversing(glsl → spirv → mlir) seemed difficult, I read through spirv dialect documentation to write below mlir. This compiled successfully to glsl with mlir-translate & spirv-cross.
I think I’ve got a very rough understanding of mlir, so thank you for your support and good documentation.
With that said, I will leave some opinions on the doc for future new-comers.
mlir-opt and mlir-translate should be the first thing to introduce to new-comers. While I’m unfamiliar with any compiler IRs, coding a .mlir and mlir-translate gave me a very good idea of what mlir is capable of. (Related: [doc] mlir-translate / mlir-opt - #30 by clattner)
The relationship between various dialects are obscure. I wish a comprehensive directed graph diagram of dialects like this one was available at the root of dialect documentation.
This actually hits a not-yet-implemented feature in deserializer–it supports other global variables as initializer but not yet constants (which comes from OpConstantNull). Sorry about the confusion.
Note that the deserialization logic is coupled with the serialization logic. Right now we mostly developed it as a way to test the serialization logic in round-trip tests. So it only covers the SPIR-V cases we commonly see in compute cases for ML. In reality, to have a robust deserializer, we need to handle way more complicated SPIR-V cases in the wild (because there are many SPIR-V compilers/producers and can generate SPIR-V in different forms). This part certainly needs more investment. (This is also what I meant previously by saying "You will likely hit other issues.)
Yup, going from MLIR SPIR-V dialect to SPIR-V blob is certainly more battle tested and well supported.
Ah, yes. The assembly form of spirv.CompositeConstruct changed a while ago but we forgot to update the example there. Please feel free to send a patch to have it fixed!
