GLSL to SPIR-V dialect frontend project, still open?

MLIR
21

Hi @antiagainst,
I am interested to start on adding OpTypeForwardPointer. I have been looking into how to do this and I find that the proposal in this thread: [RFC] First-Party Support for LLVM Types can be adapted in the spv dialect as well.

In particular, I guess we can use Alex’s proposal to modify spv.struct to be optionally identified. For example, by adapting that proposal, the following MLIR code:

!spv.struct<"s1", (i32, ptr<struct<"s1">, ptr<struct<"s2", (f32)>)>

would translate to the following SPIR-V code:

OpCapability Addresses
OpCapability Kernel
OpCapability GenericPointer
OpCapability Linkage
OpMemoryModel Physical32 OpenCL

OpTypeForwardPointer %s1_ptr Generic
OpTypeForwardPointer %s2_ptr Generic

%intt = OpTypeInt 32 0
%floatt = OpTypeFloat 32

%s1 = OpTypeStruct %intt %s1_ptr %s2_ptr
%s1_ptr = OpTypePointer Generic %s1

%s2 = OpTypeStruct %floatt
%s2_ptr = OpTypePointer Generic %s2

I might still need to work out some of the details and cover some of the angles I am not aware of. But, in general, do you think this would be a viable direction?

22

Oh nice! Thanks for pointing out; that’s indeed a possible way to model it. As always, Alex typically has awesome solutions towards things. :slight_smile: (Sorry I wasn’t following closely there; thought it’s LLVM specific and it’s a bit lengthy.) Let me comment there directly. Also, IIRC we are gonna to have a ODM to discuss this; so we can chat more about it.

23

Awesome, looking forward to your input either on the thread or during the ODM meeting. I am not sure I will be able to listen in because of the time difference, but will try.

24

Yup. Replied. The discussion will be recorded so no worries if you cannot make it; you can always follow the recordings later.

25

Thanks for the responses.

This is quite an exciting extension to work on. I already started playing with the current implementation of struct types and hopefully I will have some working prototype soon.

26

I am also interested in the glsl->spir-v dialect frontend topic. Any update on this project? Thanks.

27

I don’t think there are concrete progress on it. Are you interested in contributing to it or using it?

28

I am more interested in using a frontend converting from glsl → mlir. That is why I wonder whether this project is still active.

29

Yeah. There isn’t a direct way to do that at the moment. We have a deserializer that can take in a SPIR-V blob and translate it into MLIR form. Using that with an existing GLSL frontend might be an indirect way. With that said, that may or may not satisfy your needs. Also the deserializer is tightly developed with the serializer and sort of overfits to the cases we see in ML land right now. So it might need some effort to teach it to understand patterns generated by other SPIR-V generators.

30

Thanks for the quick reply. About the existing GLSL frontend, is there any recommendation besides glslangValidator?

31

You could also try shaderc, which comes with glslc. glslc gives you a Clang-like CLI experience, which I personally prefer to glslang. But shaderc itself is just a wrapper over glslang. So fundamentally they are the same. Shaderc/glslc can be found in newer versions of Vulkan SDK.

32

Thank you for the infomation! I will take a look at glslc.