[Mesa-dev] RFC: buffer support in TGSI for SSBO/atomic

[Ilia Mirkin]

Just wanted to note down some thoughts and get some feedback before
going forward. I've already sent out a series which covered a lot of
this, but in the end I realized it came up a bit short (available at
https://github.com/imirkin/mesa/commits/fd2).

There are two separate buffer-related features --
ARB_shader_atomic_counters(_ops) and
ARB_shader_storage_buffer_objects. The former are implementable more
efficiently on EG/NI hardware by performing the atomic ops on
not-main-memory (GDS? LDS?). However I think that the gallium-side
interface can be mostly identical for both cases, perhaps we can mark
the buffer as atomic-only in the TGSI.

Just like there is a CONST tgsi file, I want to add a BUFFER file,
which will map to ->set_shader_buffers() indices. The tricky bit comes
in from the fact that individual variables inside of a buffer may have
different access/store properties. I see two ways to resolve this:

1. Declare each variable explicitly, much like UBO's still get
individual decls per slot. These decls could contain the relevant
caching property.

2. Make each LOAD/STORE op declare what caching it wants explicitly.

The first option would work well for images, but for ssbo, it feels
problematic, as with all the various packing options that exist, you
could still specify odd per-variable cache rules, which would be
difficult to express in the TGSI DECL. However I'm not sure how to
implement the second option.

There is a precedent of a saturate flag, but looking at
tgsi_instruction, there are only 2 free bits. Since there are only 4
different caching values (none, coherent, volatile, restrict; I'm not
counting readonly/writeonly), this fits. However that would leave no
more bits in tgsi_instruction. I could add a texture-style bit, saying
to expect an additional tgsi_instruction_buffer packet with more info
but that seems wasteful.

Another option is to just pass an immediate directly to the LOAD/STORE
ops which would specify this caching spec as an extra source. This
seems much simpler, but a little dirtier. Opinions much appreciated.

I think that one this is worked out, I'll be able to resend my series
adding SSBO/atomic support to freedreno, and partial SSBO (without
atomic*) support for nvc0.

Cheers,

  -ilia