[Mlir-commits] [mlir] [mlir][memref-to-spirv]: Reverse Image Load Coordinates (PR #160495)

[Igor Wodiany]

IgWod-IMG wrote:

> Okay so, I started implementing these changes but thinking about this a bit more, does SPIR-V provide any mapping from texel coordinates to hardware memory, or are images and texels completely opaque?

My understanding is that in SPIR-V images are just handles and are opaque.

> In this conversion we are providing a generic lowering that is assuming for images width is the contiguous dimension in memory, followed by height and then depth. Whilst this might be a valid assumption for some hardware, is this true for all targets?

I investigated image stuff a bit more and it seems that it is okay to assume you always have width, height and depth in that order. SPIR-V is mostly hardware agnostic, so it is up to the vendor to translate `OpImageFetch` coordinates into something that fits into the memory layout of the actual hardware, as such I don’t think we need to concern ourselves with the actual hardware layouts at this level.

> Does this lowering as an upstream conversion even make sense?

I think it does, but we need to be careful with how we map `memref` that can represent many different layouts to something that is rather opaque. At the same time, it seems to me that the alternative solution would be to leave the conversion as it is, and then it would be up to the driver/host to make sure image is in the correct order so that indexing makes sense.

I think it would be useful to get an input on this patch from someone who has more experience with SPIR-V.

https://github.com/llvm/llvm-project/pull/160495