[Mesa-dev] [PATCH 11/11] vbo: overhaul display list vertex array setup/binding code

Mathias Fröhlich Mathias.Froehlich at gmx.net
Tue Jan 30 21:15:26 UTC 2018

Hi Brian,

> Ah right.  At one point I thought about dlist sharing, but I forgot to 
> address that in the end.
> I think one way to address that would be to put a mutex in the 
> vbo_save_vertex_list so it can only be accessed by one context at a 
> time.  Plus, check if the calling context matches to compile-time 
> context - if they don't match, update the 'current values'.

Hmm, that might work, but putting a mutex there is not so great IMO.

> I'll think about it more though.
Wait a minute ...
.. or two.

> > Beside that I am also not sure if the array update logic in 
> > works correctly when VBO_ATTRIB* arrays ending in an aliasing VERT_ATTRIB*
> > slot are both enabled. You probably need to currectly mask out the 
> > arrays before you distribute them across the inputs[] array. But the the 
> > just to store subsequent node->arrays entries to save memory fails when
> > skipping the masked out arrays.
> Can you provide a concrete example of what you mean?
I did not look too close as the dlist threading issue is already a show 
stopper for me.

But if you ask I have to look close:
Well what I initially thought should actually not be an issue. The loop 
walking the successive arrays actually walks all vbo enabled bits before some 
of them get disabled.

Put the context sharing issue asside for this question, but let me ask, were 
does the code set back the current array pointers in the inputs array?
Enabled has arrays are VBO_ATTRIB_POS, VBO_ATTRIB_GENERIC1 and  
Then issue a fixed function draw call on this dlist. That one shall evaluate 
Then issue a shader that should set the inputs VBO_ATTRIB_{POS,GENERIC1}.
But since .._GENERIC1 and _MAT_FRONT_DIFFUSE  do not end in the same 
VERT_ATTRIB location the corresponding current array pointers should be 
restored then, right?

Anyhow, wait a minute - did I already mention?

> Thanks for reviewing!
You are welcome!



More information about the mesa-dev mailing list