[Mesa-dev] [PATCH] st/mesa: expose EXT_framebuffer_multisample_blit_scaled if MSAA is supported

[Marek Olšák]

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 <greg at 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