Hi, On Wednesday, May 14, 2014 02:45:26 Jose Fonseca wrote: > If you rebase it on top of my series it can be reduced to merely this: Ok, thanks that is actually great news, as this gives me something to work with.
> In other words, we'd be introducing leaks for sake of thread-safety. I care > more for memory leaks than thread safety, but I can easily flip > USE_GLOBAL_CONTEXT internally. Ok, I can buy that. So, given that, it might be useful to mention that one can trade thread safety against leaks with toggling this define. > For now I'm going to commit my patch series as is, as I want feedback if it > causes any problems, as it is now. After I commit the series, if you could > verify that switching USE_GLOBAL_CONTEXT to 0 fixes multi-threading for you, > then I'd be happy to commit it after a few weeks. I can test this change this evening, but I won't hold back your series. It will be no worse than before and the rest of the series is highly useful stuff. But up to now I had this nebulous comment not giving enough information to see how a proper fix might look like and something that at least fixes what I could observe. One option that I can think of would be to have one such LLVM context per GL context instead of per gallivm (I realized some time ago that this is not equivalent). That should reduce the amount leaking objects to something that grows roughly with the number of created GL contexts instead of the number of compiles. Appart from getting a correct fix, could this be also an option for you? Thanks Mathias _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev