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.
Marek On Tue, Jun 17, 2014 at 1:26 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Mon, Jun 16, 2014 at 7:21 PM, Marek Olšák <mar...@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 <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