This is distinct between
ISL_AUX_USAGE_HIZ_CCS_WT is that, when the HiZ surface
operates in write-through mode which means that the HiZ surface is only
used for depth-testing acceleration and the CCS-compressed main surface
is always valid so we can texture from it.
Separating full HiZ from write-through mode at the isl_aux_usage level has a couple of advantages:
It's more explicit. Instead of write-through mode depending on the heuristic decision in
isl_surf_supports_hiz_ccs_wt, it's now something that's explicitly requested by the driver. This should be more robust than hoping
isl_surf_supports_hiz_ccs_wtalways returns the same thing every time. If someone (say BLORP) ever drops a usage flag on the isl_surf, there's a chance it could return a different value without us noticing leading to corruptions.
ISL_AUX_USAGE_HIZ_CCS_WTis it's own isl_aux_usage flag, we can say inside the driver that
HIZ_CCSdoes not support sampling but
HIZ_CCS_WTdoes. We can also pass
isl_surf_init_stateand it can do some validation for us beyond what we would be able to do if we conflate
In the future, we can add new heuristics to the driver which do things such as start all depth surfaces (regardless of usage flags) off in
HIZ_CCSand then do a full resolve and drop to
HIZ_CCS_WTthe first time it gets used by the sampler. This would potentially let us enable the faster
HIZ_CCSmode even in cases where it technically comes in through the API as a texture.
Ideally, I think we'd like to play with 3, but this series does not do that. This series should have no functional change for iris. My primary motivation here is that I think the new
ISL_AUX_USAGE makes more sense and would like to see it cleaned up before we implement HiZ+CCS for Vulkan.
The motivation for
ISL_AUX_USAGE_STC_CCS is that stencil CCS is slightly different from color CCS. Using a color CCS
resolve with stencil CCS doesn't do the right thing and you can't sample
from a stencil CCS image without the
DepthStencilResource bit set or you
will get the wrong data. Stencil CCS also has it's own rules such as it
doesn't support fast-clear and has no partial resolve. This seems to
indicate that it should probably be its own
isl_aux_usage. Now that
isl_aux_usage values is pretty cheap, let's split stencil CCS
out on its own.
The crowning patch of this MR changes the way we set the
DepthStencilResource bit in
RENDER_SURFACE_STATE to treat it as an extension of
AuxiliarySurfaceMode. This goes a bit outside of the way the docs are written but seems to be in better alignment with what the bit actually means in hardware.