No, it's not faster, but it's not slower either. Now that I think about it, I can't come up with a good shader-based algorithm for the resolve operation.
I don't think Christoph's approach that an MSAA texture can be viewed as a larger single-sample texture is correct, because the physical locations of the samples in memory usually do not correspond to the sample locations the 3D engine used for rasterization. so fetching a texel from the larger texture at (x,y) physical coordinates won't always return the closest rasterized sample at those coordinates. Also the bilinear filter would be horrible in this case, because it only takes 4 samples per pixel. Now let's consider implementing the scaled resolve operation in the shader by texelFetch-ing all samples and using a bilinear filter. For Nx MSAA, there would be N*4 texel fetches per pixel; in comparison, separate resolve+blit needs only N+4 texel fetches per pixel. In addition to that, the resolve is a special fixed-function blending operation and the fragment shader is not even executed. See? Separate resolve+blit beats everything. Marek On Wed, Jul 17, 2013 at 12:12 AM, Grigori Goronzy <g...@chown.ath.cx> wrote: > On 16.07.2013 19:26, Marek Olšák wrote: >> >> Surprisingly all drivers supporting MSAA can already do this (r300g and >> r600g >> for sure) and I think Christoph wanted to have this feature for his >> Nouveau >> drivers anyway. > > > OK, they can do it, but is it actually any faster than doing a resolve and > regular blit afterwards? This is kind of the point of this extension. r600g > creates a temporary texture to resolve into and then blits that, which > shouldn't be any faster than doing the same from GL. > > Grigori _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
