[Mesa-dev] [PATCH] RFC: Workaround for gen9 hw astc5x5 sampler bug
kevin.rogovin at intel.com
Tue Dec 5 18:34:42 UTC 2017
>This isn't true. 100% of the intel_mipmap_tree -> blorp_surf translations are handled by that function.
> It's a perfectly reasonable place to handle these things. It could also be handled in genX(blorp_exec) if that makes someone more comfortable.
This is where I placed the ASTC enumeration setting, in genX(blorp_exec). I added a boolean signaling if the caller to blorp believed it would sample from an ASTC, if it did it sets the enum as ASTC otherwise as AUX.
I confess I am not super familiar with blorp, but as far as I can tell, the only way for blorp to read an ASTC is for GetTexImage/GetTexSubImage since an ASTC surface cannot be used for an FBO.
> The problem is that a single invalidate doesn't actually cause a synchronization point in the rendering operation. All it does is torch the texture cache and it
> does so immediately and in parallel with currently active rendering. If you can't have ASTC5x5 in the texture cache with a CCS_E surface, then we need to
> do a CS stall to ensure that the previous draw is complete before we invalidate. Otherwise, if the draw with ASTC5x5 is still in-flight, the texture cache will
> immediately start to get populated with ASTC5x5 data again.
Ahh futz, I forget to add that stall.. by luck the guilty application worked anyways (when I first wrote the work I did intel_batchbuffer_flush() and relaxed it down to texture invalidate).
More information about the mesa-dev