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

[Roland Scheidegger]

On 19.05.2010 00:54, Marek Olšák wrote:
> 
> On Tue, May 18, 2010 at 10:42 PM, Roland Scheidegger <sroland at vmware.com
> <mailto: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 <mailto: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.

Ok, I've done so. I think in a 3d hw world it makes little sense that
overlapping blits would be permitted at that level. Granted
resource_copy_region could as well be implemented with some dma copy
engine or some good old style 2d blitter, and at least the latter often
could handle overlap (i915g uses 2d blitter in fact, but I don't think
the code there handled overlap correctly).
FWIW, dx10 is more strict even, CopySubresourceRegion() doesn't even
allow copies using the same subresource (only same resource).

Roland