[Mesa-dev] [PATCH] anv/blorp: sample input attachments with resolves on BDW

[Samuel Iglesias Gonsálvez]

On Tue, 2017-03-21 at 16:34 +0100, Samuel Iglesias Gonsálvez wrote:
> 
> On 21/03/17 16:14, Jason Ekstrand wrote:
> > On Tue, Mar 21, 2017 at 7:23 AM, Samuel Iglesias Gonsálvez
> > <siglesias at igalia.com <mailto:siglesias at igalia.com>> wrote:
> > 
> >     Input attachments are clear-color aware on Sky Lake, so we
> >     can frequently sample from them with no resolves at all.
> > However
> >     on Broadwell we still need to do a a resolve between the
> > subpass
> >     that writes and the subpass that reads.
> > 
> > 
> > In theory, we shouldn't always need to do a resolve.  Broadwell is
> > supposed (maybe it doesn't work?) to support sampling from fast-
> > cleared
> > buffers and I thought it was hooked up correctly.  Is this only an
> > issue
> > for certain clear colors?  I have a feeling there's something more
> > subtle going on here.
> >  
> 
> OK, I will investigate further.
> 

The value of the clear colors is irrelevant except if the image's clear
color is the same than attachment's clear color, probably
because sampling from fast-cleared buffers is not working and it has
already the clear color it expects. Once they are different, the tests
always fail.

However, I think I have found something:

According to BDW PRM, vol02d, RenderSurface::Auxiliary Surface Mode,
the only available values are  AUX_NONE (0x0), AUX_MCS (0x1),
AUX_APPEND (0x2), AUX_HIZ (0x3), the rest are reserved.

AUX_MCS is only if the Auxiliary surface is an MCS (Multisample Control
Surface). This is different in gen9+: set the mode to AUX_CCS_D (0x1)
when the Auxiliary surface is a CCS (Color Control Surface) with
compression disabled or an MCS with compression enabled, depending on
Number of Multisamples.

Inside color_attachment_compute_aux_usage() we are setting both aux
surface usage and input aux usage to ISL_AUX_USAGE_CCS_D for BDW, but I
think we need to do it only if it is a MCS (maybe set both to
ISL_AUX_USAGE_MCS would be better?) and, if not, set the latter to
ISL_AUX_USAGE_NONE in order to force the resolve in
ccs_resolve_attachment() (see the first else-if of this patch). 

What do you think?

Sam

> 
> > 
> >     Fixes 16 tests on BDW:
> > 
> >     dEQP-VK.renderpass.formats.*.input.clear.store.self_dep*
> > 
> >     Signed-off-by: Samuel Iglesias Gonsálvez <siglesias at igalia.com
> >     <mailto:siglesias at igalia.com>>
> >     ---
> >      src/intel/vulkan/anv_blorp.c | 9 ++++++---
> >      1 file changed, 6 insertions(+), 3 deletions(-)
> > 
> >     diff --git a/src/intel/vulkan/anv_blorp.c
> > b/src/intel/vulkan/anv_blorp.c
> >     index 1f4fec5f35b..2fa56f49d18 100644
> >     --- a/src/intel/vulkan/anv_blorp.c
> >     +++ b/src/intel/vulkan/anv_blorp.c
> >     @@ -1504,10 +1504,13 @@ ccs_resolve_attachment(struct
> > anv_cmd_buffer
> >     *cmd_buffer,
> >                */
> >            }
> >         } else if (usage & ANV_SUBPASS_USAGE_INPUT) {
> >     -      /* Input attachments are clear-color aware so, at least
> > on
> >     Sky Lake, we
> >     -       * can frequently sample from them with no resolves at
> > all.
> >     +      /* Input attachments are clear-color aware on Sky Lake,
> > so we
> >     +       * can frequently sample from them with no resolves at
> > all.
> >     However
> >     +       * on Broadwell we still need to do resolves.
> >             */
> >     -      if (att_state->aux_usage != att_state->input_aux_usage)
> > {
> >     +      if (cmd_buffer->device->info.gen < 9) {
> >     +         resolve_op = BLORP_FAST_CLEAR_OP_RESOLVE_FULL;
> >     +      } else if (att_state->aux_usage != att_state-
> > >input_aux_usage) {
> >               assert(att_state->input_aux_usage ==
> > ISL_AUX_USAGE_NONE);
> >               resolve_op = BLORP_FAST_CLEAR_OP_RESOLVE_FULL;
> >            } else if (!att_state->clear_color_is_zero_one) {
> >     --
> >     2.11.0
> > 
> > 
> 
> 
-------------- 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/20170322/147b72e9/attachment.sig>