2013-10-12 14:08:59 +00:00
|
|
|
/*
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
|
|
|
* of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software Foundation,
|
|
|
|
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef __BLI_TASK_H__
|
2018-01-08 11:35:48 +01:00
|
|
|
#define __BLI_TASK_H__
|
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
#include <string.h> /* for memset() */
|
2013-10-12 14:08:59 +00:00
|
|
|
|
2016-05-13 11:03:04 +02:00
|
|
|
struct ListBase;
|
|
|
|
|
2019-02-18 08:08:12 +11:00
|
|
|
/** \file
|
|
|
|
* \ingroup bli
|
2013-10-12 14:08:59 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#ifdef __cplusplus
|
|
|
|
extern "C" {
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#include "BLI_threads.h"
|
|
|
|
#include "BLI_utildefines.h"
|
|
|
|
|
2017-11-23 21:14:43 +01:00
|
|
|
struct BLI_mempool;
|
|
|
|
|
2013-10-12 14:08:59 +00:00
|
|
|
/* Task Scheduler
|
2018-06-01 18:19:39 +02:00
|
|
|
*
|
2013-10-12 14:08:59 +00:00
|
|
|
* Central scheduler that holds running threads ready to execute tasks. A single
|
|
|
|
* queue holds the task from all pools.
|
|
|
|
*
|
|
|
|
* Init/exit must be called before/after any task pools are created/freed, and
|
|
|
|
* must be called from the main threads. All other scheduler and pool functions
|
|
|
|
* are thread-safe. */
|
|
|
|
|
|
|
|
typedef struct TaskScheduler TaskScheduler;
|
|
|
|
|
|
|
|
TaskScheduler *BLI_task_scheduler_create(int num_threads);
|
|
|
|
void BLI_task_scheduler_free(TaskScheduler *scheduler);
|
|
|
|
|
|
|
|
int BLI_task_scheduler_num_threads(TaskScheduler *scheduler);
|
|
|
|
|
|
|
|
/* Task Pool
|
|
|
|
*
|
|
|
|
* Pool of tasks that will be executed by the central TaskScheduler. For each
|
|
|
|
* pool, we can wait for all tasks to be done, or cancel them before they are
|
|
|
|
* done.
|
|
|
|
*
|
|
|
|
* Running tasks may spawn new tasks.
|
|
|
|
*
|
|
|
|
* Pools may be nested, i.e. a thread running a task can create another task
|
|
|
|
* pool with smaller tasks. When other threads are busy they will continue
|
|
|
|
* working on their own tasks, if not they will join in, no new threads will
|
|
|
|
* be launched.
|
|
|
|
*/
|
|
|
|
|
|
|
|
typedef enum TaskPriority {
|
2019-04-17 06:17:24 +02:00
|
|
|
TASK_PRIORITY_LOW,
|
|
|
|
TASK_PRIORITY_HIGH,
|
2013-10-12 14:08:59 +00:00
|
|
|
} TaskPriority;
|
|
|
|
|
|
|
|
typedef struct TaskPool TaskPool;
|
2015-01-06 18:21:46 +11:00
|
|
|
typedef void (*TaskRunFunction)(TaskPool *__restrict pool, void *taskdata, int threadid);
|
2015-11-02 16:52:19 +01:00
|
|
|
typedef void (*TaskFreeFunction)(TaskPool *__restrict pool, void *taskdata, int threadid);
|
2013-10-12 14:08:59 +00:00
|
|
|
|
|
|
|
TaskPool *BLI_task_pool_create(TaskScheduler *scheduler, void *userdata);
|
2015-11-02 16:57:48 +01:00
|
|
|
TaskPool *BLI_task_pool_create_background(TaskScheduler *scheduler, void *userdata);
|
2017-03-07 17:29:39 +01:00
|
|
|
TaskPool *BLI_task_pool_create_suspended(TaskScheduler *scheduler, void *userdata);
|
2013-10-12 14:08:59 +00:00
|
|
|
void BLI_task_pool_free(TaskPool *pool);
|
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
void BLI_task_pool_push_ex(TaskPool *pool,
|
|
|
|
TaskRunFunction run,
|
|
|
|
void *taskdata,
|
|
|
|
bool free_taskdata,
|
|
|
|
TaskFreeFunction freedata,
|
|
|
|
TaskPriority priority);
|
|
|
|
void BLI_task_pool_push(TaskPool *pool,
|
|
|
|
TaskRunFunction run,
|
|
|
|
void *taskdata,
|
|
|
|
bool free_taskdata,
|
|
|
|
TaskPriority priority);
|
|
|
|
void BLI_task_pool_push_from_thread(TaskPool *pool,
|
|
|
|
TaskRunFunction run,
|
|
|
|
void *taskdata,
|
|
|
|
bool free_taskdata,
|
|
|
|
TaskPriority priority,
|
|
|
|
int thread_id);
|
2013-10-12 14:08:59 +00:00
|
|
|
|
|
|
|
/* work and wait until all tasks are done */
|
|
|
|
void BLI_task_pool_work_and_wait(TaskPool *pool);
|
2018-12-03 22:55:18 +03:00
|
|
|
/* work and wait until all tasks are done, then reset to the initial suspended state */
|
|
|
|
void BLI_task_pool_work_wait_and_reset(TaskPool *pool);
|
2013-10-12 14:08:59 +00:00
|
|
|
/* cancel all tasks, keep worker threads running */
|
|
|
|
void BLI_task_pool_cancel(TaskPool *pool);
|
|
|
|
|
2013-10-26 01:06:19 +00:00
|
|
|
/* for worker threads, test if canceled */
|
|
|
|
bool BLI_task_pool_canceled(TaskPool *pool);
|
2013-10-12 14:08:59 +00:00
|
|
|
|
|
|
|
/* optional userdata pointer to pass along to run function */
|
|
|
|
void *BLI_task_pool_userdata(TaskPool *pool);
|
|
|
|
|
|
|
|
/* optional mutex to use from run function */
|
|
|
|
ThreadMutex *BLI_task_pool_user_mutex(TaskPool *pool);
|
|
|
|
|
2017-05-31 15:24:09 +02:00
|
|
|
/* Delayed push, use that to reduce thread overhead by accumulating
|
|
|
|
* all new tasks into local queue first and pushing it to scheduler
|
|
|
|
* from within a single mutex lock.
|
|
|
|
*/
|
|
|
|
void BLI_task_pool_delayed_push_begin(TaskPool *pool, int thread_id);
|
|
|
|
void BLI_task_pool_delayed_push_end(TaskPool *pool, int thread_id);
|
|
|
|
|
2014-10-22 11:56:52 +02:00
|
|
|
/* Parallel for routines */
|
2018-01-05 16:33:13 +01:00
|
|
|
|
2018-01-08 11:35:48 +01:00
|
|
|
typedef enum eTaskSchedulingMode {
|
2019-04-17 06:17:24 +02:00
|
|
|
/* Task scheduler will divide overall work into equal chunks, scheduling
|
|
|
|
* even chunks to all worker threads.
|
|
|
|
* Least run time benefit, ideal for cases when each task requires equal
|
|
|
|
* amount of compute power.
|
|
|
|
*/
|
|
|
|
TASK_SCHEDULING_STATIC,
|
|
|
|
/* Task scheduler will schedule small amount of work to each worker thread.
|
|
|
|
* Has more run time overhead, but deals much better with cases when each
|
|
|
|
* part of the work requires totally different amount of compute power.
|
|
|
|
*/
|
|
|
|
TASK_SCHEDULING_DYNAMIC,
|
2018-01-08 11:35:48 +01:00
|
|
|
} eTaskSchedulingMode;
|
|
|
|
|
2018-01-05 16:33:13 +01:00
|
|
|
/* Per-thread specific data passed to the callback. */
|
2019-07-30 14:56:47 +02:00
|
|
|
typedef struct TaskParallelTLS {
|
2019-04-17 06:17:24 +02:00
|
|
|
/* Identifier of the thread who this data belongs to. */
|
|
|
|
int thread_id;
|
|
|
|
/* Copy of user-specifier chunk, which is copied from original chunk to all
|
|
|
|
* worker threads. This is similar to OpenMP's firstprivate.
|
|
|
|
*/
|
|
|
|
void *userdata_chunk;
|
2019-07-30 14:56:47 +02:00
|
|
|
} TaskParallelTLS;
|
|
|
|
|
|
|
|
typedef void (*TaskParallelFinalizeFunc)(void *__restrict userdata,
|
|
|
|
void *__restrict userdata_chunk);
|
2018-01-05 16:33:13 +01:00
|
|
|
|
2018-01-10 12:49:51 +01:00
|
|
|
typedef void (*TaskParallelRangeFunc)(void *__restrict userdata,
|
2018-01-05 16:33:13 +01:00
|
|
|
const int iter,
|
2019-07-30 14:56:47 +02:00
|
|
|
const TaskParallelTLS *__restrict tls);
|
2014-10-22 11:56:52 +02:00
|
|
|
|
2019-07-30 14:56:47 +02:00
|
|
|
typedef struct TaskParallelSettings {
|
2019-04-17 06:17:24 +02:00
|
|
|
/* Whether caller allows to do threading of the particular range.
|
|
|
|
* Usually set by some equation, which forces threading off when threading
|
|
|
|
* overhead becomes higher than speed benefit.
|
|
|
|
* BLI_task_parallel_range() by itself will always use threading when range
|
|
|
|
* is higher than a chunk size. As in, threading will always be performed.
|
|
|
|
*/
|
|
|
|
bool use_threading;
|
|
|
|
/* Scheduling mode to use for this parallel range invocation. */
|
|
|
|
eTaskSchedulingMode scheduling_mode;
|
|
|
|
/* Each instance of looping chunks will get a copy of this data
|
|
|
|
* (similar to OpenMP's firstprivate).
|
|
|
|
*/
|
|
|
|
void *userdata_chunk; /* Pointer to actual data. */
|
|
|
|
size_t userdata_chunk_size; /* Size of that data. */
|
|
|
|
/* Function called from calling thread once whole range have been
|
|
|
|
* processed.
|
|
|
|
*/
|
2019-07-30 14:56:47 +02:00
|
|
|
TaskParallelFinalizeFunc func_finalize;
|
2019-04-17 06:17:24 +02:00
|
|
|
/* Minimum allowed number of range iterators to be handled by a single
|
|
|
|
* thread. This allows to achieve following:
|
|
|
|
* - Reduce amount of threading overhead.
|
|
|
|
* - Partially occupy thread pool with ranges which are computationally
|
|
|
|
* expensive, but which are smaller than amount of available threads.
|
|
|
|
* For example, it's possible to multi-thread [0 .. 64] range into 4
|
|
|
|
* thread which will be doing 16 iterators each.
|
|
|
|
* This is a preferred way to tell scheduler when to start threading than
|
|
|
|
* having a global use_threading switch based on just range size.
|
|
|
|
*/
|
|
|
|
int min_iter_per_thread;
|
2019-07-30 14:56:47 +02:00
|
|
|
} TaskParallelSettings;
|
2018-01-08 11:35:48 +01:00
|
|
|
|
2019-07-30 14:56:47 +02:00
|
|
|
BLI_INLINE void BLI_parallel_range_settings_defaults(TaskParallelSettings *settings);
|
2018-01-08 11:35:48 +01:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
void BLI_task_parallel_range(const int start,
|
|
|
|
const int stop,
|
|
|
|
void *userdata,
|
|
|
|
TaskParallelRangeFunc func,
|
BLI_task: Add pooled threaded index range iterator, Take II.
This code allows to push a set of different operations all based on
iterations over a range of indices, and then process them all at once
over multiple threads.
This commit also adds unit tests for both old un-pooled, and new pooled
task_parallel_range family of functions, as well as some basic
performances tests.
This is mainly interesting for relatively low amount of individual
tasks, as expected.
E.g. performance tests on a 32 threads machine, for a set of 10
different tasks, shows following improvements when using pooled version
instead of ten sequential calls to BLI_task_parallel_range():
| Num Items | Sequential | Pooled | Speed-up |
| --------- | ---------- | ------- | -------- |
| 10K | 365 us | 138 us | 2.5 x |
| 100K | 877 us | 530 us | 1.66 x |
| 1000K | 5521 us | 4625 us | 1.25 x |
Differential Revision: https://developer.blender.org/D6189
Note: Compared to previous commit yesterday, this reworks atomic handling in
parallel iter code, and fixes a dummy double-free bug.
Now we should only use the two critical values for synchronization from
atomic calls results, which is the proper way to do things.
Reading a value after an atomic operation does not guarantee you will
get the latest value in all cases (especially on Windows release builds
it seems).
2019-11-26 14:26:47 +01:00
|
|
|
TaskParallelSettings *settings);
|
|
|
|
|
|
|
|
typedef struct TaskParallelRangePool TaskParallelRangePool;
|
|
|
|
struct TaskParallelRangePool *BLI_task_parallel_range_pool_init(
|
|
|
|
const struct TaskParallelSettings *settings);
|
|
|
|
void BLI_task_parallel_range_pool_push(struct TaskParallelRangePool *range_pool,
|
|
|
|
const int start,
|
|
|
|
const int stop,
|
|
|
|
void *userdata,
|
|
|
|
TaskParallelRangeFunc func,
|
|
|
|
const struct TaskParallelSettings *settings);
|
|
|
|
void BLI_task_parallel_range_pool_work_and_wait(struct TaskParallelRangePool *range_pool);
|
|
|
|
void BLI_task_parallel_range_pool_free(struct TaskParallelRangePool *range_pool);
|
|
|
|
|
|
|
|
/* This data is shared between all tasks, its access needs thread lock or similar protection.
|
|
|
|
*/
|
BLI_task: Add new generic `BLI_task_parallel_iterator()`.
This new function is part of the 'parallel for loops' functions. It
takes an iterator callback to generate items to be processed, in
addition to the usual 'process' func callback.
This allows to use common code from BLI_task for a wide range of custom
iteratiors, whithout having to re-invent the wheel of the whole tasks &
data chuncks handling.
This supports all settings features from `BLI_task_parallel_range()`,
including dynamic and static (if total number of items is knwon)
scheduling, TLS data and its finalize callback, etc.
One question here is whether we should provide usercode with a spinlock
by default, or enforce it to always handle its own sync mechanism.
I kept it, since imho it will be needed very often, and generating one
is pretty cheap even if unused...
----------
Additionaly, this commit converts (currently unused)
`BLI_task_parallel_listbase()` to use that generic code. This was done
mostly as proof of concept, but performance-wise it shows some
interesting data, roughly:
- Very light processing (that should not be threaded anyway) is several
times slower, which is expected due to more overhead in loop management
code.
- Heavier processing can be up to 10% quicker (probably thanks to the
switch from dynamic to static scheduling, which reduces a lot locking
to fill-in the per-tasks chunks of data). Similar speed-up in
non-threaded case comes as a surprise though, not sure what can
explain that.
While this conversion is not really needed, imho we should keep it
(instead of existing code for that function), it's easier to have
complex handling logic in as few places as possible, for maintaining and
for improving it.
Note: That work was initially done to allow for D5372 to be possible... Unfortunately that one proved to be not better than orig code on performances point of view.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D5371
2019-10-30 12:23:45 +01:00
|
|
|
typedef struct TaskParallelIteratorStateShared {
|
|
|
|
/* Maximum amount of items to acquire at once. */
|
|
|
|
int chunk_size;
|
|
|
|
/* Next item to be acquired. */
|
|
|
|
void *next_item;
|
|
|
|
/* Index of the next item to be acquired. */
|
|
|
|
int next_index;
|
|
|
|
/* Indicates that end of iteration has been reached. */
|
|
|
|
bool is_finished;
|
|
|
|
/* Helper lock to protect access to this data in iterator getter callback,
|
|
|
|
* can be ignored (if the callback implements its own protection system, using atomics e.g.).
|
|
|
|
* Will be NULL when iterator is actually processed in a single thread. */
|
|
|
|
SpinLock *spin_lock;
|
|
|
|
} TaskParallelIteratorStateShared;
|
|
|
|
|
|
|
|
typedef void (*TaskParallelIteratorIterFunc)(void *__restrict userdata,
|
|
|
|
const TaskParallelTLS *__restrict tls,
|
|
|
|
void **r_next_item,
|
|
|
|
int *r_next_index,
|
|
|
|
bool *r_do_abort);
|
|
|
|
|
|
|
|
typedef void (*TaskParallelIteratorFunc)(void *__restrict userdata,
|
|
|
|
void *item,
|
|
|
|
int index,
|
|
|
|
const TaskParallelTLS *__restrict tls);
|
|
|
|
|
|
|
|
void BLI_task_parallel_iterator(void *userdata,
|
|
|
|
TaskParallelIteratorIterFunc iter_func,
|
|
|
|
void *init_item,
|
|
|
|
const int init_index,
|
|
|
|
const int tot_items,
|
|
|
|
TaskParallelIteratorFunc func,
|
|
|
|
const TaskParallelSettings *settings);
|
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
void BLI_task_parallel_listbase(struct ListBase *listbase,
|
|
|
|
void *userdata,
|
BLI_task: Add new generic `BLI_task_parallel_iterator()`.
This new function is part of the 'parallel for loops' functions. It
takes an iterator callback to generate items to be processed, in
addition to the usual 'process' func callback.
This allows to use common code from BLI_task for a wide range of custom
iteratiors, whithout having to re-invent the wheel of the whole tasks &
data chuncks handling.
This supports all settings features from `BLI_task_parallel_range()`,
including dynamic and static (if total number of items is knwon)
scheduling, TLS data and its finalize callback, etc.
One question here is whether we should provide usercode with a spinlock
by default, or enforce it to always handle its own sync mechanism.
I kept it, since imho it will be needed very often, and generating one
is pretty cheap even if unused...
----------
Additionaly, this commit converts (currently unused)
`BLI_task_parallel_listbase()` to use that generic code. This was done
mostly as proof of concept, but performance-wise it shows some
interesting data, roughly:
- Very light processing (that should not be threaded anyway) is several
times slower, which is expected due to more overhead in loop management
code.
- Heavier processing can be up to 10% quicker (probably thanks to the
switch from dynamic to static scheduling, which reduces a lot locking
to fill-in the per-tasks chunks of data). Similar speed-up in
non-threaded case comes as a surprise though, not sure what can
explain that.
While this conversion is not really needed, imho we should keep it
(instead of existing code for that function), it's easier to have
complex handling logic in as few places as possible, for maintaining and
for improving it.
Note: That work was initially done to allow for D5372 to be possible... Unfortunately that one proved to be not better than orig code on performances point of view.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D5371
2019-10-30 12:23:45 +01:00
|
|
|
TaskParallelIteratorFunc func,
|
|
|
|
const TaskParallelSettings *settings);
|
2016-05-13 11:03:04 +02:00
|
|
|
|
2017-11-23 21:14:43 +01:00
|
|
|
typedef struct MempoolIterData MempoolIterData;
|
2019-04-17 06:17:24 +02:00
|
|
|
typedef void (*TaskParallelMempoolFunc)(void *userdata, MempoolIterData *iter);
|
|
|
|
void BLI_task_parallel_mempool(struct BLI_mempool *mempool,
|
|
|
|
void *userdata,
|
|
|
|
TaskParallelMempoolFunc func,
|
|
|
|
const bool use_threading);
|
2017-11-23 21:14:43 +01:00
|
|
|
|
2018-01-08 11:35:48 +01:00
|
|
|
/* TODO(sergey): Think of a better place for this. */
|
2019-07-30 14:56:47 +02:00
|
|
|
BLI_INLINE void BLI_parallel_range_settings_defaults(TaskParallelSettings *settings)
|
2018-01-08 11:35:48 +01:00
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
memset(settings, 0, sizeof(*settings));
|
|
|
|
settings->use_threading = true;
|
|
|
|
settings->scheduling_mode = TASK_SCHEDULING_STATIC;
|
2019-07-30 14:36:59 +02:00
|
|
|
/* Use default heuristic to define actual chunk size. */
|
|
|
|
settings->min_iter_per_thread = 0;
|
2018-01-08 11:35:48 +01:00
|
|
|
}
|
|
|
|
|
2013-10-12 14:08:59 +00:00
|
|
|
#ifdef __cplusplus
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#endif
|