Misc. bug: Vulkan OOB Access when robustness is turned off

[spencer-lunarg]

Name and Version

Running the vulkan backend /bin/test-backend-ops -o MUL_MAT I found using GPU-AV in the Vulkan Validation Layers it will produce this error

Validation Error: [ VUID-vkCmdDispatch-storageBuffers-06936 ] | MessageID = 0xace7baff
vkCmdDispatch(): (set = 0, binding = 1, index 0)  access out of bounds. The descriptor buffer (VkBuffer 0x48d000000048d) size is 42560 bytes, 9216 bytes were bound, and the highest out of bounds access was at [17311] bytes

It is happening at lama.cpp/ggml/src/ggml-vulkan/vulkan-shaders/mul_mm_funcs.glsl:488

FLOAT_TYPE_VEC8 bb = FLOAT_TYPE_VEC8(data_b[idx]);

---

While this is an error, I will note I had to turn off robustBufferAccess as with it on, this is very valid, and this issue is more of a "warning" ... @jeffbolznv feel free to close this if you think this is not worth keeping open/fixing

This is with the latest 9b17d74 commit on a ToT RADV driver

Operating systems

Linux

Which llama.cpp modules do you know to be affected?

Test code

Command line

Problem description & steps to reproduce

./bin/test-backend-ops -o MUL_MAT

First Bad Commit

No response

Relevant log output

[jeffbolznv]

I'm pretty sure this is expected. We don't explicitly bounds check the row dimension of matrices in the mul_mm shader, because doing so gets in the way of the compiler batching the loads. Out of bounds source rows don't matter to the result, since they only affect OOB rows of the destination.