[Mesa-dev] [PATCH] RFC: Workaround for gen9 hw astc5x5 sampler bug

[Rogovin, Kevin]

Hi,

>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).