mirror of https://gitlab.freedesktop.org/mesa/mesa
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>
This commit is contained in:
parent
5ead973824
commit
a6f88863f6
|
@ -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;
|
||||
|
||||
|
|
Loading…
Reference in New Issue