Fix T103408: Cycles deadlock during GPU viewport rendering
This was caused by rB0d73d5c1a2, which releases the scene mutex during kernel loading. However, the reset mutex was still held, which can cause a deadlock if another thread tries to reset the session, since it will acquire the released scene mutex and then wait for the reset mutex. Turns out there's no point in keeping the reset mutex locked after the delayed reset section, so now we just release it earlier, which resolves the deadlock.
This commit is contained in:
parent
c4d4db39dc
commit
2895c67086
Notes:
blender-bot
2023-02-14 00:29:15 +01:00
Referenced by issue #103408, Regression: Blender crash when moving camera immediately after opening the project (OPTIX) Referenced by issue #102967, 3.4: Potential candidates for corrective releases
|
@ -289,19 +289,24 @@ RenderWork Session::run_update_for_next_iteration()
|
|||
RenderWork render_work;
|
||||
|
||||
thread_scoped_lock scene_lock(scene->mutex);
|
||||
thread_scoped_lock reset_lock(delayed_reset_.mutex);
|
||||
|
||||
bool have_tiles = true;
|
||||
bool switched_to_new_tile = false;
|
||||
bool did_reset = false;
|
||||
|
||||
const bool did_reset = delayed_reset_.do_reset;
|
||||
if (delayed_reset_.do_reset) {
|
||||
thread_scoped_lock buffers_lock(buffers_mutex_);
|
||||
do_delayed_reset();
|
||||
/* Perform delayed reset if requested. */
|
||||
{
|
||||
thread_scoped_lock reset_lock(delayed_reset_.mutex);
|
||||
if (delayed_reset_.do_reset) {
|
||||
did_reset = true;
|
||||
|
||||
/* After reset make sure the tile manager is at the first big tile. */
|
||||
have_tiles = tile_manager_.next();
|
||||
switched_to_new_tile = true;
|
||||
thread_scoped_lock buffers_lock(buffers_mutex_);
|
||||
do_delayed_reset();
|
||||
|
||||
/* After reset make sure the tile manager is at the first big tile. */
|
||||
have_tiles = tile_manager_.next();
|
||||
switched_to_new_tile = true;
|
||||
}
|
||||
}
|
||||
|
||||
/* Update number of samples in the integrator.
|
||||
|
|
Loading…
Reference in New Issue