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

[Nicolai Hähnle]

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?

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

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.