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

[Christoph Bumiller]

On 17.07.2013 02:05, Marek Olšák wrote:
> 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.

It can also take 8 samples per-pixel or MS8 resolve wouldn't be
possible, so scaling down MS2 should look OK at least.
The arrangement of the samples in the texture is ordered according to
the physical sample locations (of course the proportions don't match).

Besides, it's allowed to look horrible, it only requires "a 4-tap linear
filter", and depth resolve, should anyone actually do that, uses
point/nearest filtering so you can always do it in one pass.
Also, it's possible this extension isn't even intended to resolve for
direct display.

There's one advantage in having the app do it though, you don't have to
worry about keeping a temporary surface of an appropriate size around.

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