[Mesa-dev] RFC: gallium-newclear branch

[Roland Scheidegger]

On 02.06.2010 19:04, Marek Olšák wrote:
> 
> On Wed, Jun 2, 2010 at 3:02 PM, Roland Scheidegger <sroland at vmware.com
> <mailto: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).
The state tracker may still want to use the u_blit functions for
"non-standard" things. I agree though it would be nice conceptually if
the state trackers could assume these clear functions are present and
handle everything. For performance reasons it probably matters little if
drawing the quad is done from the state tracker or the driver. u_blitter
is only used in r300g (and r600g now) though, so this means all drivers
(not able to do native clears on their own) need to use it. Looks ok to
me but it would need to be done first and proven it works.

> 
> 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.
Hmm yes I guess that would tie into that nicely. It goes a bit beyond
clears, though.

> 
> 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.
Indeed. I'm not sure if this shouldn't have a different function
however. There is some reasonable chance that if it's the same format
some hardware can do it without using 3d engine (but straight dma engine
or whatnot), but obviously not with different formats. It is worth
noting also there are differences here what d3d10 and d3d10.1 allow for
CopySubresourceRegion, so apparently it isn't so clear cut what should
be allowed and what we need.

> 
> Opinions?
> 
> -Marek

Roland