On Fri, Mar 30, 2012 at 10:12 AM, Jose Fonseca <jfons...@vmware.com> wrote: > > > ----- Original Message ----- >> Ok, what if I one uses a global lock around every gl call? > > What do you mean with around every gl call? You mean not on the GL driver but > in the GL application? Yeah, that'd work. Though in that case there's not > much point to use GL from multiple threads.
Yes I mean locking on GL application level. My code is rendering off screen on multiple threads. The assumption was that if I use pixel buffer object to retrieve the data I would rely on asynchronous nature of that call and the other threads can happily work meanwhile. However I am not sure if that would help. > >> Would that >> work with the current version of pipeline before proper thread >> support >> is in place? > > LLVM is invoked from alot of places. Modifying the gallivm/llvmpipe to hold a > lock when that happens is insanely hard. It's much easier to just refactor > the code such that threads share no mutable obejcts. > > Jose > >> On Fri, Mar 30, 2012 at 3:42 AM, Jose Fonseca <jfons...@vmware.com> >> wrote: >> > gallivm/llvmpipe is not thread safe. >> > >> > To fix it, we need to have separate LLVMContext / JIT engines for >> > each pipe_context (i.e., each thread). >> > >> > I'm working on a branch that does most of this, and I plan to >> > commit over the next month or so. That branch also has changes for >> > the compilation to happen per function, and not per module, so >> > that we can use MC-JIT (which will eventually supersed the current >> > JIT engine), and that part is a bit experimental and needs more >> > work, which is why I can't commit immediately. >> > >> > Jose >> _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
