On Mon, 2009-11-16 at 05:59 -0800, Christoph Bumiller wrote: > Corbin Simpson schrieb: > > URL: > > http://cgit.freedesktop.org/~csimpson/mesa/log/?h=gallium-blitter > > > > So, with r600g right around the corner, I'd like to do something about > > this blitter/no blitter thing. > > > > This patch series contains one new getparam, PIPE_CAP_BLITTER, and a > > proposed ABI change to accompany it. > > > > surface_copy and surface_fill are proposed to have a way of indicating > > whether or not they successfully performed the fill/blit. It is up to > > the state tracker to determine whether or not to rely on these functions. > > > > Issues: > > - Should clear be included with these two? I don't think any drivers are > > doing anything with clear except wiring it up to util_clear... > Just wanted to mention nv50 actually has a special hardware clear path, > which > supports separate R/G/B/A/Z/S clear and respects scissors, it doesn't > use util_clear.
I think we want to continue treating clears and blits as distinct operations. On binning hardware or a binning software rasterizer, like the lp-binning branch of llvmpipe, clear is definitely a special operation -- it represents one of two possible ways to initialize the contents of the tile at the start of each binning list. This means clears are effectively free, and it's actually faster to render to a full-screen cleared surface than it would be to continue rendering to a surface without clearing. Blit operations such as copy/fill would be implemented quite differently - by generating an optimized blit routine & running it directly on the underlying storage. Right now, it seems like we'd want to have both. Keith ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
