[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 <imir...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
