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