Allows to avoid a global lock being held while reading files from disk,
solving performance issues when Cycles needs to read a lot of packed
images.
Simple test file F11597666
Details
Details
Diff Detail
Diff Detail
- Repository
- rB Blender
- Branch
- image_runtime_mutex (branched from master)
- Build Status
Buildable 18318 Build 18318: arc lint + arc unit
Event Timeline
Comment Actions
Generaly LGTM, main concern here is about potential deadlocks (using several mutexes at the same time is always dangerous...).
| source/blender/blenkernel/BKE_image.h | ||
|---|---|---|
| 49–50 | Not sure this needs to be public API? Afaict this is only used in BKE image.c? | |
| source/blender/blenkernel/intern/image.c | ||
| 5335–5340 | not familiar enough with the image pool code, but are we sure this can never deadlock? i would at least add comments about expected order of lock/unlock of pool mutex vs. image mutex. | |
| source/blender/blenkernel/BKE_image.h | ||
|---|---|---|
| 49–50 | Was mainly following the Mesh's runtime API. | |
| source/blender/blenkernel/intern/image.c | ||
| 5335–5340 | Pool is never used from within an image cache lock. I'll add a comment. | |
Comment Actions
- Make runtime function maipulation private to the image.c
- Explain mutex acqusution in the image pool a bit better.
Comment Actions
Seems to work well
test case from this Diff
Master: I1029 09:03:08.657116 12372 session.cpp:467] Total render time: 3.1518 D13032: I1029 09:04:04.073683 30076 session.cpp:467] Total render time: 1.32681
Test case from D6267
Master: I1029 09:00:46.238179 22708 session.cpp:467] Total render time: 7.56488 D13032: I1029 09:00:22.561700 26416 session.cpp:467] Total render time: 5.96962