[Mesa-dev] [PATCH 04/11] st/mesa: Use Array._DrawVAO in st_atom_array.c.

Roland Scheidegger sroland at vmware.com
Tue Dec 11 16:46:34 UTC 2018


Am 11.12.18 um 10:37 schrieb Mathias Fröhlich:
> 
> Hey,
> 
> On Tuesday, 11 December 2018 10:19:47 CET Erik Faye-Lund wrote:
>> On Mon, 2018-12-10 at 18:23 +0100, Mathias Fröhlich wrote:
>>> Hi Erik,
>>>
>>> Not sure if this is our problem as I think that I only saw simple
>>> bindings with a zero instance divisor while debugging supertux kart.
>>>
>>> But at least I think that this is a problem in virglrenderer. The
>>> glVertexBindingDivisor is per binding and not per vertex attribute
>>> in OpenGL.
>>> ... you probably want to solve that differently, but for now this
>>> should
>>> quick band aid to pinpoint the problem that we observe.
>>>
>>> Does the attached patch to virglrenderer fix our problem?
>>>
>>
>> It does! Thanks a lot :)
>>
>> I'll find out what the proper fix is, and submit a patch in your name!
>> Again, thanks a lot :)
> 
> You are welcome! And I don't need credits. Its a bit of a pity that the
> vertex element/buffer structure in gallium is different than it is in OpenGL.
> OTOH, does it match the way it is done in DirectX?
Yes indeed. It actually seems D3d10 (11/12) is the odd man out here,
since GL, Vulkan, and even Metal have it per vertex buffer. But having
it per attribute is a more powerful representation (since you can have
multiple attribs per buffer, but not the other way round). Not sure
off-hand if d3d9 could already do it. I suppose if you'd be interested
only in gl state tracker you could ignore that the value could
potentially be different for different attributes but the same buffer,
otherwise you'd have to duplicate the binding in theory, although I
believe that hitting such a condition will be extremely rare (it
probably doesn't make much sense that someone would organize the data in
such a strange way that you have both per-vertex and per-instance (or
per-instance data with separate rates) in the same buffer).

Roland


More information about the mesa-dev mailing list