[Mesa-dev] RFC: Gallium support for ARB_shader_atomic_counters

[Ilia Mirkin]

On Mon, Jun 16, 2014 at 7:21 PM, Marek Olšák <maraeo at gmail.com> wrote:
> [Cc: Aditya]
>
> Aditya Avinash was interested in doing this as his first task in Mesa.

Oh awesome. Actually I think someone may have mentioned this fact to
me but then I forgot :) I'll look at other stuff then.

>
> 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.

Why does it matter whether something's an atomic counter or some other
kind of resource? i.e. why the separate ranges?

>
> 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