[Mesa-dev] RFC: Gallium support for ARB_shader_atomic_counters

Marek Olšák maraeo at gmail.com
Mon Jun 16 16:31:55 PDT 2014

It's only for the state tracker. Drivers don't have to be concerned
about this and should just expose a fixed number of writable shader
resources that can be used with all types.


On Tue, Jun 17, 2014 at 1:26 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> 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

More information about the mesa-dev mailing list