[Mesa-dev] Mesa/Gallium overall design

[Luca Barbieri]

> 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...