This is an archive of the discontinued LLVM Phabricator instance.

[mlir][spirv] Avoid struct wrapping in non-interface storage class
AbandonedPublic

Authored by antiagainst on Mar 12 2021, 7:13 AM.

Details

Summary

Per the SPIR-V spec "2.16.2. Validation Rules for Shader Capabilities":

Composite objects in the StorageBuffer, PhysicalStorageBuffer,
Uniform, and PushConstant Storage Classes must be explicitly
laid out.

Per the Vulkan spec "15.6. Shader Resource Interface":

The shader variables defined with a storage class of PushConstant
that are statically used by the shader entry points for the
pipeline define the push constant interface. They must be:
* typed as OpTypeStruct.

Variables identified with the Uniform storage class are used to
access transparent buffer backed resources. Such variables must be:
* typed as OpTypeStruct, or an array of this type,

Variables identified with the StorageBuffer storage class are
used to access transparent buffer backed resources. Such
variables must be:
* typed as OpTypeStruct, or an array of this type,

For other cases we don't need to wrap with a struct.

Diff Detail

Event Timeline

antiagainst created this revision.Mar 12 2021, 7:13 AM
antiagainst requested review of this revision.Mar 12 2021, 7:13 AM
mravishankar requested changes to this revision.Mar 15 2021, 12:27 PM

Wondering if there is a problem if we have the struct all the time. One of the issues on SPIR-V side is that we cannot do pointer casts. So a memref_cast where the operand is from something that doesnt need layout to something that does need layout would be not possible support. In general, there is no information of where the memref came from, so we might end up in situations where we cannot lower such memref_cast. If there is no reason to not have a struct, it seems more uniform to have a struct by default for all memref types.

This revision now requires changes to proceed.Mar 15 2021, 12:27 PM

Good points Mahesh!

Wondering if there is a problem if we have the struct all the time.

Main motivation is to provide as clean code as possible to the backend driver to avoid unnecessary overhead there (like no need for SROA etc.). But I don't have concrete numbers to say how much it matters for now.

One of the issues on SPIR-V side is that we cannot do pointer casts. So a memref_cast where the operand is from something that doesnt need layout to something that does need layout would be not possible support. In general, there is no information of where the memref came from, so we might end up in situations where we cannot lower such memref_cast.

Actually this should not be a valid case. Different storage classes potentially mean different hardware functionality blocks. So casting pointers from one storage class (i.e., memref memory space) to another one is not valid in general. One will need to load/store to cross storage class boundaries in general.

If there is no reason to not have a struct, it seems more uniform to have a struct by default for all memref types.

Sounds reasonable to me. I'll keep the struct still for now. Send D100386 to drop the struct offset though.

antiagainst abandoned this revision.Apr 13 2021, 7:24 AM