[Mesa-dev] RFC: gallium-msaa branch merge

[Roland Scheidegger]

On 22.05.2010 00:53, José Fonseca wrote:
> On Tue, 2010-05-18 at 10:04 -0700, Roland Scheidegger wrote:
>> Hi,
>>
>> I plan to merge the gallium-msaa branch to master soon.
>> It's actually a bit of a misnomer since the conceptually more important
>> changes in there are about blits...
>>
>> Here's a short summary what this is about:
>> blits now operate on resources, not surfaces (surface_copy/fill ->
>> resource_copy/fill_region). Note that overlapping blits are no longer
>> permitted (half the code always assumed this wasn't the case), and these
>> functions are now mandatory (most of the code using these just checked
>> for their presence and if not used util_surface_copy instead, hence it
>> seems cleaner if drivers plug that in themselves, which some already did).
>> Also, there's an assumption that resource_copy_region works regardless
>> of bind flags (at least for texture targets, actually might also need to
>> work for buffers for "modern" drivers in the future not sure yet), hence
>> there are no longer any PIPE_BIND_BLIT flags (which were quite magic to
>> begin with, since a lot of the code could end up with a quad blit which
>> really wants RENDER_TARGET/SAMPLER_VIEW bind flags instead).
> 
> I didn't have time to look at the branch in detail, but all the above
> makes sense to me FWIW.
> 
>> It is possible some of the drivers implementation are a bit suboptimal
>> now, as they still use surfaces internally for easier migration (svga,
>> r300g, nouveau might particularly benefit from some cleanup).
>> If a driver implements this just with util_resource_copy_region, it is
>> possible there are performance regressions, since some (certainly not
>> all) state trackers used a quad blitter instead if this wasn't available.
>> The u_blit code still uses a pipe_surface as destination, which should
>> probably be changed at some point too but the change was already big
>> enough imho.
>>
>> Historically, blits had to operate on surfaces IIRC since there actually
>> were surfaces in gallium not backed by a pipe_resource (then
>> pipe_texture) but those are gone. So get_tex_surface() should actually
>> be viewed as the analogous function to create_sampler_view() (and yes it
>> will migrate to context too and probably renamed to something else), it
>> creates a view of a resource (the pipe_surface) to be used as a render
>> target (color or depth/stencil).
>>
>> The msaa changes are fairly minimal, there's a new context function to
>> set the sample mask (all drivers have dummy implementations), plus some
>> bits for sample to coverage etc. And a explicit resource_resolve
>> function which is defined as the only way to resolve a multisampled
>> resource, but so far no driver implements multisampling (and the mesa
>> state tracker won't use it neither).
> 
> There was some rudimentary MSAA support in mesa/st before. How does that
> stand now?

Yes, it had the ability to get the sample count from glx and set that to
the resources. That was all. It couldn't handle alpha to coverage, or
coverage values, and assumed drivers would do resolve completely hidden
from the state tracker.
It was extended a bit, but it's still incomplete. In particular, it'll
never call resource_resolve (I'm actually not sure yet who should call
that when such a multisampled buffer is presented).
Also, to make multisampling fully work in GL, there's some more magic
needed, though such usages are probably rare:
- using ReadPixels from a multisampled color buffer, you should get the
resolved result. This shouldn't be a problem, st can use resource_resolve.
- using ReadPixels from a multisampled depth/stencil buffer. GL
semantics say you should get the result from the "most centermost
sample" (though any other is acceptable too). It is unclear how to do
that, but the logical thing to do would probably be to put the burden on
the transfer (depending on the hardware, there is probably no easy way
to get those samples anyway).
- using WritePixels to a multisampled color buffer. This should just
update all samples, so as long as it's done by rendering a quad, this is
just fine, but if that'll use a transfer fallback it's a similar problem
to ReadPixels.
- using WritePixels to a multisampled depth/stencil buffer. As long as
that's just depth, that can also be done by rendering a quad. But
rendering to stencil buffer is impossible unfortunately(*), so the
transfer fallback is hit with the same problem again.
(Note that this should all be specific to GL afaict, such things should
be impossible in d3d.)

(*) this is untrue for some hardware, e.g. r600 can easily export a
stencil ref value from a pixel shader, much like it exports depth. But
we can't really exploit that in a generic quad renderer...

Roland