I’m writing a C+±>SPIRV backend. spirv-val is telling me that OpMemoryModel Logical addressing is not compatible with functions that return pointer types, even when those pointer types’ storage class is Function. This is counter-intuitive to me, since I’d think all those cases could be covered by Logical addressing.
I’m not doing anything that requires true physical addressing. I’d think the normal virtual addressing would be fine, but that’s apparently not an option. Is there any text on what Physical64 addressing actually means? I checked the SPIRV, Vulkan, GLSL and GL specs and there’s basically nothing.
What do you mean? By your own admission, you are returning a function pointer. That is not normally allowed in logical addressing.
“Basically nothing”? The SPIR-V specification goes into quite a bit of detail as to how physical and logical addressing works. There are two primary locations where these are defined. There’s the section on memory models:
The Logicaladdressing model means pointers are abstract, having no physical size or numeric value. In this mode, pointers can only be created from existing objects, and they cannot be stored into an object, unless additional capabilities, e.g., VariablePointers , are declared to add such functionality.
The non- Logicaladdressing models allow physical pointers to be formed. OpVariable can be used to create objects that hold pointers. These are declared for a specific Storage Class. Pointers for one Storage Class cannot be used to access objects in another Storage Class. However, they can be converted with conversion opcodes. Any particular addressing model must describe the bit width of pointers for each of the storage classes.
And there’s the universal validation rules section which tells exactly where you can and cannot have pointers in logical addressing modes.
Is there any downside to just setting Physical64 for all modules? Is this just a capability request, or is there a performance implication? I need to pass pointers through functions, eg “this” pointers and return object pointers. The inliner in the backend (SPIRV-Tools) may or may not get rid of all uses that require this setting. I just don’t know how concerned to be from a compiler frontend standpoint.
So… there’s no chance of actually targeting GL or Vulkan? At least not without really torturing the generated code. I see the validation rules sections now. OpenCL requires Physical64 as expected, and CUDA dose the same thing. I was expecting better parity of graphics and compute. This is very disappointing.