Unfortunately cc0114f30b587a10766ec212afb3ad356099ef23: "st/nine: Implement Managed vertex/index buffers" introduced some regressions.
We have finally managed to find exactly what was the source of the regressions, and it appears to be some threading issues. In addition to these threading issues fixes, I've added a patch to improve the behaviour of the readonly flag, since this could also cause regressions we didn't notice yet (if app is mapping for readonly but writing trash to the buffer). About these threading issues, The expected behaviours is: . buffers start dirty . locks do dirty the buffer . if dirty, upload the content at the first draw call needing the data The main problem is that we don't implement that last part of the behaviour, and instead upload at the first draw call (not neccessarily needing the data). As the buffer must be unlocked before any draw call needing the data, implementing the behaviour would also fix the problem. However as it needs a bit of work, I plan to merge for now these fixes, and implement later the correct behaviour. Axel Davy (3): st/nine: Handle READONLY for buffer MANAGED pool st/nine: Fix Multithreading issue with MANAGED buffers st/nine: Fix second Multithreading issue with MANAGED buffers src/gallium/state_trackers/nine/buffer9.c | 26 ++++++++++++++++++-------- 1 file changed, 18 insertions(+), 8 deletions(-) -- 2.7.1 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
