Hello, I ran piglit (glthread false vs true) on the Marek branch and Nouveau driver. Of course we can still debate, if piglit is good enough to detect multi threading issue.
I spot a small typo that generate ~400 fails (*mat2x4* uniform got 6 scalar instead of 8). piglit status with the typo patch : warn +2/ fail + 4/ crash +5 All regressions are on GLX tests but glsl-uniform-out-of-bounds. The latter reports a wrong error INVALID_VALUE (there is an extra glthread check because count is too big) instead of INVALID_OPERATION (not an array uniform must have a count of 1). I'm not sure it worth a fix. On GLX side, I can explain some crashes (didn't debug all neither fail) and I suspect there are related to the previous report. At the context creation a glthread dispatcher is created and the *TLS* variable u_current_table is set with the new gl marshal function. If deprecated non-VBO functions are detected (glBegin/glVertexPointer/... and others horror from the previous century), the code will disable glthread. 1/ thread will be deleted 2/ u_current_table will be set to the original value However u_current_table is local to a thread. So a single thread will get the correct dispatcher table. Remaining threads will keep the previous marshal thread. If a glthread function is called without the thread behind, then BOOM. I don't know how to fix it. However, is it really a necessity to care for such "old" application. Note: display list update also the table, I'm not sure of the impact. I don't know if piglit test display list Unfortunately it is way too late (at least for closed application, open source can easily be updated), but one could imagine a context flag to select a gl dispatcher. IMHO, the application is the best judge to enable it. Automatic detection on the driver is quite complicated. It is way cheaper to add an env value in the .desktop file. IMHO, it would be better to just drop the "automatic removal" of glthread. Old application will be slower if an user set wrongly an env variable which is more reasonable than a crash. Cheers, Gregory _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
