<div class="gmail_quote">On Wed, Jun 2, 2010 at 3:02 PM, Roland Scheidegger <<a href="mailto:sroland@vmware.com">sroland@vmware.com</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> 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). </blockquote></div> 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