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 _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
