On Sun, Apr 11, 2010 at 11:00 PM, Luca Barbieri <l...@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 <mostawesomed...@gmail.com> _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
