On Wed, 2009-07-01 at 23:47 -0700, Corbin Simpson wrote: > So, a couple months ago I opined about the inability of Gallium to > guarantee non-overlapping blits. I need to revisit the subject. > > I can't detect when blits will overlap, every time, without massive hax, > and I'm not terribly certain that the hax work. Somehow (probably > through texture blanketing) I'm seeing two BOs, overlapping, being used > in texture_copy. I have no way of detecting that overlap at the moment, > and doing so is going to be icky. > > I propose PIPE_CAP_BLITTER, a simple pipe cap that just says, "Yes, I > have a 2D engine or some other way to do overlapping blits magically." > If this isn't set, use one of the util functions that semi-fallback to > textured drawing instead of straight surface_copy. In some state > trackers (Xorg EXA) this also can be used to indicate to higher > userspace the abilities of the card in a way that permits optimizations. > > Sorry for weird word choice; I'm running on like three cans of Red Bull > and a sleep deficit.
I think this is pretty reasonable -- the alternative is just to ditch the blitter functionality altogether. It's a pretty wierd little pimple on the side of an otherwise fairly focused set of interfaces, providing exceptions to most rules (eg: the only surfaces being modified are those bound with pipe_framebuffer_state... unless you use pipe_surface_copy()) I really wouldn't be sad to see them go... Keith ------------------------------------------------------------------------------ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
