[Mesa-dev] [PATCH 2/5] i965/gen8+: Don't upload the MCS buffer for single-sampled textures

[Pohjolainen, Topi]

On Thu, Nov 26, 2015 at 11:39:20AM +0100, Neil Roberts wrote:
> > On Thu, Nov 26, 2015 at 11:18:34AM +0200, Pohjolainen, Topi wrote:
> >> On Wed, Nov 25, 2015 at 11:01:18AM -0800, Ben Widawsky wrote:
> >> > On Wed, Nov 25, 2015 at 06:36:36PM +0100, Neil Roberts wrote:
> >> > > For single-sampled textures the MCS buffer is only used to implement
> >> > > fast clears. However the surface always needs to be resolved before
> >> > > being used as a texture anyway so the the MCS buffer doesn't actually
> >> > > achieve anything. This is important for Gen9 because in that case SRGB
> >> > 
> >> > I admit a good deal of ignorance, but why do we have to do a resolve before we
> >> > sample from it? I thought the whole point of the MCS was that we can sample from
> >> > it without a resolve.
> >> 
> >> This is my understanding also, I can't see much benefit from the fast clear
> >> if it would need to be anyway resolved before reading it using GPU (reading
> >> using CPU is then another story of course).
> >
> > I know we have this piece of text in bspec:
> >
> > "If the MCS is enabled on a non-multisampled render target, the render
> > target must be resolved before being used for other purposes (display,
> > texture, CPU lock)."
> >
> > But on the other hand the fact that surface state supports definition of fast
> > cleared MCS buffer even for sampler engine suggest that "texture" in that
> > sentence refers to something else than sampling. Not to mention that we
> > already sample fast cleared color buffers with current Mesa driver and seem
> > to have no problems with it.
> 
> The resolve needs to be done for single-sampled render targets but for
> multisample targets we can safely sample from the MCS buffer. The MCS
> (or CCS or whatever it should be called in this case) is still useful
> even if we have to resolve because it saves memory bandwidth during
> rendering. Eg, the initial clear writes less data because it only writes
> to the smaller MCS buffer and not the larger color buffer. Any blending
> operations during rendering can also read from the CCS instead of the
> color buffer. I guess the assumption is that the bandwidth savings
> during rendering outweigh the extra cost added by having to resolve it.
> 
> To be clear, this patch doesn't add the resolve step needed before
> texturing, nor does anything in the series. The resolve step is already
> done for all gens in intel_update_state. Look at the bit with the
> comment ???Resolve depth buffer and render cache of each enabled texture???.
> It calls intel_miptree_resolve_color which resolves the CCS buffer for
> each singled-sampled surface that is going to be used as a texture. The
> only change this patch makes it to not not even set the aux buffer in
> the texture surface state.

Right you are, my mistake, Mesa already does resolve them before sampling.
There is then a difference for me to handle when I'm implementing resolves
for the lossless compression - sampling engine understands aux buffers in that
case and therefore the resolve-logic for fast clears is too strict for it as
such.