forked from bartvdbraak/blender
86991fbcb0
It was caused by image threading safe commit and it was noticeable only on really multi-core CPU (like dual-socket Xeon stations), was not visible on core i7 machine. The reason of slowdown was spinlock around image buffer referencing, which lead to lots of cores waiting for single core and using image buffer after it was referenced was not so much longer than doing reference itself. The most clear solution here seemed to be introducing Image Pool which will contain list of loaded and referenced image buffers, so all threads could skip lock if the pool is used for reading only. Lock only needed in cases when buffer for requested image user is missing in the pool. This lock will happen only once per image so overall amount of locks is much less that it was before. To operate with pool: - BKE_image_pool_new() creates new pool - BKE_image_pool_free() destroys pool and dereferences all image buffers which were loaded to it - BKE_image_pool_acquire_ibuf() returns image buffer for given image and user. Pool could be NULL and in this case fallback to BKE_image_acquire_ibuf will happen. This helps to avoid lots to if(poll) checks in image sampling code. - BKE_image_pool_release_ibuf releases image buffer. In fact, it will only do something if pool is NULL, in all other case it'll equal to DoNothing operation. |
||
|---|---|---|
| build_files | ||
| doc | ||
| extern | ||
| intern | ||
| release | ||
| source | ||
| CMakeLists.txt | ||
| COPYING | ||
| GNUmakefile | ||
| SConstruct | ||