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

[Marek Olšák]

On Tue, May 18, 2010 at 10:42 PM, Roland Scheidegger <sroland at vmware.com>wrote:

> 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.
>

I recall that overlapping surface_copy blits were required by st/xorg. Since
you said that the overlapping blits are no longer permitted, the
corresponding code can be removed from u_blitter.

-Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20100519/c3be0f7c/attachment.htm>