<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 30, 2018 at 5:03 PM, Nanley Chery <span dir="ltr"><<a href="mailto:nanleychery@gmail.com" target="_blank">nanleychery@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Jan 30, 2018 at 04:25:59PM -0800, Jason Ekstrand wrote:<br>
> On Tue, Jan 30, 2018 at 2:54 PM, Nanley Chery <<a href="mailto:nanleychery@gmail.com">nanleychery@gmail.com</a>> wrote:<br>
><br>
> > On Fri, Jan 19, 2018 at 03:47:34PM -0800, Jason Ekstrand wrote:<br>
> > > Even though the blorp pass looks a bit on the sketchy side, the end<br>
> > > result in the Vulkan driver is very nice.  Instead of having this weird<br>
> > > case where you do a fast clear and then maybe have to resolve, we just<br>
> > > do the ambiguate and are done with it.  The ambiguate does exactly what<br>
> > > we want of setting all the CCS values to 0 which puts it inot the<br>
> >                                                            ^<br>
> >                                                            in<br>
<br>
</span>Typo.<br><div><div class="h5"></div></div></blockquote><div><br></div><div>Yup.  Meant into<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
> > > pass-through state.<br>
> > ><br>
> > > This should also improve performance a bit in certain cases.  For<br>
> > > instance, if we did a transition from UNDEFINED to GENERAL for a surface<br>
> > > that doesn't have CCS enabled all the time, we would end up doing a<br>
> > > fast-clear and then a full resolve which ends up touching every byte in<br>
> > > the main surface as well as the CCS.  With the ambiguate pass, that<br>
> > > transition only touches the CCS.<br>
> > > ---<br>
> > >  src/intel/vulkan/anv_blorp.c       |  5 ++++<br>
> > >  src/intel/vulkan/genX_cmd_<wbr>buffer.c | 54 +++++++++---------------------<br>
> > --------<br>
> > >  2 files changed, 17 insertions(+), 42 deletions(-)<br>
> > ><br>
> > > diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c<br>
> > > index 05efc6d..3698543 100644<br>
> > > --- a/src/intel/vulkan/anv_blorp.c<br>
> > > +++ b/src/intel/vulkan/anv_blorp.c<br>
> > > @@ -1792,6 +1792,11 @@ anv_image_ccs_op(struct anv_cmd_buffer<br>
> > *cmd_buffer,<br>
> > >                          surf.surf->format, isl_to_blorp_fast_clear_op(<br>
> > ccs_op));<br>
> > >        break;<br>
> > >     case ISL_AUX_OP_AMBIGUATE:<br>
> > > +      for (uint32_t a = 0; a < layer_count; a++) {<br>
> > > +         const uint32_t layer = base_layer + a;<br>
> > > +         blorp_ccs_ambiguate(&batch, &surf, level, layer);<br>
> > > +      }<br>
> > > +      break;<br>
> > >     default:<br>
> > >        unreachable("Unsupported CCS operation");<br>
> > >     }<br>
> > > diff --git a/src/intel/vulkan/genX_cmd_<wbr>buffer.c<br>
> > b/src/intel/vulkan/genX_cmd_<wbr>buffer.c<br>
> > > index 77fdadf..9e2eba3 100644<br>
> > > --- a/src/intel/vulkan/genX_cmd_<wbr>buffer.c<br>
> > > +++ b/src/intel/vulkan/genX_cmd_<wbr>buffer.c<br>
> > > @@ -486,15 +486,6 @@ init_fast_clear_state_entry(<wbr>struct anv_cmd_buffer<br>
> > *cmd_buffer,<br>
> > >     uint32_t plane = anv_image_aspect_to_plane(<wbr>image->aspects, aspect);<br>
> > >     enum isl_aux_usage aux_usage = image->planes[plane].aux_<wbr>usage;<br>
> > ><br>
> > > -   /* The resolve flag should updated to signify that<br>
> > fast-clear/compression<br>
> > > -    * data needs to be removed when leaving the undefined layout. Such<br>
> > data<br>
> > > -    * may need to be removed if it would cause accesses to the color<br>
> > buffer<br>
> > > -    * to return incorrect data. The fast clear data in CCS_D buffers<br>
> > should<br>
> > > -    * be removed because CCS_D isn't enabled all the time.<br>
> > > -    */<br>
> > > -   genX(set_image_needs_resolve)(<wbr>cmd_buffer, image, aspect, level,<br>
> > > -                                 aux_usage == ISL_AUX_USAGE_NONE);<br>
> > > -<br>
> > >     /* The fast clear value dword(s) will be copied into a surface state<br>
> > object.<br>
> > >      * Ensure that the restrictions of the fields in the dword(s) are<br>
> > followed.<br>
> > >      *<br>
> > > @@ -677,10 +668,9 @@ transition_color_buffer(struct anv_cmd_buffer<br>
> > *cmd_buffer,<br>
> > >        for (unsigned level = base_level; level < last_level_num; level++)<br>
> > >           init_fast_clear_state_entry(<wbr>cmd_buffer, image, aspect, level);<br>
> > ><br>
> > > -      /* Initialize the aux buffers to enable correct rendering. This<br>
> > operation<br>
> > > -       * requires up to two steps: one to rid the aux buffer of data<br>
> > that may<br>
> > > -       * cause GPU hangs, and another to ensure that writes done<br>
> > without aux<br>
> > > -       * will be visible to reads done with aux.<br>
> > > +      /* Initialize the aux buffers to enable correct rendering.  In<br>
> > order to<br>
> > > +       * ensure that things such as storage images work correctly, aux<br>
> > buffers<br>
> > > +       * are initialized to the pass-through state.<br>
> ><br>
> > Only CCS is initialized to the pass-through state while MCS is<br>
> > fast-cleared. We may also want to update the comment below since we're<br>
> > no longer fast-clearing CCS.<br>
> ><br>
><br>
> Right.  I've replaced this entire comment with:<br>
><br>
>       /* Initialize the aux buffers to enable correct rendering.  In order<br>
> to<br>
>        * ensure that things such as storage images work correctly, aux<br>
> buffers<br>
>        * need to be initialized to valid data.<br>
>        *<br>
>        * Having an aux buffer with invalid data is a problem for two<br>
> reasons:<br>
>        *<br>
>        *  1) Having an invalid value in the buffer can confuse the hardware.<br>
>        *     For instance, with CCS_E on SKL, a two-bit CCS value of 2 is<br>
>        *     invalid and leads to the hardware doing strange things.  It<br>
>        *     doesn't hang as far as we can tell but rendering corruption can<br>
>        *     occur.<br>
>        *<br>
>        *  2) If this transition is into the GENERAL layout and we then use<br>
> the<br>
>        *     image as a storage image, then we must have the aux buffer in<br>
> the<br>
>        *     pass-through state so that, if we then go to texture from the<br>
>        *     image, we get the results of our storage image writes and not<br>
> the<br>
>        *     fast clear color or other random data.<br>
<br>
</div></div>This reads better. Is 2) an actual issue? When we create surface states<br>
for storage images, we set the aux_usage to NONE.<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>Yes.  If you do UNDEFINED -> GENERAL -> use for storage -> RENDER_OPTIMAL + LOAD_OP_LOAD -> draw to part of it -> TEXTURE_OPTIMAL.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
- Nanley<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
>        *<br>
>        * For CCS both of the problems above are real demonstrable issues.<br>
> In<br>
>        * that case, the only thing we can do is to perform an ambiguate to<br>
>        * transition the aux surface into the pass-through state.<br>
>        *<br>
>        * For MCS, (2) is never an issue because we don't support<br>
> multisampled<br>
>        * storage images.  In theory, issue (1) is a problem with MCS but<br>
> we've<br>
>        * never seen it in the wild.  For 4x and 16x, all bit patters could,<br>
> in<br>
>        * theory, be interpreted as something but we don't know that all bit<br>
>        * patterns are actually valid.  For 2x and 8x, you could easily end<br>
> up<br>
>        * with the MCS referring to an invalid plane because not all bits of<br>
>        * the MCS value are actually used.  Even though we've never seen<br>
> issues<br>
>        * in the wild, it's best to play it safe and initialize the MCS.  We<br>
>        * can use a fast-clear for MCS because we only ever touch from render<br>
>        * and texture (no image load store).<br>
>        */<br>
><br>
> >         *<br>
> > >         * Having an aux buffer with invalid data is possible for CCS<br>
> > buffers<br>
> > >         * SKL+ and for MCS buffers with certain sample counts (2x and<br>
> > 8x). One<br>
> > > @@ -692,16 +682,18 @@ transition_color_buffer(struct anv_cmd_buffer<br>
> > *cmd_buffer,<br>
> > >         * We don't have any data to show that this is a problem, but we<br>
> > want to<br>
> > >         * avoid causing difficult-to-debug problems.<br>
> > >         */<br>
> > > -      if (GEN_GEN >= 9 && image->samples == 1) {<br>
> > > +      if (image->samples == 1) {<br>
> > >           for (uint32_t l = 0; l < level_count; l++) {<br>
> > >              const uint32_t level = base_level + l;<br>
> > >              const uint32_t level_layer_count =<br>
> > >                 MIN2(layer_count, anv_image_aux_layers(image, aspect,<br>
> > level));<br>
> > >              anv_image_ccs_op(cmd_buffer, image, aspect, level,<br>
> > >                               base_layer, level_layer_count,<br>
> > > -                             ISL_AUX_OP_FAST_CLEAR, false);<br>
> > > +                             ISL_AUX_OP_AMBIGUATE, false);<br>
> > > +            genX(set_image_needs_resolve)(<wbr>cmd_buffer, image,<br>
> > > +                                          aspect, level, false);<br>
> > >           }<br>
> > > -      } else if (image->samples > 1) {<br>
> > > +      } else {<br>
> > >           if (image->samples == 4 || image->samples == 16) {<br>
> > >              anv_perf_warn(cmd_buffer-><wbr>device->instance, image,<br>
> > >                            "Doing a potentially unnecessary fast-clear<br>
> > to "<br>
> > > @@ -712,32 +704,10 @@ transition_color_buffer(struct anv_cmd_buffer<br>
> > *cmd_buffer,<br>
> > >           anv_image_mcs_op(cmd_buffer, image, aspect,<br>
> > >                            base_layer, layer_count,<br>
> > >                            ISL_AUX_OP_FAST_CLEAR, false);<br>
> > > -      }<br>
> > > -      /* At this point, some elements of the CCS buffer may have the<br>
> > fast-clear<br>
> > > -       * bit-arrangement. As the user writes to a subresource, we need<br>
> > to have<br>
> > > -       * the associated CCS elements enter the ambiguated state. This<br>
> > enables<br>
> > > -       * reads (implicit or explicit) to reflect the user-written data<br>
> > instead<br>
> > > -       * of the clear color. The only time such elements will not<br>
> > change their<br>
> > > -       * state as described above, is in a final layout that doesn't<br>
> > have CCS<br>
> > > -       * enabled. In this case, we must force the associated CCS<br>
> > buffers of the<br>
> > > -       * specified range to enter the ambiguated state in advance.<br>
> > > -       */<br>
> > > -      if (image->samples == 1 &&<br>
> > > -          image->planes[plane].aux_usage != ISL_AUX_USAGE_CCS_E &&<br>
> > > -          final_layout != VK_IMAGE_LAYOUT_COLOR_<wbr>ATTACHMENT_OPTIMAL) {<br>
> > > -         /* The CCS_D buffer may not be enabled in the final layout.<br>
> > Call this<br>
> > > -          * function again with a initial layout of<br>
> > COLOR_ATTACHMENT_OPTIMAL<br>
> > > -          * to perform a resolve.<br>
> > > -          */<br>
> > > -          anv_perf_warn(cmd_buffer-><wbr>device->instance, image,<br>
> > > -                        "Performing an additional resolve for CCS_D<br>
> > layout "<br>
> > > -                        "transition. Consider always leaving it on or "<br>
> > > -                        "performing an ambiguation pass.");<br>
> > > -         transition_color_buffer(cmd_<wbr>buffer, image, aspect,<br>
> > > -                                 base_level, level_count,<br>
> > > -                                 base_layer, layer_count,<br>
> > > -                                 VK_IMAGE_LAYOUT_COLOR_<br>
> > ATTACHMENT_OPTIMAL,<br>
> > > -                                 final_layout);<br>
> ><br>
> > Nice to be rid of this.<br>
> ><br>
><br>
> Yup.<br>
><br>
><br>
> > > +         for (unsigned level = base_level; level < last_level_num;<br>
> > level++) {<br>
> > > +            genX(set_image_needs_resolve)(<wbr>cmd_buffer, image,<br>
> > > +                                          aspect, level, true);<br>
> > > +         }<br>
> ><br>
> > Why set needs resolve true here?<br>
> ><br>
><br>
> There's no particularly good reason.  I'll delete it.  We never do MCS<br>
> resolves anyway.  When the time comes for me to go hook up MCS fast-clears<br>
> again, we can sort it out then.<br>
</div></div></blockquote></div><br></div></div>