It would make sense to add
pipe_context::set_atomic_counter_buffers(pipe, start, count, buffers)
that are available in all shader stages, because it's how OpenGL
works. Only SSBOs are per-shader stage.
Marek
On Wed, Aug 2, 2017 at 12:56 PM, Nicolai Hähnle <nhaeh...@gmail.com> wrote:
> On 02.08.2017 01:00, Dave Airlie wrote:
>>
>> From: Dave Airlie <airl...@redhat.com>
>>
>> This looks like an evergreen specific feature, but with atomic
>> counters AMD have hw specific counters they use instead of operating
>> on buffers directly. These are separate to the buffer atomics,
>> so require different limits and code paths.
>
>
> Do you mean GDS?
>
> I've been thinking about GDS on radeonsi as well. Apparently, the latency
> for GDS atomics is about half or perhaps even less compared to the texture
> (regular memory) pipe. So it'd be nice if the Gallium interface can somehow
> cover both.
>
> Is this the whole set of changes you plan for st/mesa? So the driver somehow
> determines which TGSI BUFFERs are SSBOs and which are atomic counters, and
> then handles them accordingly?
>
> Do you really need the MAX_HW_ATOMIC_COUNTER_BUFFERS cap? I assume counters
> are loaded into special memory and read back from it using explicit
> commands, so the hardware doesn't really have a limit, but I guess the
> driver does.
>
> Hmmm... given that st/mesa doesn't really do much with most of this
> information, what about this:
>
> Can we perhaps just add MAX_ATOMIC_COUNTERS and MAX_ATOMIC_COUNTER_BUFFERS
> caps that are set/used by all drivers? I don't see why the state tracker
> needs to know about the concept of an atomic_counter_mode. As long as
> drivers are able to specify number of atomic counter buffers and SSBOs
> separately, and we specify that the first N buffers are atomic counter
> buffers, then the driver can figure things out just fine.
>
>
>> I've left the CAP for atomic type extensible in case someone
>> else has a variant on this sort of thing (freedreno maybe?)
>> and needs to change it.
>>
>> This adds all the CAPs required to add support for those atomic
>> counters, along with a related CAP for limiting the number of
>> output resources.
>>
>> I'd like to land this and the st patch then I can start to
>> upstream the evergreen support for these and other GL4.x features.
>>
>> Signed-off-by: Dave Airlie <airl...@redhat.com>
>
> [snip]
>>
>> diff --git a/src/gallium/include/pipe/p_defines.h
>> b/src/gallium/include/pipe/p_defines.h
>> index b39612f..b838ce5 100644
>> --- a/src/gallium/include/pipe/p_defines.h
>> +++ b/src/gallium/include/pipe/p_defines.h
>> @@ -781,11 +781,18 @@ enum pipe_cap
>> PIPE_CAP_POST_DEPTH_COVERAGE,
>> PIPE_CAP_BINDLESS_TEXTURE,
>> PIPE_CAP_NIR_SAMPLERS_AS_DEREF,
>> + PIPE_CAP_ATOMIC_COUNTER_MODE,
>> + PIPE_CAP_MAX_COMBINED_SHADER_OUTPUT_RESOURCES,
>> };
>> #define PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_NV50 (1 << 0)
>> #define PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_R600 (1 << 1)
>> +/* normal mode used by most hardware */
>> +#define PIPE_ATOMIC_COUNTER_MODE_USE_BUFFERS 0
>> +/* limited HW counters used by evergreen */
>> +#define PIPE_ATOMIC_COUNTER_MODE_HW_COUNTERS 1
>> +
>
>
> Please make this an enum (although as mentioned above, I'd rather just get
> rid of it entirely).
>
> Cheers,
> Nicolai
>
>
>> enum pipe_endian
>> {
>> PIPE_ENDIAN_LITTLE = 0,
>> @@ -850,6 +857,8 @@ enum pipe_shader_cap
>> PIPE_SHADER_CAP_MAX_SHADER_IMAGES,
>> PIPE_SHADER_CAP_LOWER_IF_THRESHOLD,
>> PIPE_SHADER_CAP_TGSI_SKIP_MERGE_REGISTERS,
>> + PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTERS,
>> + PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTER_BUFFERS,
>> };
>> /**
>>
>
>
> --
> Lerne, wie die Welt wirklich ist,
> Aber vergiss niemals, wie sie sein sollte.
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
