[Mesa-dev] thread safe llvmpipe

[Jose Fonseca]

Which LLVM version where you using? The lp_bld_init.c behavior varies tremendously with LLVM version. 

>From Mathias' reply it looks like we should call llvm_start_multithreading somewhere regardless. 

Jose 

----- Original Message ----- 

> Thanks for this update!

> I just looked into this issue again - in a usecase were multiple
> threads are running and each thread creates a context, renders in
> that context for some time and then destroys this context. No legacy
> OpenGL features were used.

> In this scenario one nearly always can reproduce a crash. From
> analyzing the callstacks of the crashes one could see that there
> were only two cases that can trigger such a crash
> 1. the first call to glDrawArrays() within a thread (always only the
> first one)
> 2. the final call that cleans up the context (wglDeleteContext in
> this case on Windows)

> When locking those two calls the application seemed to become thread
> safe. When just locking one of those two calls the crash still
> occurs. So it seems the problematic part is when LLVM eather creates
> the code - or LLVM does the cleanup.

> Is the user of llvmpipe expected to initialize LLVM for multithreaded
> support here ( llvm_start_multithreading ) - or should this not be
> necessary and this issue is more likely a result that still some
> LLVM contexts are shared?

> Below i have attached a typical callstack one can see when a heap
> corruption occurs - may be this gives some attional insight:

> opengl32.dll!malloc(unsigned __int64 size) Line 163 + 0x43 bytes C
> opengl32.dll!operator new(unsigned __int64 size) Line 59 + 0x8 bytes
> C++
> opengl32.dll!llvm::APInt::sext() + 0x17b bytes C++
> opengl32.dll!llvm::ConstantRange::signExtend() + 0x8c bytes C++
> opengl32.dll!llvm::ConstantRange::sextOrTrunc() + 0x25 bytes C++
> opengl32.dll!llvm::ScalarEvolution::getSignedRange() + 0x10fb bytes
> C++
> opengl32.dll!llvm::ScalarEvolution::isKnownNonNegative() + 0x13 bytes
> C++
> opengl32.dll!llvm::ScalarEvolution::getSignExtendExpr() + 0x17e bytes
> C++
> opengl32.dll!llvm::ScalarEvolution::getAnyExtendExpr() + 0x17c bytes
> C++
> opengl32.dll!`anonymous namespace'::LSRInstance::GenerateTruncates()
> + 0x1df bytes C++
> opengl32.dll!`anonymous
> namespace'::LSRInstance::GenerateAllReuseFormulae() + 0x6ce bytes
> C++
> opengl32.dll!`anonymous namespace'::LSRInstance::LSRInstance() +
> 0x316 bytes C++
> opengl32.dll!`anonymous namespace'::LoopStrengthReduce::runOnLoop() +
> 0x4a bytes C++opengl32.dll!llvm::LPPassManager::runOnFunction() +
> 0x492 bytes C++
> opengl32.dll!llvm::FPPassManager::runOnFunction() + 0x314 bytes C++
> opengl32.dll!llvm::FunctionPassManagerImpl::run() + 0x70 bytes C++
> opengl32.dll!llvm::FunctionPassManager::run() + 0xd2 bytes C++
> opengl32.dll!llvm::JIT::runJITOnFunctionUnlocked() + 0x20 bytes C++
> opengl32.dll!llvm::JIT::getPointerToFunction() + 0x287 bytes C++
> opengl32.dll!generate_variant(llvmpipe_context * lp,
> lp_fragment_shader * shader, const lp_fragment_shader_variant_key *
> key) Line 2199 + 0x13 bytes C
> opengl32.dll!llvmpipe_update_fs(llvmpipe_context * lp) Line 2647 +
> 0x27 bytes C
> opengl32.dll!llvmpipe_update_derived(llvmpipe_context * llvmpipe)
> Line 159 C
> opengl32.dll!llvmpipe_draw_vbo(pipe_context * pipe, const
> pipe_draw_info * info) Line 69 C
> opengl32.dll!st_draw_vbo(gl_context * ctx, const _mesa_prim * prims,
> unsigned int nr_prims, const _mesa_index_buffer * ib, unsigned char
> index_bounds_valid, unsigned int min_index, unsigned int max_index,
> gl_transform_feedback_object * tfb_vertcount) Line 274 + 0x2a bytes
> C
> opengl32.dll!vbo_draw_arrays(gl_context * ctx, unsigned int mode, int
> start, int count, unsigned int numInstances, unsigned int
> baseInstance) Line 627 C
> opengl32.dll!vbo_exec_DrawArrays(unsigned int mode, int start, int
> count) Line 653 C

> Von: Jose Fonseca <jfonseca at vmware.com>
> An: Swizzle at t-online.de
> Cc: mesa-dev at lists.freedesktop.org
> Betreff: Re: [Mesa-dev] thread safe llvmpipe
> Datum: Sun, 13 Jan 2013 02:22:03 +0100

> That work has been merged (w/ LLVM 3.1 and MC-JIT support), however
> it's quite likely that's there are still race conditions, as nobody
> has been pursuing llvmpipe thread-safety so far.
> Jose

> > Last year end of march i remember there was a discusssion about the
> > thread safety in llvmpipe.
> 
> > It seems that llvmpipe was not thread safe since the underlying
> > LLVM
> > contexts were shared, but there was a branch mentioned that fixes
> > this issue and that was planned to be merged to the mainline in the
> > future.
> 

> > When working with the latest mesa version i currently still notice
> > that llvmpipe is currently not thread safe - so i assume that this
> > changes that bring separated LLVM context handling have not been
> > submitted to the main line so far.
> 
> > Any new information available concerning this topic?
> 
> > _______________________________________________
> 
> > mesa-dev mailing list
> 
> > mesa-dev at lists.freedesktop.org
> 
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>