[Mesa-dev] RFC: gallium-newclear branch

[Marek Olšák]

On Wed, Jun 2, 2010 at 3:02 PM, Roland Scheidegger <sroland at vmware.com>wrote:

> Together with a PIPE_CAP_CLEAR_WITH_MASK_AND_SCISSOR.
>
> That would be all interface changes needed (so mask and scissor would be
> optional for drivers to implement, but single color buffers wouldn't be)
> - clearly some drivers can't handle the former, but I think all could be
> changed more or less easily to handle the latter. Still, that'll make 2
> cap queries just for clears (one for separate depth stencil, the other
> for masks/scissors), unless we replace the latter with
> PIPE_CAP_CLEAR_ALL_FEATURES or something (so, your driver implements
> masks/scissors, it has to implement separate depth/stencil clears too).
>

Considering that a state tracker has to use the 3D engine anyway if one of
these CAPS isn't supported, it makes sense to make the support of these
"clear" features mandatory and let pipe drivers use u_blitter if needed.

Right now we have u_blit and u_blitter. We cannot let u_blitter go because
it implements clear/resource_copy_region for r300g and r600g. On the other
hand, u_blit and other custom-made blitters wouldn't be needed if some
interface restrictions were raised (I think).

Or we may finally start developing the intermediate layer we talked about
some time ago and make it redirect unsupported clear/resource_copy_region
usage to u_blitter.

It would also be nice to allow non-matching src and dst formats in
resource_copy_region and let u_blitter cope with that but that's another
story.

Opinions?

-Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20100602/de040699/attachment.htm>