On Wed, Jan 11, 2017 at 5:55 PM, Nanley Chery <[email protected]> wrote:
> Signed-off-by: Nanley Chery <[email protected]> > --- > src/intel/vulkan/anv_blorp.c | 9 +++++++-- > src/intel/vulkan/anv_private.h | 15 +++++++++++++++ > src/intel/vulkan/genX_cmd_buffer.c | 5 +---- > 3 files changed, 23 insertions(+), 6 deletions(-) > > diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c > index 433e82f938..9919ac7ea0 100644 > --- a/src/intel/vulkan/anv_blorp.c > +++ b/src/intel/vulkan/anv_blorp.c > @@ -1264,6 +1264,12 @@ anv_cmd_buffer_clear_subpass(struct anv_cmd_buffer > *cmd_buffer) > render_area.offset.y + > render_area.extent.height)) { > clear_with_hiz = false; > + } else if (clear_att.clearValue.depthStencil.depth != > + ANV_HZ_FC_VAL) { > + /* Don't enable fast depth clears for any color not equal > to > + * ANV_HZ_FC_VAL. > + */ > + clear_with_hiz = false; > } > } > > @@ -1626,8 +1632,7 @@ anv_gen8_hiz_op_resolve(struct anv_cmd_buffer > *cmd_buffer, > struct blorp_surf surf; > get_blorp_surf_for_anv_image(image, VK_IMAGE_ASPECT_DEPTH_BIT, > ISL_AUX_USAGE_HIZ, &surf); > - surf.clear_color.u32[0] = (uint32_t) > - cmd_state->attachments[ds].clear_value.depthStencil.depth; > + surf.clear_color.u32[0] = (uint32_t) ANV_HZ_FC_VAL; > Ugh... We should really fix this ugly corner of blorp. > > blorp_gen6_hiz_op(&batch, &surf, 0, 0, op); > blorp_batch_finish(&batch); > diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_ > private.h > index 237308fb3e..98692b5913 100644 > --- a/src/intel/vulkan/anv_private.h > +++ b/src/intel/vulkan/anv_private.h > @@ -72,6 +72,21 @@ struct gen_l3_config; > extern "C" { > #endif > > +/* Allowing different clear colors requires us to perform a depth resolve > at > + * the end of certain render passes. This is because while slow clears > store > + * the clear color in the HiZ buffer, fast clears (without a resolve) > don't. > + * See the PRMs for examples describing when additional resolves would be > + * necessary. To enable fast clears without requiring extra resolves, we > set > + * the clear value to a globally-defined one. We could allow different > values > + * if the user doesn't expect coherent data during or after a render > passes > + * (VK_ATTACHMENT_STORE_OP_DONT_CARE), but such users (aside from the > CTS) > + * don't seem to exist yet. In almost all Vulkan applications tested thus > far, > + * 1.0f seems to be the only value used. The only application that > doesn't set > + * this value does so through the usage of an seemingly uninitialized > clear > + * value. > + */ > +#define ANV_HZ_FC_VAL 1.0f > + > #define MAX_VBS 32 > #define MAX_SETS 8 > #define MAX_RTS 8 > diff --git a/src/intel/vulkan/genX_cmd_buffer.c > b/src/intel/vulkan/genX_cmd_buffer.c > index 95d0cfc983..baa932e517 100644 > --- a/src/intel/vulkan/genX_cmd_buffer.c > +++ b/src/intel/vulkan/genX_cmd_buffer.c > @@ -2283,10 +2283,7 @@ cmd_buffer_emit_depth_stencil(struct > anv_cmd_buffer *cmd_buffer) > anv_batch_emit(&cmd_buffer->batch, GENX(3DSTATE_CLEAR_PARAMS), cp) { > if (has_hiz) { > cp.DepthClearValueValid = true; > - const uint32_t ds = > - cmd_buffer->state.subpass->depth_stencil_attachment; > - cp.DepthClearValue = > - cmd_buffer->state.attachments[ds].clear_value.depthStencil. > depth; > + cp.DepthClearValue = ANV_HZ_FC_VAL; > } > } > } > -- > 2.11.0 > > _______________________________________________ > mesa-dev mailing list > [email protected] > https://lists.freedesktop.org/mailman/listinfo/mesa-dev >
_______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
