[Mesa-dev] RFC: gallium-newclear branch

[Roland Scheidegger]

On 01.06.2010 21:51, Keith Whitwell wrote:
>> 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).
> 
> I think these interfaces are OK.  I'd rename them to clear_render_target
> and clear_depth_sencil as we don't generally use camel-case in gallium
> (TGSI being the exception).
Ok, will do that and merge afterwards.

> 
> I know we needed to use double to get conformance for depth clears - GL
> does more or less the same (ClearDepth takes a GLclampd).  We're
> probably stuck with it.
I guess if we need conformance for Z32_UNORM depth buffers then it
indeed needs to stay. That said, the "new" glClearBuffer functions do
not support doubles, only floats for clearing depths. Hence I guess it
would be possible to use float only for clear_depth_stencil, not for
clear, but that doesn't look very nice neither.

> 
> On whether to include the box or not, I could go either way.  It's there
> now, so unless you are motivated to remove it, it can stay.
Yeah, it's there also because it evolved out of surface_fill originally,
and I figured it's easier to remove later rather than reintroduce :-).

> 
> We're clearly not at the end of the story with clear -- there's still
> changes to make GL clear happier (masks, scissor) that this doesn't
> address.  If anyone wants to step up with that work, please make a
> proposal.
That and the ability to clear only one color buffer bound to the
framebuffer. Though maybe the mesa statetracker should just use the
clear_render_target for that, though this doesn't make sense if it
should respect mask/scissor too. So possibly should just change clear to
respect that optionally instead.

#define PIPE_CLEAR_WITH_MASK_AND_SCISSOR (1 << 0)
#define PIPE_CLEAR_DEPTH        (1 << 1)
#define PIPE_CLEAR_STENCIL      (1 << 2)
#define PIPE_CLEAR_DEPTHSTENCIL (PIPE_CLEAR_DEPTH | PIPE_CLEAR_STENCIL)
#define PIPE_CLEAR_COLOR0       (1 << 3)
...
#define PIPE_CLEAR_COLOR7       (1 << 10)
#define PIPE_CLEAR_COLOR        (0xff << 3

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).

Roland