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

[Christoph Bumiller]

On 17.07.2013 00:12, Grigori Goronzy 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.
>

You can implement arbitrary filters for resolve since you're doing it
manually using texelFetch from a shader anyway, so yes you can make it
faster (for depth/stencil resolve this is trivial), or at least leave
that option open, while if GL apps do it manually you can't do anything
about it.

NV50/NVC0 just use a single plain old scaled blit for resolve because a
multisample texture's samples are all adjacent in 2D coordinate space,
it's no different from downscaling a larger texture, so there it's
always going to be faster.
Granted, it might look ugly if I can't find a fitting filtering mode,
but I'll just ignore that until I see some application using it that
relies on SCALED_RESOLVE_NICEST_EXT looking decent.

> Grigori
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>