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

[Marek Olšák]

On Sun, Sep 9, 2012 at 7:43 PM, Stéphane Marchesin
<stephane.marchesin at gmail.com> wrote:
> 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

It was the simplest code I could find. In no way did I mean to say it
was correct and bullet-proof.

> 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.

Yeah, it's mainly suited for the hardware which has no dedicated
blitter and everything must go through the 3D engine.

Marek