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

Reply via email to