[Mesa-dev] Gallium: Moving BlitFramebuffer implementation into drivers

[Christoph Bumiller]

On 08.09.2012 23:52, Marek Olšák wrote:
> Hi everyone,
> 
> I'd like to move the BlitFramebuffer implementation into gallium
> drivers. The pros are:
> - allowing MSAA resource blitting to be accelerated on any hardware
> - allowing stencil blitting to be accelerated on any hardware
> - drivers are more likely to take a faster codepath if they have the
> full description of the blit operation
> - easy way to do blitting in state trackers (no modules needed)
> - unduplication of code between u_blitter and u_blit (by dropping
> u_blit), so that we can more concentrate on improving the former
> 
> This is the proposed interface:
> 
> /**
>  * Information to describe a blit call.
>  */
> struct pipe_blit_info
> {
>    struct {
>       struct pipe_resource *resource;
>       unsigned level;
>       struct pipe_box box; /**< negative width, height only legal for src */
>       /* For pipe_surface-like format casting: */
>       enum pipe_format format; /**< must be supported for sampling (src)
>                                     or rendering (dst) */
>    } dst, src;
> 
>    unsigned mask; /**< bitmask of PIPE_MASK_R/G/B/A/Z/S */
>    unsigned filter; /**< PIPE_TEX_FILTER_* */
> 
>    boolean scissor_enable;
>    struct pipe_scissor_state scissor;
> };
> 
> struct pipe_context
> {
> ...
>    void (*blit)(struct pipe_context *pipe,
>                 const struct pipe_blit_info *info);
> ...
> };
> 

This is great, since I've really always wanted this, so I can finally
use the 2D engine for blits, which saves a lot of state bashing and
vertex upload compared to using the 3D entry points.

Plus, it finally enables me to do fast stencil-only blits, which has to
be done in a somewhat unusual way on NV cards (binding the ZS resource
as color render target using the color mask with an appropriate format
and shader to make it write only the stencil byte).

> The reason for having the scissor state in there is that the source
> texture cannot be clipped to the scissor rectangle easily if the blit
> is scaled (stretched). The result of such clipping would have to be in
> floats.
> 
> There are pretty much no limitations of what it can do, just like
> BlitFramebuffer (which allows flipping, scaling, format conversions,
> upsampling and downsampling (= resolve), out-of-bounds reads are
> clamped etc.), except that we should also allow the render condition
> to take effect? Not sure it would be needed though.
> 
> I will gladly implement the new blit hook in all drivers. I will use
> u_blitter for that. i915g is a good example of how easy it can be:
> http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/i915/i915_surface.c#n46
> 
> This deprecates resource_resolve. Note that resource_resolve already
> allows scaling (there is a cap for that though), flipping, and format
> conversions. pipe_resolve_info is really not much different from
> pipe_blit_info and may just as well be removed.
> 
> I am not sure if it deprecates resource_copy_region (let's talk only
> about textures here). Drivers are free to use resource_copy_region for
> those blits that are equivalent to it, so in the end it doesn't matter
> if the state tracker is using blit or resource_copy_region.
> 

I think it's nice to still have an entry poin for a plain GPU memcpy, it
would use a different mechanism on NV hardware (DMA or async copy engine
vs. 2D/3D engine).
Besides, it matches D3D's CopySubresourceRegion.

> It also deprecates u_blit. I'd like all traces of u_blit to disappear
> from st/mesa at least. I'd also like to remove all code that tries
> resource_copy_region first before using u_blit, because drivers are
> better off deciding that for themselves (CopyTexSubImage is one such
> example).
> 
> I am also fixing all BlitFramebuffer tests that st/mesa fails at the moment.
> 
> That's it. I am looking forward to your comments.
> 
> Marek
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>