----- 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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
