[Mesa-dev] [PATCH 08/22] anv/cmd_buffer: Always enable CCS_D in render passes
Jason Ekstrand
jason at jlekstrand.net
Tue May 2 23:38:01 UTC 2017
On Tue, May 2, 2017 at 4:28 PM, Nanley Chery <nanleychery at gmail.com> wrote:
> On Tue, May 02, 2017 at 04:15:42PM -0700, Jason Ekstrand wrote:
> > On Thu, Apr 27, 2017 at 11:32 AM, Nanley Chery <nanleychery at gmail.com>
> > wrote:
> >
> > > The lifespan of the fast-clear data will surpass the render pass scope.
> > > We need CCS_D to be enabled in order to invalidate blocks previously
> > > marked as cleared and to sample cleared data correctly.
> > >
> > > Signed-off-by: Nanley Chery <nanley.g.chery at intel.com>
> > > ---
> > > src/intel/vulkan/anv_blorp.c | 15 ++----
> > > src/intel/vulkan/genX_cmd_buffer.c | 94
> +++++++++++++++++++-----------
> > > --------
> > > 2 files changed, 52 insertions(+), 57 deletions(-)
> > >
> > > diff --git a/src/intel/vulkan/anv_blorp.c
> b/src/intel/vulkan/anv_blorp.c
> > > index d17b73dcc7..5e7d4b06b8 100644
> > > --- a/src/intel/vulkan/anv_blorp.c
> > > +++ b/src/intel/vulkan/anv_blorp.c
> > > @@ -1383,7 +1383,8 @@ ccs_resolve_attachment(struct anv_cmd_buffer
> > > *cmd_buffer,
> > > &cmd_buffer->state.attachments[att];
> > >
> > > if (att_state->aux_usage == ISL_AUX_USAGE_NONE ||
> > > - att_state->aux_usage == ISL_AUX_USAGE_MCS)
> > > + att_state->aux_usage == ISL_AUX_USAGE_MCS ||
> > > + att_state->fast_clear == false)
> > > return; /* Nothing to resolve */
> > >
> > > assert(att_state->aux_usage == ISL_AUX_USAGE_CCS_E ||
> > > @@ -1432,7 +1433,7 @@ ccs_resolve_attachment(struct anv_cmd_buffer
> > > *cmd_buffer,
> > > * the render pass. We need a full resolve.
> > > */
> > > resolve_op = BLORP_FAST_CLEAR_OP_RESOLVE_FULL;
> > > - } else if (att_state->fast_clear) {
> > > + } else {
> > > /* We don't know what to do with clear colors outside the
> render
> > > * pass. We need a partial resolve. Only transparent black
> is
> > > * built into the surface state object and thus no resolve is
> > > @@ -1443,11 +1444,6 @@ ccs_resolve_attachment(struct anv_cmd_buffer
> > > *cmd_buffer,
> > > att_state->clear_value.color.uint32[2] ||
> > > att_state->clear_value.color.uint32[3])
> > > resolve_op = BLORP_FAST_CLEAR_OP_RESOLVE_PARTIAL;
> > > - } else {
> > > - /* The image "natively" supports all the compression we care
> > > about
> > > - * and we don't need to resolve at all. If this is the
> case, we
> > > also
> > > - * don't need to resolve for any of the input attachment
> cases
> > > below.
> > > - */
> > > }
> > > } else if (usage & ANV_SUBPASS_USAGE_INPUT) {
> > > /* Input attachments are clear-color aware so, at least on Sky
> > > Lake, we
> > > @@ -1474,8 +1470,7 @@ ccs_resolve_attachment(struct anv_cmd_buffer
> > > *cmd_buffer,
> > > struct blorp_surf surf;
> > > get_blorp_surf_for_anv_image(image, VK_IMAGE_ASPECT_COLOR_BIT,
> > > att_state->aux_usage, &surf);
> > > - if (att_state->fast_clear)
> > > - surf.clear_color = vk_to_isl_color(att_state->
> clear_value.color);
> > > + surf.clear_color = vk_to_isl_color(att_state->clear_value.color);
> > >
> > > /* From the Sky Lake PRM Vol. 7, "Render Target Resolve":
> > > *
> > > @@ -1504,8 +1499,6 @@ ccs_resolve_attachment(struct anv_cmd_buffer
> > > *cmd_buffer,
> > >
> > > /* Once we've done any sort of resolve, we're no longer
> fast-cleared */
> > > att_state->fast_clear = false;
> > > - if (att_state->aux_usage == ISL_AUX_USAGE_CCS_D)
> > > - att_state->aux_usage = ISL_AUX_USAGE_NONE;
> > > }
> > >
> > > void
> > > diff --git a/src/intel/vulkan/genX_cmd_buffer.c
> > > b/src/intel/vulkan/genX_cmd_buffer.c
> > > index ddb22c4539..0ea378fde2 100644
> > > --- a/src/intel/vulkan/genX_cmd_buffer.c
> > > +++ b/src/intel/vulkan/genX_cmd_buffer.c
> > > @@ -232,6 +232,50 @@ color_attachment_compute_aux_usage(struct
> anv_device
> > > *device,
> > > att_state->input_aux_usage = ISL_AUX_USAGE_MCS;
> > > att_state->fast_clear = false;
> > > return;
> > > + } else if (GEN_GEN == 7 &&
> > > + (iview->isl.base_level > 0 ||
> > > + iview->isl.base_array_layer > 0 ||
> > > + iview->isl.array_len > 1)) {
> > > + /* On gen7, we can't do multi-LOD or multi-layer CCS. We
> technically
> > > + * can, but it comes with crazy restrictions that we don't want
> to
> > > deal
> > > + * with now.
> > > + */
> > > + att_state->aux_usage = ISL_AUX_USAGE_NONE;
> > > + att_state->input_aux_usage = ISL_AUX_USAGE_NONE;
> > > + att_state->fast_clear = false;
> > > + return;
> > > + } else if (iview->image->aux_usage == ISL_AUX_USAGE_CCS_E) {
> > > + att_state->aux_usage = ISL_AUX_USAGE_CCS_E;
> > > + att_state->input_aux_usage = ISL_AUX_USAGE_CCS_E;
> > > + } else {
> > > + att_state->aux_usage = ISL_AUX_USAGE_CCS_D;
> > > + if (isl_format_supports_ccs_e(&device->info,
> iview->isl.format)) {
> > > + /* SKL can sample from CCS with one restriction.
> > > + *
> > > + * From the Sky Lake PRM, RENDER_SURFACE_STATE::
> > > AuxiliarySurfaceMode:
> > > + *
> > > + * "If Number of Multisamples is MULTISAMPLECOUNT_1,
> AUX_CCS_D
> > > + * setting is only allowed if Surface Format supported for
> > > Fast
> > > + * Clear. In addition, if the surface is bound to the
> sampling
> > > + * engine, Surface Format must be supported for Render
> Target
> > > + * Compression for surfaces bound to the sampling engine."
> > > + *
> > > + * In other words, we can only sample from a fast-cleared
> image
> > > if it
> > > + * also supports color compression.
> > > + *
> > > + * TODO: Consider using a heuristic to determine if
> temporarily
> > > enabling
> > > + * CCS_E for this image view would be beneficial.
> > > + *
> > > + * While fast-clear resolves and partial resolves are fairly
> > > cheap in the
> > > + * case where you render to most of the pixels, full resolves
> > > are not
> > > + * because they potentially involve reading and writing the
> > > entire
> > > + * framebuffer. If we can't texture with CCS_E, we should
> leave
> > > it off and
> > > + * limit ourselves to fast clears.
> > > + */
> > > + att_state->input_aux_usage = ISL_AUX_USAGE_CCS_D;
> > > + } else {
> > > + att_state->input_aux_usage = ISL_AUX_USAGE_NONE;
> > > + }
> > >
> >
> > Is this refactor needed? I don't see how this code does anything
> different
> > from what we had before.
> >
> >
>
> Prior to this patch CCS_D would only enabled if a fast clear would occur
> on the attachment. With this patch, CCS_D is always enabled regardless
> of whether a fast clear operation is performed.
>
I think I see it now. It's a bit hard to see the delta with all of the
code moving around everywhere.
> -Nanley
>
> > > }
> > >
> > > assert(iview->image->aux_surface.isl.usage &
> ISL_SURF_USAGE_CCS_BIT);
> > > @@ -240,6 +284,10 @@ color_attachment_compute_aux_usage(struct
> anv_device
> > > *device,
> > > color_is_zero_one(att_state->clear_value.color,
> iview->isl.format);
> > >
> > > if (att_state->pending_clear_aspects ==
> VK_IMAGE_ASPECT_COLOR_BIT) {
> > > +
> > > + /* We should have returned early if the aux buffer will not be
> > > used. */
> > > + assert(att_state->aux_usage != ISL_AUX_USAGE_NONE);
> > > +
> > > /* Start off assuming fast clears are possible */
> > > att_state->fast_clear = true;
> > >
> > > @@ -253,17 +301,6 @@ color_attachment_compute_aux_usage(struct
> anv_device
> > > *device,
> > > render_area.extent.height != iview->extent.height)
> > > att_state->fast_clear = false;
> > >
> > > - if (GEN_GEN <= 7) {
> > > - /* On gen7, we can't do multi-LOD or multi-layer
> fast-clears. We
> > > - * technically can, but it comes with crazy restrictions
> that we
> > > - * don't want to deal with now.
> > > - */
> > > - if (iview->isl.base_level > 0 ||
> > > - iview->isl.base_array_layer > 0 ||
> > > - iview->isl.array_len > 1)
> > > - att_state->fast_clear = false;
> > > - }
> > > -
> > > /* On Broadwell and earlier, we can only handle 0/1 clear
> colors */
> > > if (GEN_GEN <= 8 && !att_state->clear_color_is_zero_one)
> > > att_state->fast_clear = false;
> > > @@ -275,41 +312,6 @@ color_attachment_compute_aux_usage(struct
> anv_device
> > > *device,
> > > } else {
> > > att_state->fast_clear = false;
> > > }
> > > -
> > > - /**
> > > - * TODO: Consider using a heuristic to determine if temporarily
> > > enabling
> > > - * CCS_E for this image view would be beneficial.
> > > - *
> > > - * While fast-clear resolves and partial resolves are fairly cheap
> in
> > > the
> > > - * case where you render to most of the pixels, full resolves are
> not
> > > - * because they potentially involve reading and writing the entire
> > > - * framebuffer. If we can't texture with CCS_E, we should leave it
> > > off and
> > > - * limit ourselves to fast clears.
> > > - */
> > > - if (iview->image->aux_usage == ISL_AUX_USAGE_CCS_E) {
> > > - att_state->aux_usage = ISL_AUX_USAGE_CCS_E;
> > > - att_state->input_aux_usage = ISL_AUX_USAGE_CCS_E;
> > > - } else if (att_state->fast_clear) {
> > > - att_state->aux_usage = ISL_AUX_USAGE_CCS_D;
> > > - /* From the Sky Lake PRM, RENDER_SURFACE_STATE::
> > > AuxiliarySurfaceMode:
> > > - *
> > > - * "If Number of Multisamples is MULTISAMPLECOUNT_1,
> AUX_CCS_D
> > > - * setting is only allowed if Surface Format supported for
> Fast
> > > - * Clear. In addition, if the surface is bound to the
> sampling
> > > - * engine, Surface Format must be supported for Render Target
> > > - * Compression for surfaces bound to the sampling engine."
> > > - *
> > > - * In other words, we can only sample from a fast-cleared image
> if
> > > it
> > > - * also supports color compression.
> > > - */
> > > - if (isl_format_supports_ccs_e(&device->info,
> iview->isl.format))
> > > - att_state->input_aux_usage = ISL_AUX_USAGE_CCS_D;
> > > - else
> > > - att_state->input_aux_usage = ISL_AUX_USAGE_NONE;
> > > - } else {
> > > - att_state->aux_usage = ISL_AUX_USAGE_NONE;
> > > - att_state->input_aux_usage = ISL_AUX_USAGE_NONE;
> > > - }
> > > }
> > >
> > > static bool
> > > --
> > > 2.12.2
> > >
> > > _______________________________________________
> > > mesa-dev mailing list
> > > mesa-dev at lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170502/1f4cdc56/attachment-0001.html>
More information about the mesa-dev
mailing list