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

[Stéphane Marchesin]

On Sat, Sep 8, 2012 at 2:52 PM, Marek Olšák <maraeo at gmail.com> 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);
> ...
> };
>
> 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

It's funny you mention that code, as it has some issues on i915g in
some corner cases. Not sure what/where the issue is (i915g or that
blitting implementation), though. In any case, I'm thinking of
switching to use the blitter since I found out that this code leads to
a ton of state emission which pollutes the 3D buffers.

Stéphane