You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, each primitive locks the scene mutex during the Sync method to write new values, making primitive syncing pretty much sequential. I can think of two ways to optimize it:
Minimize the time spent in the lock for each primitive. Instead of reading, processing and writing the primitive data inside the lock, we could separate the reading/processing to be thread free and lock only when updating the Cycles geometry buffers.
Provide further synchronization mechanism to guarantee that committing resources to the device has finished before new primitives are being synced.
The former seems to most reasonable solution, there are lots of edge cases for 2., especially when running on top of "opaque" execution engine.
To provide evidence of the problem... Scrolling quickly through the usdview timeline without scene locks for each primitive Sync can result in the previous frame still committing resources (as it runs in a separate session thread) while new primitives are being synced causing data races and exceptions during Session::update_scene .
It's not something of the highest priority, but we should probably look to start the discussion.
The text was updated successfully, but these errors were encountered:
Some of the work I made for #135 is to move us closer to solve synchronization issues. In that #135 PR we have a resource registry that should be a centralized place to commit all necessary resources to Cycles.
Currently, each primitive locks the scene mutex during the
Sync
method to write new values, making primitive syncing pretty much sequential. I can think of two ways to optimize it:The former seems to most reasonable solution, there are lots of edge cases for 2., especially when running on top of "opaque" execution engine.
To provide evidence of the problem... Scrolling quickly through the usdview timeline without scene locks for each primitive Sync can result in the previous frame still committing resources (as it runs in a separate session thread) while new primitives are being synced causing data races and exceptions during
Session::update_scene
.It's not something of the highest priority, but we should probably look to start the discussion.
The text was updated successfully, but these errors were encountered: