Handle DS_READ_U16, DS_WRITE_B16, DS_ADD_U64

[mikusp]

Hit by God of War

[squidbus]

Are you sure shift by 2 (divide by 4) is still correct for a 16-bit value?

[mikusp]

No idea, documentation doesn't really say that, they use addr for all accesses 16/32/64bit

[squidbus]

Well I suppose regardless of guest requirements you do need to have the right index for whatever we are using on the SPIR-V side, for example if we have a shared memory u16 array you need to shift 1 over to index by u16.

[red-prig]

Since you are using an array of 32 bit values, so dividing by 4 will be the base index, and then you need to take either the upper or lower part depending on the first bit:
result = ((offset & 1)=0) ? buf[offset/4] & 0xFFFF : buf[offset/4] & 0xFFFF0000

[red-prig]

Oh, the second bit is not the first, lol
result = ((offset & 2)=0) ? buf[offset/4] & 0xFFFF : buf[offset/4] & 0xFFFF0000

[squidbus]

The approach mentioned by @red-prig here is probably correct if we don't have a way in SPIR-V to alias the same shared memory array as a different type (I don't remember if this is the case). The code as of current revision creates two separate arrays which could be problematic if a shader mixes access sizes.

[red-prig]

Creating aliases usually works fine, the problem is more likely in addressing a 16-bit value, not all GPUs support this, and those that do may work slower

[squidbus]

I think we are fine in that regard given we already may do so for buffers.

[mikusp]

I'm working on a better implementation with aliasing definitions for u16/32/64, as the partial access mentioned by red_prig won't work for atomic operations

[georgemoralis]

Review issues seems to be fixed