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