From a6f88863f616eadef462dde8a01ee665f1cf7639 Mon Sep 17 00:00:00 2001 From: Alyssa Rosenzweig Date: Sun, 7 Aug 2022 19:27:06 -0400 Subject: [PATCH] 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 Part-of: --- src/gallium/drivers/asahi/agx_pipe.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/asahi/agx_pipe.c b/src/gallium/drivers/asahi/agx_pipe.c index 32dcefd7c68..7f3dd07e498 100644 --- 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;