[Mesa-dev] Mesa/Gallium overall design

[Keith Whitwell]

On Mon, Apr 12, 2010 at 9:55 AM, Christoph Bumiller
<e0425955 at 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