On 9 August 2017 at 21:44, Nicolai Hähnle <nhaeh...@gmail.com> wrote: > Hi Dave, > > Thanks for the update, I prefer this. > > Have you considered Marek's query about pipeline-wide atomic buffers? > > The issue I'm thinking about is what happens when multiple shaders access > the same atomic counter. In a GDS/GWS-based implementation, those accesses > must map to the same hardware counter slot, as far as I understand it. But > if you follow a straight-forward mapping based on today's TGSI, they won't > be. > > There are two types of situations that can happen: > > 1. A GL program object has one counter that is accessed by multiple stages. > > 2. A GL program object (or even a single shader stage) has multiple counters > with different bindings, and the same buffer range happens to be bound to > both bindings. > > I'm pretty sure the second case is intended to be undefined behavior (see > Issue 19 of ARB_shader_atomic_counters), but I believe the first case is > intended to be supported. > > So *something* has to make sure that different stages end up accessing the > same hardware counter. One way of doing this is to have a global (as opposed > to per-shader-stage) list of atomic buffers at the Gallium pipe_context
So there is a reason I haven't considered it yet, r600 only support one atomic buffer, for non-compute shaders. For compute shaders it supports 8. I'm not sure I'll get much out of changing that interface for a device I can't really test it with. I guess we should do the interface Marek suggested but I think I'd rather wait until radeonsi tackles it. Dave. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev