[Mesa-dev] RFC: gallium-newclear branch

Roland Scheidegger sroland at vmware.com
Fri May 28 17:51:25 PDT 2010


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


More information about the mesa-dev mailing list