[SPIR-V] support loading "structured" data from a random device address

[jaebaek]

We support loading "bytes" data from a random device address without a memory layout support in #4226. In the future, we will add loading "structured" data from a random device address, which needs a sophisticated design for the memory layout rules.

[BeastLe9enD]

Any news on this? It would be very interesting to be able to work with complicated structure types

[natevm]

It would be helpful to have a real world example here.

I don’t see why one would want any memory layout other than HLSL’s 16 byte alignment rules, especially if this raw buffer of data is a byte for byte copy from the host.

In CUDA for example, a device address (a pointer) leaves it to the user to get correct byte alignment, setup the appropriate structure layout etc. No strange layout rules apply there, and i’d argue CUDA is a fairly successful language for keeping thing simple like this.

I’d currently argue against such a feature, but perhaps there is some use case I’m not seeing?

[devshgraphicsprogramming]

Or one could just follow the scalar layout rules, since the device is likely to have them if it has BDA anyway?

[devshgraphicsprogramming]

Alternatively if the compiler instantiated "reference meta types" like suggested in #4986

then you could add the layout rules as a template parameter to later work out the OpAccessChain

[natevm]

Or one could just follow the scalar layout rules, since the device is likely to have them if it has BDA anyway?

I personally have been assuming scalar, which seems to work fine for the “bundles” platforms using this feature. For now this seems like a safe assumption… but I could see an argument made for the other layouts.

At the moment, I’ve noticed on AMD platforms that these raw buffer loads and stores cause their internal driver compiler to crash. Perhaps this has something to do with the layout rules?