[Mesa-dev] Mesa/Gallium overall design

[Corbin Simpson]

On Sun, Apr 11, 2010 at 11:00 PM, Luca Barbieri <luca at luca-barbieri.com> wrote:
>> If you believe that it is easier to implement features on your hardware by
>> straying from Gallium or Mesa interfaces, you are welcome to do so.
>
> I don't understand what you mean.
> As far as I know, the classic Mesa interfaces cover all OpenGL
> features, since they don't abstract much.

More or less. There's a couple things there that require shoehorns,
but they're largely fixable by just adding another driver hook.

> The discussion is about what to do about features and cards not
> currently covered by Gallium

Ignore them.

> This includes all pre-R300 Radeon hardware, and since Radeon
> development hasn't yet moved to Gallium exclusively, maybe there are
> also some shortcomings in the Gallium interface affecting R300+ that
> are preventing r300 and r600 to be dropped in favor of r300g and r600g
> (not sure about this).

r300g is actively receiving love from the amateurs (me, Marek, Maciej)
and the paid guys (Dave, Alex). r300c commits are largely
maintenance-based at this point; I'd say the only consideration I give
to r300c is that I make a good effort to not break it when I touch
radeon_compiler.

r600g hasn't really taken off yet, but it's being worked on by Jerome.
r600 itself hasn't received much code since the initial release, and
although I haven't heard from Cooper and Richard, I'm sure they're
furiously working on something cool, either r600 or r600g or maybe
more video playback stuff.

There really aren't any Radeon-specific shortcomings in the interface
other than a hard dependency on NPOT textures, which require lots and
lots of hackery to fix.

> The Intel drivers also appear to be in the same situation, with
> classic drivers not being dropped in favor of Gallium ones, also
> indicating possible Gallium shortcomings leading to this.
> Nouveau is the only one that is embracing Gallium as far as possible,
> going as far as having attempted Gallium drivers for fixed function
> cards.

Intel only actively works on Mesa. The Gallium drivers are Jakob's and
Keith's, respectively, and are spare-time projects. If I remember
correctly, and please don't quote me without asking him first, Eric
said that the reason Intel hasn't moved to Gallium is because they
have a substantial codebase already developed, and they see no reason
to leave it.

> Hardware immediate vertex submission may be nVidia-specific, but it is
> part of a larger class of features available from OpenGL but not
> supported by Gallium.
> My aim was to discuss the larger problem of how to handle this class,
> rather than the possibly nVidia-specific feature that sparked the
> discussion.

Do what r300g does: Delay VBO submission, and make a choice at render
time as to whether immediate mode is going to pay off in performance.

You've kind of sparked my curiosity, though. What "larger class of
features" are you wanting to address, specifically? Some things are
simply not well-designated in the docs, like multisampling; others are
intentionally not part of Gallium, like non-GL_RENDER modes.

I wasn't trying to be antagonistic, but Gallium is supposed to be a
"common interface" and "abstraction," so features specific to one
chipset are invariably going to fall by the wayside. For example, r500
Radeons (and maybe r400?) have a filter4 kernel that they could use to
implement e.g. fast Lanczos sinc on textures, but the relevant Gallium
state was never used or tested and I think it's been nuked.

~ C.

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson
<MostAwesomeDude at gmail.com>