[Mesa-dev] [PATCH 1/2] gallium: add CAPs to support HW atomic counters.

[Dave Airlie]

On 2 August 2017 at 20:56, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
> On 02.08.2017 01:00, Dave Airlie wrote:
>>
>> From: Dave Airlie <airlied at 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?

It's GDS but not the same GDS as you mean I suspect.

Evergreen/Cayman have GDS append/consume counters. There is a
special PKT3 to load the values, and you have to use and EVENT to get the
values back out.

>
> 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?

Yes, at the moment you get ATOMIC as the first X buffer indices, the
rest are buffers.

>
> 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.

Yes we need this to get the state tracker to offset the real buffers
from the atomic buffers
by the correct amount.

> 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.

This doesn't really make sense though. The current limits are pretty
much GL defined limits,
you can fit as many atomic counters into an SSBO has you want. It
doesn't make much sense
then for the drivers to all report these values separately if they
only support SSBO atomics.

Only when you have actual HW counters which are physically limited by
the hw should we report
the values the HW limits us to.


>> 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 <airlied at 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).

I suspect for GDS atomics you might want to add another mode here.

Dave.