But I notice that in SPIRVToLLVM.cpp, we have a function encodeBindAttribute. It encodes the “binding” and “descriptor_set” into the global variable name. Considering that “location” is also a layout qualifer as “binding” and “descriptor”. Do we prefer using the mechanism in encodeBindAttribut or setting “location” as an attribute of llvm.mlir.global is also fine?
Also based on our investigation, we will also encounter the same issue when converting image load store since image also attch many attributes to record its image type.
Hey @Weiwei-2021, thanks for your interest in the SPIR-V to LLVM conversion!
Before going into details, just wanted to remind you that it’s contributed by @george as a GSoC project. See the conversion manual and George’s summary here if you haven’t run into them.
George did a fantastic job and it’s a great contribution, but there are still quite some technical issues unaddressed (e.g., multithreaded cases, robust and flexible ABI support, etc.) to have it as something you can use for load-bearing workloads. What you are looking at here is effectively ABI, which isn’t fully fleshed yet. I’m curious, what would you like to achieve with this location support? Depending on your answer (just trying out things, or make it work with some your internal stack, etc.), the suggestion might be different. Could you elaborate on the intention a bit more?
Coming to the specific location support, a couple of points.
spv.GlobalVariable should actually have native support for it. Right now we only support descriptor set and binding and builtin. Even they are just specially treated in verification/conversion but not in ODS. These should all be in ODS as native attributes for better integration.
This is certainly doable. But I don’t think attaching the location to the resultant llvm.mlir.global is the final step. You need to do something with it later. Like if this is a driver compiler consuming SPIR-V input and generate architecture specific GPU ISA, you’ll need to pick up the attribute here and use it to link different graphics shader stages. Is that what you want? Or something else?
Please don’t read too much into the current descriptor set/binding treatment. They are there to serve the purpose of having a MVP to have a CPU-based mlir-spirv-cpu-runner. It should not be seen as the way of handling it. Effectively descriptor set/binding is a part of the ABI. The host and device exchange data through the contract there. They should match. In the mlir-spirv-cpu-runner (which is a MVP host) we decided to use the string encoding for that purpose. But I can image in production driver there can be other ways (like using attributes, etc.).
Location is similar to descriptor set/binding in a sense but it also has its own responsibly. It is also used for linking different shader stages. There are details in the Vulkan spec. I’d assume you want to do that after converting to LLVM (which is why you’d like to pass down the location). Is that correct?
Not sure I fully follow here. Do you mean you are plumbing image support through the SPIR-V to LLVM conversion and seeing similar issues of attributes being dropped?
Thank you for sharnig those! It provides a clear picture about the SPIRV->LLVM project.
This is exactly what I am trying to do, e.g., propogate the location and pick up it when coverting LLVM dialect to llvm IR.
Good to know about it. I checked the file and want to find a standard approach to do it. That is why I ask.
Yes, we need to know this location info at llvm IR level for further compilation. Also curious why the current mlir-spirv-cpu-runner doesn’t encounter this issue? The shaders it used don’t contain any location qualifer?
I should not raise another topic at the last minute which is confusing.Sorry about it. I don’t have an example in my hand now. Let us disscuss it later when I successfully repeat this error.
In summary, using attribute to represent “location” is a feasible approach. Thank you for sharing those information. I will use add this attribute to llvm.mlir.globalvarible and submit a patch for it. Thanks again and have a good day.
mlir-spirv-cpu-runner is only handling the compute portion. So there is no location and graphics shader stage linking and such. But I’m glad that you are pushing further on the graphics support. Looking forward to what you come up with later!
I think you mean spv.GlobalVariable here? Yup, please go ahead. My only request is that please handle descriptor set/binding and builtin similarly given you are touching this part. Don’t’ want to be in a hybrid situation.