> 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.
Well, there are a lot of things that Gallium doesn't do well compared to other APIs, mostly OpenGL: 1. Support for fixed function cards in some way, either: 1a. (worse) New Gallium interfaces to pass fixed function pipeline states, along with an auxiliary module to turn them into shaders 1b. (better) An auxiliary module doing magic with LLVM to fit shaders into the fixed function pipeline 2. Support for setting individual states instead of full state objects, for APIs like OpenGL where that works better 3. Immediate vertex submission 4. More powerful and better defined clear interface with scissor/MRT support 5. Perhaps in theory more powerful 2D interfaces (e.g. format conversion, stretching, color masks, ROPs, Porter-Duff, etc), emulated over 3D by the blitter module, to better implement 2D apis 6. Better handling of shader linkage (I have some work on this) 7. Some broadly used and *good* way of managing graphics memory (e.g. pipebuffer improved and widely adopted) 8. Conditionals/predicates in TGSI (for NV_*_program) 9. Half float registers and precision specification in TGSI (for NV_*_program) 10. Maybe an interface to explicitly set constants instead of dealing with constant buffers (not sure about this, perhaps constant buffers are fine everywhere) Of course there are also the missing features that DirectX 10/11 has, like: 1. Mipmap generation 2. Stream out/transform feedback and DrawAuto 3. Support for creating display lists, i.e. having a CSO representing an hardware pushbuffer (DX11 has that) 4. Compute shaders 5. Tessellation 6. Multisampling, including alpha-to-coverage and all hardware-specific tricks like CSAA 7. 2D texture arrays 8. Texture sampling in geometry shaders 9. Indirect instanced drawing (see DX11 DrawInstancedIndirect) 10. DX11 shader interfaces 11. Selection of viewports/render target in 2D texture array from the geometry shader 12. More TGSI instructions (pointer load/stores, fp64, atomic ops, shared memory, etc.) There are also likely many other that didn't come to mind immediately. > 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. Well, I don't think Gallium should be the intersection of hardware/API features, but rather the union of all hardware/API features. Otherwise, obviously, it's going to suck on all cards and for all APIs. So if Radeon can do Lanczos sampling/rescaling and there is an OpenGL extensions that exposes that, I think Gallium should be extended to allow implementing the OpenGL extension over it and allow implementing the driver portions . Note that it is generally possible to do this intelligently, so that cards and APIs not having the feature are not imposed an undue burden due to it. The usual way is to either add a capability bit, and/or provide an auxiliary module emulating the special functionality over more common one. For instance, for the vertex submission problem, you could just introduce a Gallium-level module like the Mesa VBO module, that would allow non-nVidia drivers to only need to have a few lines of code added to enable it (with the settings most appropriate for them). Of course this may not get done due to not being worth the time to implement it, but that's a different issue. BTW, for instance, I sent a patch to change the Gallium sampler state to support nearest-neighbor anisotropic filtering on nVidia cards (by removing ANISO as a special filter), and it was merged some time ago, so it seems this kind of thing is possible... _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
