On Tue, Dec 5, 2017 at 10:34 AM, Rogovin, Kevin <kevin.rogo...@intel.com> wrote:
> 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. > I'd have to think about it harder but even those are not likely to actually get ASTC decode. Maybe for some sort of decompression thing but if you're doing GetCompressedTexImage, it'll probably turn into a blorp_copy which will use R32G32B32A32_UINT. > > 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 mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
