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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
