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

[Jose Fonseca]

----- Original Message -----
> 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);
> ...
> };
> 
> 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.
> 
> 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

IMO, although pipe helper modules like draw/u_blitter create several problems as they are not water-tight layers, I think overall this new interface is a good idea. 

Software renderers like llvmpipe/softpipe would benefit from a specialized software blitter does doesn't go through the full texture quad. svga pipe driver too, has dedicated stretch-blit commands that currently go unused.

But I'd prefer that u_blit was not removed/changed immediately, but simply marked deprecated and left untouched for a transitory period: we have internal state trackers that rely on it, and we want to be able to continue using it, until the new blit method becomes fully functional and stable.

Also, I think it would be simpler to keep resource_copy_region for now.

Jose