| Summary: | Gallium OSMesa driver is far from being thread-safe | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Frederic Devernay <frederic.devernay> |
| Component: | Drivers/OSMesa | Assignee: | mesa-dev |
| Status: | RESOLVED MOVED | QA Contact: | mesa-dev |
| Severity: | normal | ||
| Priority: | medium | CC: | frederic.devernay |
| Version: | 11.2 | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
patch for Mesa-11.2.0
patch for Mesa-11.1.2 patch for Mesa-11.2.0, v2 patch for Mesa-11.1.2, v2 patch for Mesa-11.2.0, v3 patch for Mesa-11.1.2, v3 patch for Mesa-11.1.2, v3 |
||
|
Description
Frederic Devernay
2016-04-20 17:31:08 UTC
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.