[Mesa-dev] [Mesa3d-dev] r300g: hack around issue with doom3 and 0 stride

[Keith Whitwell]

On Sun, Apr 11, 2010 at 9:33 AM, Luca Barbieri <luca at luca-barbieri.com> wrote:
> Why?
>
> At least all nVidia cards directly support this, and it allows code like this:
>
> hw_set_vertex_attrib(idx, v)
> {
>    write command to set vertex attrib on GPU fifo
>    write idx on GPU fifo
>    write v on GPU fifo
>    return;
> }
>
> glColor()
> {
>    pipe->set_vertex_attrib(COLOR, v);
>    return;
> }
>
> Instead of this simple approach, we instead currently use the "vbo
> module", which attempts to store all the GL attributes in a vertex
> buffer, with all kinds of unnecessary complexity like having to resize
> the buffer in the middle of a primitive because you just used another
> vertex attribute, having to deal with memory allocation, vertex
> element CSO hashing and so on.
>
> Of course this results in not-so-good performance, which could
> otherwise be avoided with the approach described above (guess what the
> binary drivers use).
>
> I have no idea whether Radeon or Intel GPUs support this, but it
> doesn't seem unlikely since it is the basic OpenGL model.

Nvidia's definitely the odd one out here.  No other hardware I'm aware
of has this behaviour -- though perhaps the old SGI workstations also
worked this way.

I think this falls into the general question of how to make use of
special features a particular piece of hardware offers, without
raising the interface to the level ceases to provide a meaningful
intermediate abstraction.  Right now our answer is that we don't try
to, and .  There's zero likelihood that we'll suddenly decide to
include this deprecated GL feature as part of gallium, for instance --
much more likely would be to put some effort into optimizing the VBO
module, or creating a gallium-specific version of that code.

If you were absolutely committed to making use of this hardware
feature, one option might be to use the high vantage point of the
target/ directory, and allow that stack-constructing code to have
meaningful things to say about how to assemble the components above
the gallium driver level.  For instance, the nvidia-gl targets could
swap in some nv-aware VBO module replacement, which was capable of
talking to hardware and interacting somehow with the nv gallium
implementation.

I'm not sure if that will be a net positive thing for the
maintainability of the nv drivers, or whether the whole thing would
collapse in an unmaintanable heap of cross dependencies and layering
violations...  Personally I'd be more interested in improving the VBO
code.

Keith