Is swiftshader thread safe?

[Dean Sinaean]

Hello, 

     Sorry to bother. I am new to OpenGL ES and swiftshader. I am studying the code and have a question.

  

     I think in OpenGL ES, some objects can be shared across contexts, like Buffers and Textures. Does that mean they could be created and destroyed from within different threads?

     Given a circumstance, thread A and thread B are using context A and context B respectively. and context B is shared with context A and thus they use the same ResourceManager and NameSpace<Buffer>. 

     Thread A is deleting a buffer and Thread B is creating a buffer. this ends up with a std::map::erase and a std::map::insert in two seperate threads. Why won't this cause a race condition? 

    the code I am worrying about is like following:

 

    typedef std::map<GLint, Buffer*> BufferMap;

    BufferMap mBufferMap;

    gl::NameSpace mBufferNameSpace;

    

  https://swiftshader-review.googlesource.com/c/SwiftShader/+/2931/4/src/OpenGL/libGLESv2/ResourceManager.h#92

[Nicolas Capens]

Hi Dean,

Thanks for your interest in SwiftShader. The short answer is yes, SwiftShader is thread safe.

For the example of glGenBuffers() and glDeleteBuffers() being called concurrently, note that gl::GenBuffers() and gl::DeleteBuffers() both call es2::getContext(). The latter returns a RAII pointer-like object which takes an exclusive lock of the resource manager, and releases it on destruction. See ContextPtr in src/OpenGL/libGLESv2/Context.h. We believe all other shareable resources are also thread safe.

We may not have thread safety for platform-specific edge cases though. The OpenGL ES and EGL specifications leave some threading behavior the responsibility of the application or system components. For what it's worth, SwiftShader is used extensively for Android testing, with no known grave threading concerns.

Please do note that our OpenGL ES implementation is slated to be removed. We're focussing solely on our Vulkan implementation now. That said, we'll be providing backward compatibility with GLES through the ANGLE project. We are working hard to ensure this stack will be at least as thread safe as the legacy GLES implementation. We'll share details on how to build this "SwANGLE" setup with the group soon.

Cheers,

Nicolas

--
You received this message because you are subscribed to the Google Groups "swiftshader" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swiftshader...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/swiftshader/46495c28-6ffb-4569-add3-a5f536b576b5o%40googlegroups.com.