[Mesa-dev] Mesa/Gallium overall design

[Christoph Bumiller]

On 04/12/2010 02:00 PM, Keith Whitwell wrote:
> 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 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.
This could be solved by passing color masks to clear explicitly, as Luca
suggested. On nv50 you have to do CLEAR_BUFFERS for each buffer anyway,
and on nvfx you can just deactivate the other buffers with a single command.

> - Maybe we want a method for clearing arbitrary color & depth buffers
> not even bound to the framebuffer.
That would be somewhat inconvenient, because we'd have to bind them
internally as RTs to clear them.
If they're not bound and you want to clear them (which doesn't happen in
OpenGL), you can probably just use surface_fill, like util_clear does
already, since scissors, color and stencil masks won't apply.

> - 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...)
That's not the only thing. Separate depth and stencil clears are much
more common, and currently never use proper clear.

> 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