see src/gallium/state_trackers/osmesa/osmesa.c There are at least three global variables with no protection: - stapi in get_st_api() - stmgr in get_st_manager() - BufferList Consequently: - OSMesaCreateContext cannot be called simultaneously from two threads - OSMesaMakeCurrent called from two threads with the same buffer attribs will share the same element in BufferList, and thus render to the same memory! My guess is that these two objects should simply be stored in the context itself, but I cannot foresee the consequences. For example, will shared display lists still work? I am willing to help on solving this (we use OSMesa in highly multithreaded application).
Created attachment 123108 [details] [review] patch for Mesa-11.2.0 Add proposed patch for Mesa 11.2.0, please review
Created attachment 123109 [details] [review] patch for Mesa-11.1.2
I'm not really sure about that. It is possible this was intended for multiple contexts rendering to the same buffer (as is possible with "ordinary" GL), which won't work with this. Though you are certainly right that it's impossible to use multiple buffers right now from different contexts. As for multiple screens, I'm not quite sure why one wouldn't do? Albeit might need some mutex protection? I don't really know anything about osmesa though nor why people still use it, Brian would be the person to ask how it's supposed to work.
> I don't really know anything about osmesa though nor why people still use > it We use OSMesa extensively for rendering on headless servers with no GPUs. It's *MUCH* better than dealing with having to start up an X server and use GLX. EGL is in the planned transition but it doesn't quite work yet with a software-only no-X configuration, at least not that I've been able to configure :-(. Off topic for this bug though.
OK, there was another issue, which actually may affect other Gallium drivers as well: st_framebuffer_reuse_or_create() uses pointer comparison to check if it can reuse a framebuffer. The problem is that a call to free followed by a call to malloc may very well return the exact same pointer! Pointer comparison should be used as a safe check but is very unreliable. The consequence is that osmesa_st_framebuffer_validate() was not called and the textures were not allocated, even though the osbuffer was just allocated. I added a fix which explicitely sets st->ctx->WinSysDrawBuffer and st->ctx->WinSysReadBuffer to NULL, so that the framebuffer is reallocated and framebuffer_validate() is always called. This is in the second version of the patch set.
Created attachment 123120 [details] [review] patch for Mesa-11.2.0, v2
Created attachment 123121 [details] [review] patch for Mesa-11.1.2, v2
(In reply to Frederic Devernay from comment #5) > OK, there was another issue, which actually may affect other Gallium drivers > as well: > > st_framebuffer_reuse_or_create() uses pointer comparison to check if it can > reuse a framebuffer. > > The problem is that a call to free followed by a call to malloc may very > well return the exact same pointer! Pointer comparison should be used as a > safe check but is very unreliable. Yes, I think this is the same issue as originally reported here: https://bugs.chromium.org/p/chromium/issues/detail?id=395818
Created attachment 123123 [details] [review] patch for Mesa-11.2.0, v3 add a trivial check in osmesa_destroy_buffer (in case context is destroy before being made current)
Created attachment 123124 [details] patch for Mesa-11.1.2, v3 add a trivial check in osmesa_destroy_buffer (in case context is destroyed before being made current)
Created attachment 123125 [details] [review] patch for Mesa-11.1.2, v3 add a trivial check in osmesa_destroy_buffer (in case context is destroyed before being made current)
Hi Frederic, please send your patches to the ML for review[1]. [1] http://mesa3d.org/devinfo.html#submitting
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/880.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.