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

[Christoph Bumiller]

On 11.04.2010 09:32, Luca Barbieri wrote:
>> I'd like to get rid of the zero stride concept and require the state tracker
>> to either turn those values into proper constant (easy now we can bind >1
>> constant buffer)
>>     
> Wouldn't that require changing and recompiling the vertex shaders,
> reading the constants from the driver anyway, or just binding that
> constant buffer as a vertex buffer like things are done now? (unless
> the GPU has special fetch-from-constant-buffer support)
>
>   
My recollection of VPs already being recompiled to accommodate
constant attributes was wrong, but in FF mode suitable FPs are
create if you use a constant color, i.e. passed-through one specified
outside glBegin.

If an attribute is specified only once, yet inside glBegin, you get a
buffer where the same color is specified for each vertex, with default
stride.
You get stride 0 then, obviously, for custom shaders where you specify
an attribute outside glBegin.

Modern apps using shaders will probably know to place consant
attributes in uniforms themselves.
I doubt recompiling a new VP that gets an attribute from constbuf
is any faster than using stride 0 attributes.
>> or use instancing to get the same effect.
>>     
> How is this possible? Non-per-instance data still varies per vertex.
>
>   
Oh, why, you just set the instance divisor to infinity and you
have a constant attribute. Until the instance count exceeds
infinity, i.e. UNSIGNED_MAX.
I find that somewhat ugly, though.
> IMHO what could be done is to add an explicit API for that instead
> ("set_vertex_attrib") and have a special vertex buffer index in the
> vertex element state that means "I'll call set_vertex_attrib for this
> element".
>
>   
I've wanted such a thing. Fetching constants attributes by
mapping a buffer, hoping it's user memory and doesn't have
to be mapped into your address space first (ok that can be
attributed to bad buffer management), and then converting
the data to float (or uint32) ...
is probably not that problematic ... but still, driver code could
become nicer. At least for the nvXX drivers.
> As an additional step, "begin_draw", "end_draw" and "emit_vertex"
> could be added, allowing to implement glBegin/glVertexAttrib/glEnd
> directly over Gallium and getting rid of the vbo module, probably with
> significant performance gains.
>
>   
> A vbo-like Gallium auxiliary module could handle GPUs that lack such
> support, if there are any.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>