asahi: Don't advertise ARB_clip_control yet

Our depth handling is pretty busted as it is. Adding clip control into
the mix will only make things more complicated. Best not worry about
that yet. Implementing this ext "properly" has some wrinkles: explain
them.

Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17948>

diff --git a/src/gallium/drivers/asahi/agx_pipe.c b/src/gallium/drivers/asahi/agx_pipe.c
index 32dcefd..7f3dd07 100644 (file)
--- a/src/gallium/drivers/asahi/agx_pipe.c
+++ b/src/gallium/drivers/asahi/agx_pipe.c
@@ -730,9 +730,24 @@ agx_get_param(struct pipe_screen* pscreen, enum pipe_cap param)
    case PIPE_CAP_MIXED_FRAMEBUFFER_SIZES:
    case PIPE_CAP_FRAGMENT_SHADER_DERIVATIVES:
    case PIPE_CAP_FRAMEBUFFER_NO_ATTACHMENT:
-   case PIPE_CAP_CLIP_HALFZ:
       return 1;
 
+   /* We could support ARB_clip_control by toggling the clip control bit for
+    * the render pass. Because this bit is for the whole render pass,
+    * switching clip modes necessarily incurs a flush. This should be ok, from
+    * the ARB_clip_control spec:
+    *
+    *         Some implementations may introduce a flush when changing the
+    *         clip control state.  Hence frequent clip control changes are
+    *         not recommended.
+    *
+    * However, this would require tuning to ensure we don't flush unnecessary
+    * when using u_blitter clears, for example. As we don't yet have a use case,
+    * don't expose the feature.
+    */
+   case PIPE_CAP_CLIP_HALFZ:
+      return 0;
+
    case PIPE_CAP_MAX_RENDER_TARGETS:
       return 1;