[Mesa-dev] thread safe llvmpipe

Rob Schneider Swizzle at t-online.de
Sat Jan 19 09:12:27 PST 2013

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

	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

	opengl32.dll!llvm::ScalarEvolution::isKnownNonNegative()  + 0x13
bytes C++ 

	opengl32.dll!llvm::ScalarEvolution::getSignExtendExpr()  + 0x17e
bytes C++ 

	opengl32.dll!llvm::ScalarEvolution::getAnyExtendExpr()  + 0x17c bytes

	opengl32.dll!`anonymous namespace'::LSRInstance::GenerateTruncates() 
+ 0x1df bytes C++ 

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130119/2cc828e9/attachment-0001.html>

More information about the mesa-dev mailing list