On Sun, Sep 9, 2012 at 7:43 PM, Stéphane Marchesin
<stephane.marche...@gmail.com> wrote:
> On Sat, Sep 8, 2012 at 2:52 PM, Marek Olšák <mar...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
