Skip to content

GLES31: Issues with atomic opcodes

  1. tgsi_opcode_infer_dst_type / tgsi_opcode_infer_src_type doesn't have cases for atomic opcodes, causing our conversion logic to break down.

  2. All atomic ops could take an uint and int:

https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/atomicCompSwap.xhtml

However, many TGSI opcodes don't make the distinction (i.e, we only have ATOMCAS and not ATOMICAS / ATOMUCAS).

  1. We always assume SSBOs are a long array of uints. However, opcodes (ATOMIMAX, ATOMIMIN) require a long array of ints. Our usual trick of casting to an int won't work:

"A shader will fail to compile if the value passed to the mem argument of an atomic memory function does not correspond to a buffer or shared variable. It is acceptable to pass an element of an array or a single component of a vector to the mem argument of an atomic memory function, as long as the underlying array or vector is a buffer or shared variable."

We could workaround this by having a shared variable temp that loads from the SSBO. But it'll be different memory than the SSBO, so that can cause issues as well.