intel/isl: Add a separate ISL_AUX_USAGE_HIZ_CCS_WT and ISL_AUX_USAGE_STC_CCS enums.

Faith Ekstrand requested to merge gfxstrand/mesa:review/isl-hiz-wt into master

This is distinct between ISL_AUX_USAGE_HIZ_CCS and 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:

  1. 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_wt always 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.

  2. Because ISL_AUX_USAGE_HIZ_CCS_WT is it's own isl_aux_usage flag, we can say inside the driver that HIZ_CCS does not support sampling but HIZ_CCS_WT does. We can also pass HIZ_CCS_WT to isl_surf_init_state and it can do some validation for us beyond what we would be able to do if we conflate HIZ_CCS_WT and CCS_E.

  3. 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_CCS and then do a full resolve and drop to HIZ_CCS_WT the first time it gets used by the sampler. This would potentially let us enable the faster HIZ_CCS mode 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 adding new 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.

Edited by Faith Ekstrand

Merge request reports