[Mesa-dev] [0.5/16] i965/blorp/gen9: Do not try deferred mcs allocation for CCS_E

[Kenneth Graunke]

On Monday, February 27, 2017 10:44:42 AM PDT Topi Pohjolainen wrote:
> For lossless compression mcs is always allocated when miptree
> itself is created. The deferred logic in blorp is only meant for
> CCS_D (single sample fast clear without compression).
> 
> In intel_miptree_supports_lossless_compressed() one makes a
> heuristic choice not to use compression for float types.
> Currently the deferred hook is also applied for gen9 and blorp
> clears therefore effectively revert the heuristic.
> 
> This also prevents blorp from wrongly falling to meta path
> when the deferred mcs allocation fails for x-tiled miptrees.
> 
> CC: Jason Ekstrand <jason at jlekstrand.net>
> CC: Ben Widawsky <ben at bwidawsk.net>
> Signed-off-by: Topi Pohjolainen <topi.pohjolainen at intel.com>
> ---
>  src/mesa/drivers/dri/i965/brw_blorp.c | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c b/src/mesa/drivers/dri/i965/brw_blorp.c
> index 52f85ff..032fd2c 100644
> --- a/src/mesa/drivers/dri/i965/brw_blorp.c
> +++ b/src/mesa/drivers/dri/i965/brw_blorp.c
> @@ -845,11 +845,14 @@ do_single_blorp_clear(struct brw_context *brw, struct gl_framebuffer *fb,
>           return true;
>  
>        /* If the MCS buffer hasn't been allocated yet, we need to allocate
> -       * it now.
> +       * it now. For SKL (that supports lossless compression) mcs is allocated
> +       * by the time the miptree is created. If it is omitted there, do not
> +       * try to allocate here.
>         */
>        if (!irb->mt->mcs_buf) {
> -         assert(!intel_miptree_is_lossless_compressed(brw, irb->mt));
> -         if (!intel_miptree_alloc_non_msrt_mcs(brw, irb->mt, false)) {
> +         if (brw->gen >= 9) {
> +             can_fast_clear = false;
> +         } else if (!intel_miptree_alloc_non_msrt_mcs(brw, irb->mt, false)) {
>              /* MCS allocation failed--probably this will only happen in
>               * out-of-memory conditions.  But in any case, try to recover
>               * by falling back to a non-blorp clear technique.
> 

I was a bit concerned that this might disable fast clears for formats
which can do CCS_D and not CCS_E, as you're using a simple gen >= 9
check rather than the checks we use when doing non-deferred allocation:

      const bool lossless_compression_disabled = INTEL_DEBUG & DEBUG_NO_RBC;
      const bool is_lossless_compressed =
         unlikely(!lossless_compression_disabled) &&
         brw->gen >= 9 && !mt->is_scanout &&
         intel_miptree_supports_lossless_compressed(brw, mt);

But I think we already don't do CCS_D fast clears - we only do them when
CCS_E (lossless compression) is supported.  So,

Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>

Rather than all the intel_miptree_supports_* stuff, it might be nice to
check all that on creation, and store flags for "CCS_E is possible",
"CCS_D is possible", etc.  We already have AUX_DISABLE_* flags, but I'm
not sure whether those have quite the same meaning...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170419/de568731/attachment.sig>