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