Hi, there's a new branch gallium-newclear which has some changes to clear functionality in it. I think this could be expanded further in the future to allow even more full-featured (GL) clears (as was briefly discussed previously) but this addresses some concerns, in particular needs of d3d10 and it also gets rid (sort of...) of the ugly resource_fill_region (ok changing that from surface_fill was a mistake...) which didn't really have that well defined meaning (with that unsigned value parameter) for depth/stencil surfaces (yet some drivers used it for that). I wanted to make separate depth stencil clears non-optional, but ultimately failed as too many drivers couldn't support it easily (from those not supporting it, I wouldn't be able to fix cell or nvfx - softpipe should be doable but not going to look nice, neither is llvmpipe looking nice). Nonetheless, if there's some method for the hw to do this faster than by normal rendering of a quad (which the statetrackers will do as fallback) certainly this should be implemented as this is something which all d3d/GL APIs allow and applications actually use (I'm not so sure about the masking and scissoring wrt actual use).
Anyway, the new clearRT/clearDS functions aren't implemented by all drivers yet. That should be ok for now since they didn't use to implement surface_fill neither. Also, the interface of these is not set in stone yet. In particular, they can handle a region, which is needed by d3d9, but not d3d10, so might remove that (also, clearDS (as well as clear) uses double as depth value, I'm not convinced on that, the only benefit over float seems to be for z32_unorm depth buffers you can get an exact value that way - but certainly rgba colors have the same problem, and those are just floats anyway, but it's a minor detail). Comments, thoughts? Roland _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
