On Mon, Apr 12, 2010 at 9:55 AM, Christoph Bumiller <e0425...@student.tuwien.ac.at> wrote: > On 04/12/2010 10:22 AM, Luca Barbieri wrote: > >>>> 4. More powerful and better defined clear interface with scissor/MRT >>>> support >>> >>> I'm not sure how scissors fit in, other than that you probably have to >>> hax them on your HW to work with clears, but this isn't really a >>> problem any longer. If you want to involve e.g. MRTs in your clears, >>> patch util_clear to do it. Also how is this a GL thing? >> >> Because glClear respects scissors, and some hardware provides >> scissor-supporting CLEAR as well, while some may instead have the >> opposite. >> So IMHO there should be a separate full_clear and clear_with_scissors, >> or something like that. >> > > Hrm. So you dislike my patch about clearing buffers so much that you ignore > its existence ? You could have suggested to add a new full_clear function in > Hrm. So you dislike my patch about clearing buffers so much that you > ignore it ? > > People could have suggested to add a new full_clear function in addition > to the CAP I proposed, rather than the CAP modifying the behaviour of > the existing clear function (which was, admittedly, probably a bad idea). > > Well, it's only Monday, maybe just didn't see it, so here's a reminder.
More expressive clears is something which has come up a few times. I haven't seen your patch either (I'll search again), so I'm not commenting on it in particular, but: - It's clear we need a method for clearing a subset of the bound color buffers, rather than the current one flag for all colorbufs. - Maybe we want a method for clearing arbitrary color & depth buffers not even bound to the framebuffer. - Scissor clears -- extending gallium to permit scissored clears does not fundamentally change the idea of gallium. I'm not convinced it's a very important use case, but I'm not (or no longer...) philosophically opposed to it & I'm willing to investigate what such a change might look like. This is a miniature version of the general dillema of defining an intermediate interface on top of varying levels of hardware support. I'm not super happy with either of the obvious solutions - a less expressive interface which pushes more than necessary in the state-tracker (the current case), vs a more expressive interface with an in-driver helper module operating half-way to a layering violation. In fact this is something which has also come up a few times, with the draw module as the clear worst offender, the practice of utility modules within the driver looping up to twiddle the upstream interface leads to some pretty nasty situations & hard to understand code. I'd prefer to see less rather than more of this. A world where workarounds and missing functionality are implemented in a layer strictly below the state tracker and strictly above the driver would be preferable to where we are now, and with the advent of gallium/targets, we have an actor with the capability to construct such a stack. Keith _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
