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

[Roland Scheidegger]

On 18.05.2010 22:23, Dave Airlie wrote:
> On Wed, May 19, 2010 at 3:04 AM, Roland Scheidegger <sroland at vmware.com> 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).
>> 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).
>>
>> Comments?
> 
> I was worried overlapping blits for u_blitter were no longer allowed,
> this is a requirement so please don't break that if you find its in
> the way.

I was thinking about changing the u_blitter code (I don't particularly
like that there is all different code to u_blit but doing pretty much
the same), but I left this as is (and there are no plans to change
u_blit code to not handle overlap).
That said though I can't see why u_blitter code still needs to handle
overlap. Unless I'm missing something overlap can no longer happen
there, at least not in master where r300 is the only user of this.

Roland