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). _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
