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 > > <[email protected] <mailto:[email protected]>> 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 <[email protected] > > <mailto:[email protected]>> > > --- > > 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 > > > > > >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
