[Mesa-dev] RFC: Gallium support for ARB_shader_atomic_counters

[Marek Olšák]

[Cc: Aditya]

Aditya Avinash was interested in doing this as his first task in Mesa.

But what you describe sounds good. If we use set_shader_resources for
atomic counter buffer objects, we should also have a plan for how we
will bind shader storage buffers objects and images. I suggest we use
a disjoint range of binding points for each, e.g. atomic counters:
0..15 (if we need so many), storage buffers: 16..31, and images:
32..47 if a driver supports 48 writable shader resources. The state
tracker will have to divide the binding points among all resource
types.

Marek

On Tue, Jun 17, 2014 at 12:43 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> Hello,
>
> I've been toying with the idea of adding gallium support for the
> atomic counters extension in gallium. Nouveau already largely supports
> it, so it's mostly a question of plumbing. (One piece that's missing
> in nouveau is _actually_ binding resources, but that can't be too
> difficult... I hope.)
>
> It seems like the thing that makes the most sense is to make sure that
> the atomic buffer is allocated with PIPE_BIND_SHADER_RESOURCE, and use
> ->set_shader_resources to bind them. Then the TGSI opcodes generated
> would refer to TGSI_FILE_RESOURCE objects linked to those atomic
> buffers. I would reuse the existing ATOM* opcodes + LOAD/STORE (didn't
> check if extra ones are needed, but I'd assume not).
>
> Am I missing some large piece of this? Is there an easier/better way
> of doing this? It'll obviously require a bunch of work in
> st_glsl_to_tgsi to add support for tracking resources/etc.
>
>   -ilia
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev