2011-02-23 10:52:22 +00:00
|
|
|
/*
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +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
|
2018-06-01 18:19:39 +02:00
|
|
|
* of the License, or (at your option) any later version.
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
*
|
|
|
|
* 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,
|
2010-02-12 13:34:04 +00:00
|
|
|
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
*
|
|
|
|
* The Original Code is Copyright (C) 2006 Blender Foundation
|
|
|
|
* All rights reserved.
|
|
|
|
*/
|
|
|
|
|
2019-02-18 08:08:12 +11:00
|
|
|
/** \file
|
|
|
|
* \ingroup bli
|
2011-02-27 20:37:56 +00:00
|
|
|
*/
|
|
|
|
|
2020-12-04 11:28:09 +01:00
|
|
|
#include <cerrno>
|
|
|
|
#include <cstdlib>
|
|
|
|
#include <cstring>
|
2006-02-25 11:56:08 +00:00
|
|
|
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
#include "MEM_guardedalloc.h"
|
|
|
|
|
2010-01-22 11:06:57 +00:00
|
|
|
#include "BLI_gsqueue.h"
|
2020-03-19 09:33:03 +01:00
|
|
|
#include "BLI_listbase.h"
|
2018-11-27 18:21:43 +01:00
|
|
|
#include "BLI_system.h"
|
2013-10-12 14:08:59 +00:00
|
|
|
#include "BLI_task.h"
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
#include "BLI_threads.h"
|
|
|
|
|
2008-08-16 22:47:33 +00:00
|
|
|
#include "PIL_time.h"
|
|
|
|
|
2008-02-21 08:43:13 +00:00
|
|
|
/* for checking system threads - BLI_system_thread_count */
|
2008-02-20 01:12:21 +00:00
|
|
|
#ifdef WIN32
|
2012-06-16 20:20:07 +00:00
|
|
|
# include <sys/timeb.h>
|
2020-03-19 09:33:03 +01:00
|
|
|
# include <windows.h>
|
2008-02-21 08:43:13 +00:00
|
|
|
#elif defined(__APPLE__)
|
2012-06-16 20:20:07 +00:00
|
|
|
# include <sys/sysctl.h>
|
2020-03-19 09:33:03 +01:00
|
|
|
# include <sys/types.h>
|
2008-02-21 08:43:13 +00:00
|
|
|
#else
|
2012-06-16 20:20:07 +00:00
|
|
|
# include <sys/time.h>
|
2020-03-19 09:33:03 +01:00
|
|
|
# include <unistd.h>
|
2008-02-20 16:07:42 +00:00
|
|
|
#endif
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
|
2020-07-02 16:40:30 +02:00
|
|
|
#ifdef WITH_TBB
|
|
|
|
# include <tbb/spin_mutex.h>
|
|
|
|
#endif
|
|
|
|
|
2017-03-02 09:56:25 +01:00
|
|
|
#include "atomic_ops.h"
|
2018-11-27 18:21:43 +01:00
|
|
|
#include "numaapi.h"
|
2017-03-02 09:56:25 +01:00
|
|
|
|
2014-04-27 18:44:23 +02:00
|
|
|
#if defined(__APPLE__) && defined(_OPENMP) && (__GNUC__ == 4) && (__GNUC_MINOR__ == 2) && \
|
|
|
|
!defined(__clang__)
|
2013-05-20 16:15:16 +00:00
|
|
|
# define USE_APPLE_OMP_FIX
|
|
|
|
#endif
|
2014-03-31 13:51:40 +02:00
|
|
|
|
2013-05-20 16:15:16 +00:00
|
|
|
#ifdef USE_APPLE_OMP_FIX
|
2010-03-09 16:54:25 +00:00
|
|
|
/* ************** libgomp (Apple gcc 4.2.1) TLS bug workaround *************** */
|
|
|
|
extern pthread_key_t gomp_tls_key;
|
|
|
|
static void *thread_tls_data;
|
|
|
|
#endif
|
|
|
|
|
2020-09-07 15:57:12 +10:00
|
|
|
/**
|
|
|
|
* Basic Thread Control API
|
|
|
|
* ========================
|
2018-06-01 18:19:39 +02:00
|
|
|
*
|
2012-03-03 20:19:11 +00:00
|
|
|
* Many thread cases have an X amount of jobs, and only an Y amount of
|
2020-09-07 15:57:12 +10:00
|
|
|
* threads are useful (typically amount of CPU's)
|
2012-03-03 20:19:11 +00:00
|
|
|
*
|
|
|
|
* This code can be used to start a maximum amount of 'thread slots', which
|
2018-06-01 18:19:39 +02:00
|
|
|
* then can be filled in a loop with an idle timer.
|
2012-03-03 20:19:11 +00:00
|
|
|
*
|
|
|
|
* A sample loop can look like this (pseudo c);
|
|
|
|
*
|
2020-09-07 15:57:12 +10:00
|
|
|
* \code{.c}
|
2018-06-01 18:19:39 +02:00
|
|
|
*
|
2020-09-07 15:57:12 +10:00
|
|
|
* ListBase lb;
|
|
|
|
* int max_threads = 2;
|
|
|
|
* int cont = 1;
|
2018-06-01 18:19:39 +02:00
|
|
|
*
|
2020-09-07 15:57:12 +10:00
|
|
|
* BLI_threadpool_init(&lb, do_something_func, max_threads);
|
|
|
|
*
|
|
|
|
* while (cont) {
|
|
|
|
* if (BLI_available_threads(&lb) && !(escape loop event)) {
|
|
|
|
* // get new job (data pointer)
|
|
|
|
* // tag job 'processed
|
|
|
|
* BLI_threadpool_insert(&lb, job);
|
|
|
|
* }
|
|
|
|
* else PIL_sleep_ms(50);
|
2018-06-01 18:19:39 +02:00
|
|
|
*
|
2020-09-07 15:57:12 +10:00
|
|
|
* // Find if a job is ready, this the do_something_func() should write in job somewhere.
|
|
|
|
* cont = 0;
|
|
|
|
* for (go over all jobs)
|
|
|
|
* if (job is ready) {
|
|
|
|
* if (job was not removed) {
|
|
|
|
* BLI_threadpool_remove(&lb, job);
|
2012-03-03 20:19:11 +00:00
|
|
|
* }
|
2020-09-07 15:57:12 +10:00
|
|
|
* }
|
|
|
|
* else cont = 1;
|
2012-03-03 20:19:11 +00:00
|
|
|
* }
|
2020-09-07 15:57:12 +10:00
|
|
|
* // Conditions to exit loop.
|
|
|
|
* if (if escape loop event) {
|
|
|
|
* if (BLI_available_threadslots(&lb) == max_threads) {
|
|
|
|
* break;
|
|
|
|
* }
|
|
|
|
* }
|
|
|
|
* }
|
2018-06-01 18:19:39 +02:00
|
|
|
*
|
2020-09-07 15:57:12 +10:00
|
|
|
* BLI_threadpool_end(&lb);
|
2012-03-03 20:19:11 +00:00
|
|
|
*
|
2020-09-07 15:57:12 +10:00
|
|
|
* \endcode
|
|
|
|
*/
|
2006-12-21 15:44:46 +00:00
|
|
|
static pthread_mutex_t _image_lock = PTHREAD_MUTEX_INITIALIZER;
|
2012-07-13 13:47:13 +00:00
|
|
|
static pthread_mutex_t _image_draw_lock = PTHREAD_MUTEX_INITIALIZER;
|
2010-03-16 16:58:45 +00:00
|
|
|
static pthread_mutex_t _viewer_lock = PTHREAD_MUTEX_INITIALIZER;
|
2006-03-13 11:01:17 +00:00
|
|
|
static pthread_mutex_t _custom1_lock = PTHREAD_MUTEX_INITIALIZER;
|
2011-10-31 17:00:59 +00:00
|
|
|
static pthread_mutex_t _nodes_lock = PTHREAD_MUTEX_INITIALIZER;
|
2011-11-07 12:55:18 +00:00
|
|
|
static pthread_mutex_t _movieclip_lock = PTHREAD_MUTEX_INITIALIZER;
|
Color Management, Stage 2: Switch color pipeline to use OpenColorIO
Replace old color pipeline which was supporting linear/sRGB color spaces
only with OpenColorIO-based pipeline.
This introduces two configurable color spaces:
- Input color space for images and movie clips. This space is used to convert
images/movies from color space in which file is saved to Blender's linear
space (for float images, byte images are not internally converted, only input
space is stored for such images and used later).
This setting could be found in image/clip data block settings.
- Display color space which defines space in which particular display is working.
This settings could be found in scene's Color Management panel.
When render result is being displayed on the screen, apart from converting image
to display space, some additional conversions could happen.
This conversions are:
- View, which defines tone curve applying before display transformation.
These are different ways to view the image on the same display device.
For example it could be used to emulate film view on sRGB display.
- Exposure affects on image exposure before tone map is applied.
- Gamma is post-display gamma correction, could be used to match particular
display gamma.
- RGB curves are user-defined curves which are applying before display
transformation, could be used for different purposes.
All this settings by default are only applying on render result and does not
affect on other images. If some particular image needs to be affected by this
transformation, "View as Render" setting of image data block should be set to
truth. Movie clips are always affected by all display transformations.
This commit also introduces configurable color space in which sequencer is
working. This setting could be found in scene's Color Management panel and
it should be used if such stuff as grading needs to be done in color space
different from sRGB (i.e. when Film view on sRGB display is use, using VD16
space as sequencer's internal space would make grading working in space
which is close to the space using for display).
Some technical notes:
- Image buffer's float buffer is now always in linear space, even if it was
created from 16bit byte images.
- Space of byte buffer is stored in image buffer's rect_colorspace property.
- Profile of image buffer was removed since it's not longer meaningful.
- OpenGL and GLSL is supposed to always work in sRGB space. It is possible
to support other spaces, but it's quite large project which isn't so
much important.
- Legacy Color Management option disabled is emulated by using None display.
It could have some regressions, but there's no clear way to avoid them.
- If OpenColorIO is disabled on build time, it should make blender behaving
in the same way as previous release with color management enabled.
More details could be found at this page (more details would be added soon):
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management
--
Thanks to Xavier Thomas, Lukas Toene for initial work on OpenColorIO
integration and to Brecht van Lommel for some further development and code/
usecase review!
2012-09-15 10:05:07 +00:00
|
|
|
static pthread_mutex_t _colormanage_lock = PTHREAD_MUTEX_INITIALIZER;
|
2014-03-01 20:46:58 +01:00
|
|
|
static pthread_mutex_t _fftw_lock = PTHREAD_MUTEX_INITIALIZER;
|
2015-04-06 10:40:12 -03:00
|
|
|
static pthread_mutex_t _view3d_lock = PTHREAD_MUTEX_INITIALIZER;
|
2010-04-13 12:51:03 +00:00
|
|
|
static pthread_t mainid;
|
2018-11-27 18:21:43 +01:00
|
|
|
static bool is_numa_available = false;
|
2017-03-02 09:56:25 +01:00
|
|
|
static unsigned int thread_levels = 0; /* threads can be invoked inside threads */
|
2013-05-08 13:23:17 +00:00
|
|
|
static int num_threads_override = 0;
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
|
|
|
|
/* just a max for security reasons */
|
2010-01-28 19:18:35 +00:00
|
|
|
#define RE_MAX_THREAD BLENDER_MAX_THREADS
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
|
2020-12-04 12:46:43 +01:00
|
|
|
struct ThreadSlot {
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
struct ThreadSlot *next, *prev;
|
2006-02-25 11:56:08 +00:00
|
|
|
void *(*do_thread)(void *);
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
void *callerdata;
|
2006-02-25 11:56:08 +00:00
|
|
|
pthread_t pthread;
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
int avail;
|
2020-12-04 12:46:43 +01:00
|
|
|
};
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
|
2010-04-13 12:51:03 +00:00
|
|
|
void BLI_threadapi_init(void)
|
|
|
|
{
|
|
|
|
mainid = pthread_self();
|
2018-11-27 18:21:43 +01:00
|
|
|
if (numaAPI_Initialize() == NUMAAPI_SUCCESS) {
|
|
|
|
is_numa_available = true;
|
|
|
|
}
|
2013-08-19 10:51:40 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_threadapi_exit(void)
|
|
|
|
{
|
2010-04-13 12:51:03 +00:00
|
|
|
}
|
|
|
|
|
2007-11-25 16:35:33 +00:00
|
|
|
/* tot = 0 only initializes malloc mutex in a safe way (see sequence.c)
|
2012-03-03 20:19:11 +00:00
|
|
|
* problem otherwise: scene render will kill of the mutex!
|
|
|
|
*/
|
2007-11-25 16:35:33 +00:00
|
|
|
|
2018-02-16 01:13:46 +11:00
|
|
|
void BLI_threadpool_init(ListBase *threadbase, void *(*do_thread)(void *), int tot)
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
{
|
|
|
|
int a;
|
2010-04-13 12:51:03 +00:00
|
|
|
|
2020-07-02 16:19:18 +02:00
|
|
|
if (threadbase != nullptr && tot > 0) {
|
2014-02-08 06:07:10 +11:00
|
|
|
BLI_listbase_clear(threadbase);
|
2018-06-17 16:32:54 +02:00
|
|
|
|
2019-03-27 13:16:10 +11:00
|
|
|
if (tot > RE_MAX_THREAD) {
|
|
|
|
tot = RE_MAX_THREAD;
|
|
|
|
}
|
|
|
|
else if (tot < 1) {
|
|
|
|
tot = 1;
|
|
|
|
}
|
2018-06-17 16:32:54 +02:00
|
|
|
|
2012-05-12 15:02:10 +00:00
|
|
|
for (a = 0; a < tot; a++) {
|
2020-07-02 16:19:18 +02:00
|
|
|
ThreadSlot *tslot = static_cast<ThreadSlot *>(MEM_callocN(sizeof(ThreadSlot), "threadslot"));
|
2007-11-25 16:35:33 +00:00
|
|
|
BLI_addtail(threadbase, tslot);
|
2012-05-12 15:02:10 +00:00
|
|
|
tslot->do_thread = do_thread;
|
|
|
|
tslot->avail = 1;
|
2007-11-25 16:35:33 +00:00
|
|
|
}
|
2010-06-22 15:17:12 +00:00
|
|
|
}
|
2017-03-02 09:56:25 +01:00
|
|
|
|
|
|
|
unsigned int level = atomic_fetch_and_add_u(&thread_levels, 1);
|
|
|
|
if (level == 0) {
|
2013-05-20 16:15:16 +00:00
|
|
|
#ifdef USE_APPLE_OMP_FIX
|
2020-07-06 21:03:45 +10:00
|
|
|
/* Workaround for Apple gcc 4.2.1 OMP vs background thread bug,
|
|
|
|
* we copy GOMP thread local storage pointer to setting it again
|
|
|
|
* inside the thread that we start. */
|
2010-06-22 15:17:12 +00:00
|
|
|
thread_tls_data = pthread_getspecific(gomp_tls_key);
|
2010-03-09 16:54:25 +00:00
|
|
|
#endif
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* amount of available threads */
|
|
|
|
int BLI_available_threads(ListBase *threadbase)
|
|
|
|
{
|
2012-05-12 15:02:10 +00:00
|
|
|
int counter = 0;
|
2018-06-17 16:32:54 +02:00
|
|
|
|
2020-07-02 16:19:18 +02:00
|
|
|
LISTBASE_FOREACH (ThreadSlot *, tslot, threadbase) {
|
2019-03-27 13:16:10 +11:00
|
|
|
if (tslot->avail) {
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
counter++;
|
2019-03-27 13:16:10 +11:00
|
|
|
}
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
}
|
2020-07-02 16:19:18 +02:00
|
|
|
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
return counter;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* returns thread number, for sample patterns or threadsafe tables */
|
2018-02-16 01:13:46 +11:00
|
|
|
int BLI_threadpool_available_thread_index(ListBase *threadbase)
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
{
|
2012-05-12 15:02:10 +00:00
|
|
|
int counter = 0;
|
2018-06-17 16:32:54 +02:00
|
|
|
|
2020-07-02 16:19:18 +02:00
|
|
|
LISTBASE_FOREACH (ThreadSlot *, tslot, threadbase) {
|
2019-03-27 13:16:10 +11:00
|
|
|
if (tslot->avail) {
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
return counter;
|
2019-03-27 13:16:10 +11:00
|
|
|
}
|
2020-07-02 16:19:18 +02:00
|
|
|
++counter;
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
}
|
2020-07-02 16:19:18 +02:00
|
|
|
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-03-09 16:54:25 +00:00
|
|
|
static void *tslot_thread_start(void *tslot_p)
|
|
|
|
{
|
2012-05-12 15:02:10 +00:00
|
|
|
ThreadSlot *tslot = (ThreadSlot *)tslot_p;
|
2010-03-09 16:54:25 +00:00
|
|
|
|
2013-05-20 16:15:16 +00:00
|
|
|
#ifdef USE_APPLE_OMP_FIX
|
2020-07-07 12:44:47 +10:00
|
|
|
/* Workaround for Apple gcc 4.2.1 OMP vs background thread bug,
|
|
|
|
* set GOMP thread local storage pointer which was copied beforehand */
|
2012-05-12 15:02:10 +00:00
|
|
|
pthread_setspecific(gomp_tls_key, thread_tls_data);
|
2010-03-09 16:54:25 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
return tslot->do_thread(tslot->callerdata);
|
|
|
|
}
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
|
2011-09-28 05:53:40 +00:00
|
|
|
int BLI_thread_is_main(void)
|
|
|
|
{
|
2010-05-27 12:40:12 +00:00
|
|
|
return pthread_equal(pthread_self(), mainid);
|
2010-04-13 12:51:03 +00:00
|
|
|
}
|
|
|
|
|
2018-02-16 01:13:46 +11:00
|
|
|
void BLI_threadpool_insert(ListBase *threadbase, void *callerdata)
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
{
|
2020-07-02 16:19:18 +02:00
|
|
|
LISTBASE_FOREACH (ThreadSlot *, tslot, threadbase) {
|
2012-03-24 06:18:31 +00:00
|
|
|
if (tslot->avail) {
|
2012-05-12 15:02:10 +00:00
|
|
|
tslot->avail = 0;
|
|
|
|
tslot->callerdata = callerdata;
|
2020-07-02 16:19:18 +02:00
|
|
|
pthread_create(&tslot->pthread, nullptr, tslot_thread_start, tslot);
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
printf("ERROR: could not insert thread slot\n");
|
|
|
|
}
|
|
|
|
|
2018-02-16 01:13:46 +11:00
|
|
|
void BLI_threadpool_remove(ListBase *threadbase, void *callerdata)
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
{
|
2020-07-02 16:19:18 +02:00
|
|
|
LISTBASE_FOREACH (ThreadSlot *, tslot, threadbase) {
|
2012-05-12 15:02:10 +00:00
|
|
|
if (tslot->callerdata == callerdata) {
|
2020-07-02 16:19:18 +02:00
|
|
|
pthread_join(tslot->pthread, nullptr);
|
|
|
|
tslot->callerdata = nullptr;
|
2012-05-12 15:02:10 +00:00
|
|
|
tslot->avail = 1;
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-02-16 01:13:46 +11:00
|
|
|
void BLI_threadpool_remove_index(ListBase *threadbase, int index)
|
2008-08-14 23:48:52 +00:00
|
|
|
{
|
2012-05-12 15:02:10 +00:00
|
|
|
int counter = 0;
|
2018-06-17 16:32:54 +02:00
|
|
|
|
2020-07-02 16:19:18 +02:00
|
|
|
LISTBASE_FOREACH (ThreadSlot *, tslot, threadbase) {
|
2008-08-14 23:48:52 +00:00
|
|
|
if (counter == index && tslot->avail == 0) {
|
2020-07-02 16:19:18 +02:00
|
|
|
pthread_join(tslot->pthread, nullptr);
|
|
|
|
tslot->callerdata = nullptr;
|
2008-08-14 23:48:52 +00:00
|
|
|
tslot->avail = 1;
|
|
|
|
break;
|
|
|
|
}
|
2020-07-02 16:19:18 +02:00
|
|
|
++counter;
|
2008-08-14 23:48:52 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-02-16 01:13:46 +11:00
|
|
|
void BLI_threadpool_clear(ListBase *threadbase)
|
2008-09-25 20:29:15 +00:00
|
|
|
{
|
2020-07-02 16:19:18 +02:00
|
|
|
LISTBASE_FOREACH (ThreadSlot *, tslot, threadbase) {
|
2008-09-25 20:29:15 +00:00
|
|
|
if (tslot->avail == 0) {
|
2020-07-02 16:19:18 +02:00
|
|
|
pthread_join(tslot->pthread, nullptr);
|
|
|
|
tslot->callerdata = nullptr;
|
2008-09-25 20:29:15 +00:00
|
|
|
tslot->avail = 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-02-16 01:13:46 +11:00
|
|
|
void BLI_threadpool_end(ListBase *threadbase)
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
{
|
2018-06-17 16:32:54 +02:00
|
|
|
|
2021-01-20 15:15:38 +11:00
|
|
|
/* Only needed if there's actually some stuff to end
|
|
|
|
* this way we don't end up decrementing thread_levels on an empty `threadbase`. */
|
2020-07-02 16:19:18 +02:00
|
|
|
if (threadbase == nullptr || BLI_listbase_is_empty(threadbase)) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
LISTBASE_FOREACH (ThreadSlot *, tslot, threadbase) {
|
|
|
|
if (tslot->avail == 0) {
|
|
|
|
pthread_join(tslot->pthread, nullptr);
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
}
|
|
|
|
}
|
2020-07-02 16:19:18 +02:00
|
|
|
BLI_freelistN(threadbase);
|
2006-01-30 11:09:50 +00:00
|
|
|
}
|
|
|
|
|
2009-09-30 18:18:32 +00:00
|
|
|
/* System Information */
|
2006-02-11 15:55:00 +00:00
|
|
|
|
2008-02-19 22:23:21 +00:00
|
|
|
/* how many threads are native on this system? */
|
2012-04-29 17:11:40 +00:00
|
|
|
int BLI_system_thread_count(void)
|
2008-02-19 22:23:21 +00:00
|
|
|
{
|
2015-06-20 22:10:30 +02:00
|
|
|
static int t = -1;
|
|
|
|
|
|
|
|
if (num_threads_override != 0) {
|
|
|
|
return num_threads_override;
|
|
|
|
}
|
2020-08-07 11:23:02 +02:00
|
|
|
if (LIKELY(t != -1)) {
|
2015-06-20 22:10:30 +02:00
|
|
|
return t;
|
|
|
|
}
|
|
|
|
|
|
|
|
{
|
2008-02-19 22:59:52 +00:00
|
|
|
#ifdef WIN32
|
2015-06-20 22:10:30 +02:00
|
|
|
SYSTEM_INFO info;
|
|
|
|
GetSystemInfo(&info);
|
|
|
|
t = (int)info.dwNumberOfProcessors;
|
2018-06-17 16:32:54 +02:00
|
|
|
#else
|
2012-05-12 15:02:10 +00:00
|
|
|
# ifdef __APPLE__
|
2015-06-20 22:10:30 +02:00
|
|
|
int mib[2];
|
|
|
|
size_t len;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-06-20 22:10:30 +02:00
|
|
|
mib[0] = CTL_HW;
|
|
|
|
mib[1] = HW_NCPU;
|
|
|
|
len = sizeof(t);
|
2020-07-02 16:19:18 +02:00
|
|
|
sysctl(mib, 2, &t, &len, nullptr, 0);
|
2012-05-12 15:02:10 +00:00
|
|
|
# else
|
2015-06-20 22:10:30 +02:00
|
|
|
t = (int)sysconf(_SC_NPROCESSORS_ONLN);
|
2012-05-12 15:02:10 +00:00
|
|
|
# endif
|
2008-02-19 22:59:52 +00:00
|
|
|
#endif
|
2015-06-20 22:10:30 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
CLAMP(t, 1, RE_MAX_THREAD);
|
2013-05-08 13:23:17 +00:00
|
|
|
|
2008-02-19 22:23:21 +00:00
|
|
|
return t;
|
|
|
|
}
|
|
|
|
|
2013-05-08 13:23:17 +00:00
|
|
|
void BLI_system_num_threads_override_set(int num)
|
|
|
|
{
|
|
|
|
num_threads_override = num;
|
|
|
|
}
|
|
|
|
|
|
|
|
int BLI_system_num_threads_override_get(void)
|
|
|
|
{
|
|
|
|
return num_threads_override;
|
|
|
|
}
|
|
|
|
|
2009-09-30 18:18:32 +00:00
|
|
|
/* Global Mutex Locks */
|
|
|
|
|
2015-08-10 15:03:31 +02:00
|
|
|
static ThreadMutex *global_mutex_from_type(const int type)
|
|
|
|
{
|
|
|
|
switch (type) {
|
|
|
|
case LOCK_IMAGE:
|
|
|
|
return &_image_lock;
|
|
|
|
case LOCK_DRAW_IMAGE:
|
|
|
|
return &_image_draw_lock;
|
|
|
|
case LOCK_VIEWER:
|
|
|
|
return &_viewer_lock;
|
|
|
|
case LOCK_CUSTOM1:
|
|
|
|
return &_custom1_lock;
|
|
|
|
case LOCK_NODES:
|
|
|
|
return &_nodes_lock;
|
|
|
|
case LOCK_MOVIECLIP:
|
|
|
|
return &_movieclip_lock;
|
|
|
|
case LOCK_COLORMANAGE:
|
|
|
|
return &_colormanage_lock;
|
|
|
|
case LOCK_FFTW:
|
|
|
|
return &_fftw_lock;
|
|
|
|
case LOCK_VIEW3D:
|
|
|
|
return &_view3d_lock;
|
|
|
|
default:
|
|
|
|
BLI_assert(0);
|
2020-07-02 16:19:18 +02:00
|
|
|
return nullptr;
|
2015-08-10 15:03:31 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-02-16 01:13:46 +11:00
|
|
|
void BLI_thread_lock(int type)
|
2009-09-30 18:18:32 +00:00
|
|
|
{
|
2015-08-10 15:03:31 +02:00
|
|
|
pthread_mutex_lock(global_mutex_from_type(type));
|
2009-09-30 18:18:32 +00:00
|
|
|
}
|
|
|
|
|
2018-02-16 01:13:46 +11:00
|
|
|
void BLI_thread_unlock(int type)
|
2009-09-30 18:18:32 +00:00
|
|
|
{
|
2015-08-10 15:03:31 +02:00
|
|
|
pthread_mutex_unlock(global_mutex_from_type(type));
|
2009-09-30 18:18:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Mutex Locks */
|
|
|
|
|
|
|
|
void BLI_mutex_init(ThreadMutex *mutex)
|
|
|
|
{
|
2020-07-02 16:19:18 +02:00
|
|
|
pthread_mutex_init(mutex, nullptr);
|
2009-09-30 18:18:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_mutex_lock(ThreadMutex *mutex)
|
|
|
|
{
|
|
|
|
pthread_mutex_lock(mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_mutex_unlock(ThreadMutex *mutex)
|
|
|
|
{
|
|
|
|
pthread_mutex_unlock(mutex);
|
|
|
|
}
|
|
|
|
|
2013-10-12 14:08:59 +00:00
|
|
|
bool BLI_mutex_trylock(ThreadMutex *mutex)
|
|
|
|
{
|
|
|
|
return (pthread_mutex_trylock(mutex) == 0);
|
|
|
|
}
|
|
|
|
|
2009-09-30 18:18:32 +00:00
|
|
|
void BLI_mutex_end(ThreadMutex *mutex)
|
|
|
|
{
|
|
|
|
pthread_mutex_destroy(mutex);
|
|
|
|
}
|
|
|
|
|
2013-04-24 17:31:09 +00:00
|
|
|
ThreadMutex *BLI_mutex_alloc(void)
|
|
|
|
{
|
2020-07-02 16:19:18 +02:00
|
|
|
ThreadMutex *mutex = static_cast<ThreadMutex *>(MEM_callocN(sizeof(ThreadMutex), "ThreadMutex"));
|
2013-04-24 17:31:09 +00:00
|
|
|
BLI_mutex_init(mutex);
|
|
|
|
return mutex;
|
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_mutex_free(ThreadMutex *mutex)
|
|
|
|
{
|
|
|
|
BLI_mutex_end(mutex);
|
|
|
|
MEM_freeN(mutex);
|
|
|
|
}
|
|
|
|
|
2012-11-15 15:59:58 +00:00
|
|
|
/* Spin Locks */
|
|
|
|
|
2020-07-06 17:35:41 +10:00
|
|
|
#ifdef WITH_TBB
|
2020-07-02 16:40:30 +02:00
|
|
|
static tbb::spin_mutex *tbb_spin_mutex_cast(SpinLock *spin)
|
|
|
|
{
|
|
|
|
static_assert(sizeof(SpinLock) >= sizeof(tbb::spin_mutex),
|
|
|
|
"SpinLock must match tbb::spin_mutex");
|
|
|
|
static_assert(alignof(SpinLock) % alignof(tbb::spin_mutex) == 0,
|
|
|
|
"SpinLock must be aligned same as tbb::spin_mutex");
|
|
|
|
return reinterpret_cast<tbb::spin_mutex *>(spin);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2012-11-15 15:59:58 +00:00
|
|
|
void BLI_spin_init(SpinLock *spin)
|
|
|
|
{
|
2020-07-02 16:40:30 +02:00
|
|
|
#ifdef WITH_TBB
|
|
|
|
tbb::spin_mutex *spin_mutex = tbb_spin_mutex_cast(spin);
|
|
|
|
new (spin_mutex) tbb::spin_mutex();
|
|
|
|
#elif defined(__APPLE__)
|
|
|
|
BLI_mutex_init(spin);
|
2017-11-14 12:21:15 +01:00
|
|
|
#elif defined(_MSC_VER)
|
|
|
|
*spin = 0;
|
2012-11-15 15:59:58 +00:00
|
|
|
#else
|
|
|
|
pthread_spin_init(spin, 0);
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_spin_lock(SpinLock *spin)
|
|
|
|
{
|
2020-07-02 16:40:30 +02:00
|
|
|
#ifdef WITH_TBB
|
|
|
|
tbb::spin_mutex *spin_mutex = tbb_spin_mutex_cast(spin);
|
|
|
|
spin_mutex->lock();
|
|
|
|
#elif defined(__APPLE__)
|
|
|
|
BLI_mutex_lock(spin);
|
2017-11-14 12:21:15 +01:00
|
|
|
#elif defined(_MSC_VER)
|
|
|
|
while (InterlockedExchangeAcquire(spin, 1)) {
|
|
|
|
while (*spin) {
|
2021-02-05 16:23:34 +11:00
|
|
|
/* Spin-lock hint for processors with hyper-threading. */
|
2018-05-26 22:29:10 +02:00
|
|
|
YieldProcessor();
|
2017-11-14 12:21:15 +01:00
|
|
|
}
|
|
|
|
}
|
2012-11-15 15:59:58 +00:00
|
|
|
#else
|
|
|
|
pthread_spin_lock(spin);
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_spin_unlock(SpinLock *spin)
|
|
|
|
{
|
2020-07-02 16:40:30 +02:00
|
|
|
#ifdef WITH_TBB
|
|
|
|
tbb::spin_mutex *spin_mutex = tbb_spin_mutex_cast(spin);
|
|
|
|
spin_mutex->unlock();
|
|
|
|
#elif defined(__APPLE__)
|
|
|
|
BLI_mutex_unlock(spin);
|
2017-11-14 12:21:15 +01:00
|
|
|
#elif defined(_MSC_VER)
|
|
|
|
_ReadWriteBarrier();
|
|
|
|
*spin = 0;
|
2012-11-15 15:59:58 +00:00
|
|
|
#else
|
|
|
|
pthread_spin_unlock(spin);
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2017-11-20 23:32:06 +01:00
|
|
|
void BLI_spin_end(SpinLock *spin)
|
|
|
|
{
|
2020-07-02 16:40:30 +02:00
|
|
|
#ifdef WITH_TBB
|
|
|
|
tbb::spin_mutex *spin_mutex = tbb_spin_mutex_cast(spin);
|
|
|
|
spin_mutex->~spin_mutex();
|
|
|
|
#elif defined(__APPLE__)
|
|
|
|
BLI_mutex_end(spin);
|
|
|
|
#elif defined(_MSC_VER)
|
2020-07-07 16:17:36 +02:00
|
|
|
/* Nothing to do, spin is a simple integer type. */
|
2020-07-02 16:40:30 +02:00
|
|
|
#else
|
2017-11-14 12:21:15 +01:00
|
|
|
pthread_spin_destroy(spin);
|
2017-11-20 23:32:06 +01:00
|
|
|
#endif
|
2020-07-02 16:40:30 +02:00
|
|
|
}
|
2012-11-15 15:59:58 +00:00
|
|
|
|
2009-09-30 18:18:32 +00:00
|
|
|
/* Read/Write Mutex Lock */
|
|
|
|
|
|
|
|
void BLI_rw_mutex_init(ThreadRWMutex *mutex)
|
|
|
|
{
|
2020-07-02 16:19:18 +02:00
|
|
|
pthread_rwlock_init(mutex, nullptr);
|
2009-09-30 18:18:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_rw_mutex_lock(ThreadRWMutex *mutex, int mode)
|
|
|
|
{
|
2019-03-27 13:16:10 +11:00
|
|
|
if (mode == THREAD_LOCK_READ) {
|
2009-09-30 18:18:32 +00:00
|
|
|
pthread_rwlock_rdlock(mutex);
|
2019-03-27 13:16:10 +11:00
|
|
|
}
|
|
|
|
else {
|
2009-09-30 18:18:32 +00:00
|
|
|
pthread_rwlock_wrlock(mutex);
|
2019-03-27 13:16:10 +11:00
|
|
|
}
|
2009-09-30 18:18:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_rw_mutex_unlock(ThreadRWMutex *mutex)
|
|
|
|
{
|
|
|
|
pthread_rwlock_unlock(mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_rw_mutex_end(ThreadRWMutex *mutex)
|
|
|
|
{
|
|
|
|
pthread_rwlock_destroy(mutex);
|
|
|
|
}
|
|
|
|
|
2013-04-24 17:31:09 +00:00
|
|
|
ThreadRWMutex *BLI_rw_mutex_alloc(void)
|
|
|
|
{
|
2020-07-02 16:19:18 +02:00
|
|
|
ThreadRWMutex *mutex = static_cast<ThreadRWMutex *>(
|
|
|
|
MEM_callocN(sizeof(ThreadRWMutex), "ThreadRWMutex"));
|
2013-04-24 17:31:09 +00:00
|
|
|
BLI_rw_mutex_init(mutex);
|
|
|
|
return mutex;
|
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_rw_mutex_free(ThreadRWMutex *mutex)
|
|
|
|
{
|
|
|
|
BLI_rw_mutex_end(mutex);
|
|
|
|
MEM_freeN(mutex);
|
|
|
|
}
|
|
|
|
|
2013-07-08 17:56:51 +00:00
|
|
|
/* Ticket Mutex Lock */
|
|
|
|
|
|
|
|
struct TicketMutex {
|
|
|
|
pthread_cond_t cond;
|
|
|
|
pthread_mutex_t mutex;
|
|
|
|
unsigned int queue_head, queue_tail;
|
|
|
|
};
|
|
|
|
|
|
|
|
TicketMutex *BLI_ticket_mutex_alloc(void)
|
|
|
|
{
|
2020-07-02 16:19:18 +02:00
|
|
|
TicketMutex *ticket = static_cast<TicketMutex *>(
|
|
|
|
MEM_callocN(sizeof(TicketMutex), "TicketMutex"));
|
2013-07-08 17:56:51 +00:00
|
|
|
|
2020-07-02 16:19:18 +02:00
|
|
|
pthread_cond_init(&ticket->cond, nullptr);
|
|
|
|
pthread_mutex_init(&ticket->mutex, nullptr);
|
2013-07-08 17:56:51 +00:00
|
|
|
|
|
|
|
return ticket;
|
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_ticket_mutex_free(TicketMutex *ticket)
|
|
|
|
{
|
|
|
|
pthread_mutex_destroy(&ticket->mutex);
|
|
|
|
pthread_cond_destroy(&ticket->cond);
|
|
|
|
MEM_freeN(ticket);
|
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_ticket_mutex_lock(TicketMutex *ticket)
|
|
|
|
{
|
|
|
|
unsigned int queue_me;
|
|
|
|
|
|
|
|
pthread_mutex_lock(&ticket->mutex);
|
|
|
|
queue_me = ticket->queue_tail++;
|
|
|
|
|
2019-03-27 13:16:10 +11:00
|
|
|
while (queue_me != ticket->queue_head) {
|
2013-07-08 17:56:51 +00:00
|
|
|
pthread_cond_wait(&ticket->cond, &ticket->mutex);
|
2019-03-27 13:16:10 +11:00
|
|
|
}
|
2013-07-08 17:56:51 +00:00
|
|
|
|
|
|
|
pthread_mutex_unlock(&ticket->mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_ticket_mutex_unlock(TicketMutex *ticket)
|
|
|
|
{
|
|
|
|
pthread_mutex_lock(&ticket->mutex);
|
|
|
|
ticket->queue_head++;
|
|
|
|
pthread_cond_broadcast(&ticket->cond);
|
|
|
|
pthread_mutex_unlock(&ticket->mutex);
|
|
|
|
}
|
|
|
|
|
2008-08-16 22:47:33 +00:00
|
|
|
/* ************************************************ */
|
|
|
|
|
2013-10-12 14:08:59 +00:00
|
|
|
/* Condition */
|
2008-08-16 22:47:33 +00:00
|
|
|
|
2013-10-12 14:08:59 +00:00
|
|
|
void BLI_condition_init(ThreadCondition *cond)
|
2008-08-16 22:47:33 +00:00
|
|
|
{
|
2020-07-02 16:19:18 +02:00
|
|
|
pthread_cond_init(cond, nullptr);
|
2008-08-16 22:47:33 +00:00
|
|
|
}
|
|
|
|
|
2013-10-12 14:08:59 +00:00
|
|
|
void BLI_condition_wait(ThreadCondition *cond, ThreadMutex *mutex)
|
2008-08-16 22:47:33 +00:00
|
|
|
{
|
2013-10-12 14:08:59 +00:00
|
|
|
pthread_cond_wait(cond, mutex);
|
2008-08-16 22:47:33 +00:00
|
|
|
}
|
|
|
|
|
2015-08-10 15:03:31 +02:00
|
|
|
void BLI_condition_wait_global_mutex(ThreadCondition *cond, const int type)
|
|
|
|
{
|
|
|
|
pthread_cond_wait(cond, global_mutex_from_type(type));
|
|
|
|
}
|
|
|
|
|
2013-10-12 14:08:59 +00:00
|
|
|
void BLI_condition_notify_one(ThreadCondition *cond)
|
2008-08-16 22:47:33 +00:00
|
|
|
{
|
2013-10-12 14:08:59 +00:00
|
|
|
pthread_cond_signal(cond);
|
2008-08-16 22:47:33 +00:00
|
|
|
}
|
|
|
|
|
2013-10-12 14:08:59 +00:00
|
|
|
void BLI_condition_notify_all(ThreadCondition *cond)
|
2008-08-16 22:47:33 +00:00
|
|
|
{
|
2013-10-12 14:08:59 +00:00
|
|
|
pthread_cond_broadcast(cond);
|
2008-08-16 22:47:33 +00:00
|
|
|
}
|
|
|
|
|
2013-10-12 14:08:59 +00:00
|
|
|
void BLI_condition_end(ThreadCondition *cond)
|
2008-08-16 22:47:33 +00:00
|
|
|
{
|
2013-10-12 14:08:59 +00:00
|
|
|
pthread_cond_destroy(cond);
|
2008-08-16 22:47:33 +00:00
|
|
|
}
|
|
|
|
|
2010-01-22 11:06:57 +00:00
|
|
|
/* ************************************************ */
|
|
|
|
|
|
|
|
struct ThreadQueue {
|
|
|
|
GSQueue *queue;
|
|
|
|
pthread_mutex_t mutex;
|
2012-06-10 12:26:33 +00:00
|
|
|
pthread_cond_t push_cond;
|
|
|
|
pthread_cond_t finish_cond;
|
|
|
|
volatile int nowait;
|
2013-10-26 01:06:19 +00:00
|
|
|
volatile int canceled;
|
2010-01-22 11:06:57 +00:00
|
|
|
};
|
|
|
|
|
2011-02-13 15:02:21 +00:00
|
|
|
ThreadQueue *BLI_thread_queue_init(void)
|
2010-01-22 11:06:57 +00:00
|
|
|
{
|
|
|
|
ThreadQueue *queue;
|
|
|
|
|
2020-07-02 16:19:18 +02:00
|
|
|
queue = static_cast<ThreadQueue *>(MEM_callocN(sizeof(ThreadQueue), "ThreadQueue"));
|
2012-05-12 15:02:10 +00:00
|
|
|
queue->queue = BLI_gsqueue_new(sizeof(void *));
|
2010-01-22 11:06:57 +00:00
|
|
|
|
2020-07-02 16:19:18 +02:00
|
|
|
pthread_mutex_init(&queue->mutex, nullptr);
|
|
|
|
pthread_cond_init(&queue->push_cond, nullptr);
|
|
|
|
pthread_cond_init(&queue->finish_cond, nullptr);
|
2010-01-22 11:06:57 +00:00
|
|
|
|
|
|
|
return queue;
|
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_thread_queue_free(ThreadQueue *queue)
|
|
|
|
{
|
2012-06-10 12:26:33 +00:00
|
|
|
/* destroy everything, assumes no one is using queue anymore */
|
|
|
|
pthread_cond_destroy(&queue->finish_cond);
|
|
|
|
pthread_cond_destroy(&queue->push_cond);
|
2010-01-22 11:06:57 +00:00
|
|
|
pthread_mutex_destroy(&queue->mutex);
|
|
|
|
|
|
|
|
BLI_gsqueue_free(queue->queue);
|
|
|
|
|
|
|
|
MEM_freeN(queue);
|
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_thread_queue_push(ThreadQueue *queue, void *work)
|
|
|
|
{
|
|
|
|
pthread_mutex_lock(&queue->mutex);
|
|
|
|
|
|
|
|
BLI_gsqueue_push(queue->queue, &work);
|
|
|
|
|
|
|
|
/* signal threads waiting to pop */
|
2012-06-10 12:26:33 +00:00
|
|
|
pthread_cond_signal(&queue->push_cond);
|
2010-01-22 11:06:57 +00:00
|
|
|
pthread_mutex_unlock(&queue->mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
void *BLI_thread_queue_pop(ThreadQueue *queue)
|
|
|
|
{
|
2020-07-02 16:19:18 +02:00
|
|
|
void *work = nullptr;
|
2010-01-22 11:06:57 +00:00
|
|
|
|
|
|
|
/* wait until there is work */
|
|
|
|
pthread_mutex_lock(&queue->mutex);
|
2019-03-27 13:16:10 +11:00
|
|
|
while (BLI_gsqueue_is_empty(queue->queue) && !queue->nowait) {
|
2012-06-10 12:26:33 +00:00
|
|
|
pthread_cond_wait(&queue->push_cond, &queue->mutex);
|
2019-03-27 13:16:10 +11:00
|
|
|
}
|
2018-06-17 16:32:54 +02:00
|
|
|
|
2010-01-22 11:06:57 +00:00
|
|
|
/* if we have something, pop it */
|
2012-06-10 12:26:33 +00:00
|
|
|
if (!BLI_gsqueue_is_empty(queue->queue)) {
|
2010-01-22 11:06:57 +00:00
|
|
|
BLI_gsqueue_pop(queue->queue, &work);
|
2018-06-17 16:32:54 +02:00
|
|
|
|
2019-03-27 13:16:10 +11:00
|
|
|
if (BLI_gsqueue_is_empty(queue->queue)) {
|
2012-06-10 12:26:33 +00:00
|
|
|
pthread_cond_broadcast(&queue->finish_cond);
|
2019-03-27 13:16:10 +11:00
|
|
|
}
|
2012-06-10 12:26:33 +00:00
|
|
|
}
|
2010-01-22 11:06:57 +00:00
|
|
|
|
|
|
|
pthread_mutex_unlock(&queue->mutex);
|
|
|
|
|
|
|
|
return work;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void wait_timeout(struct timespec *timeout, int ms)
|
|
|
|
{
|
|
|
|
ldiv_t div_result;
|
2010-01-23 14:29:56 +00:00
|
|
|
long sec, usec, x;
|
2010-01-22 11:06:57 +00:00
|
|
|
|
2010-01-23 14:29:56 +00:00
|
|
|
#ifdef WIN32
|
|
|
|
{
|
|
|
|
struct _timeb now;
|
|
|
|
_ftime(&now);
|
|
|
|
sec = now.time;
|
2012-05-12 15:02:10 +00:00
|
|
|
usec = now.millitm * 1000; /* microsecond precision would be better */
|
2010-01-22 11:06:57 +00:00
|
|
|
}
|
2010-01-23 11:25:20 +00:00
|
|
|
#else
|
2010-01-23 14:29:56 +00:00
|
|
|
{
|
|
|
|
struct timeval now;
|
2020-07-02 16:19:18 +02:00
|
|
|
gettimeofday(&now, nullptr);
|
2010-01-23 14:29:56 +00:00
|
|
|
sec = now.tv_sec;
|
|
|
|
usec = now.tv_usec;
|
|
|
|
}
|
|
|
|
#endif
|
2010-01-23 11:25:20 +00:00
|
|
|
|
2010-01-23 14:29:56 +00:00
|
|
|
/* add current time + millisecond offset */
|
2010-01-23 11:25:20 +00:00
|
|
|
div_result = ldiv(ms, 1000);
|
2010-01-23 14:29:56 +00:00
|
|
|
timeout->tv_sec = sec + div_result.quot;
|
|
|
|
|
2012-05-12 15:02:10 +00:00
|
|
|
x = usec + (div_result.rem * 1000);
|
2010-01-23 11:25:20 +00:00
|
|
|
|
|
|
|
if (x >= 1000000) {
|
|
|
|
timeout->tv_sec++;
|
|
|
|
x -= 1000000;
|
|
|
|
}
|
|
|
|
|
2012-05-12 15:02:10 +00:00
|
|
|
timeout->tv_nsec = x * 1000;
|
2010-01-22 11:06:57 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void *BLI_thread_queue_pop_timeout(ThreadQueue *queue, int ms)
|
|
|
|
{
|
|
|
|
double t;
|
2020-07-02 16:19:18 +02:00
|
|
|
void *work = nullptr;
|
2010-01-22 11:06:57 +00:00
|
|
|
struct timespec timeout;
|
|
|
|
|
2012-05-12 15:02:10 +00:00
|
|
|
t = PIL_check_seconds_timer();
|
2010-01-22 11:06:57 +00:00
|
|
|
wait_timeout(&timeout, ms);
|
|
|
|
|
|
|
|
/* wait until there is work */
|
|
|
|
pthread_mutex_lock(&queue->mutex);
|
2012-03-24 06:18:31 +00:00
|
|
|
while (BLI_gsqueue_is_empty(queue->queue) && !queue->nowait) {
|
2019-03-27 13:16:10 +11:00
|
|
|
if (pthread_cond_timedwait(&queue->push_cond, &queue->mutex, &timeout) == ETIMEDOUT) {
|
2010-01-22 11:06:57 +00:00
|
|
|
break;
|
2019-03-27 13:16:10 +11:00
|
|
|
}
|
2020-08-07 11:23:02 +02:00
|
|
|
if (PIL_check_seconds_timer() - t >= ms * 0.001) {
|
2010-01-22 11:06:57 +00:00
|
|
|
break;
|
2019-03-27 13:16:10 +11:00
|
|
|
}
|
2010-01-22 11:06:57 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* if we have something, pop it */
|
2012-06-10 12:26:33 +00:00
|
|
|
if (!BLI_gsqueue_is_empty(queue->queue)) {
|
2010-01-22 11:06:57 +00:00
|
|
|
BLI_gsqueue_pop(queue->queue, &work);
|
2018-06-17 16:32:54 +02:00
|
|
|
|
2019-03-27 13:16:10 +11:00
|
|
|
if (BLI_gsqueue_is_empty(queue->queue)) {
|
2012-06-10 12:26:33 +00:00
|
|
|
pthread_cond_broadcast(&queue->finish_cond);
|
2019-03-27 13:16:10 +11:00
|
|
|
}
|
2012-06-10 12:26:33 +00:00
|
|
|
}
|
2018-06-17 16:32:54 +02:00
|
|
|
|
2010-01-22 11:06:57 +00:00
|
|
|
pthread_mutex_unlock(&queue->mutex);
|
|
|
|
|
|
|
|
return work;
|
|
|
|
}
|
|
|
|
|
2018-02-15 23:36:11 +11:00
|
|
|
int BLI_thread_queue_len(ThreadQueue *queue)
|
2010-01-22 11:06:57 +00:00
|
|
|
{
|
|
|
|
int size;
|
|
|
|
|
|
|
|
pthread_mutex_lock(&queue->mutex);
|
2018-02-15 23:36:11 +11:00
|
|
|
size = BLI_gsqueue_len(queue->queue);
|
2010-01-22 11:06:57 +00:00
|
|
|
pthread_mutex_unlock(&queue->mutex);
|
|
|
|
|
|
|
|
return size;
|
|
|
|
}
|
|
|
|
|
2015-06-19 12:30:21 +02:00
|
|
|
bool BLI_thread_queue_is_empty(ThreadQueue *queue)
|
|
|
|
{
|
|
|
|
bool is_empty;
|
|
|
|
|
|
|
|
pthread_mutex_lock(&queue->mutex);
|
|
|
|
is_empty = BLI_gsqueue_is_empty(queue->queue);
|
|
|
|
pthread_mutex_unlock(&queue->mutex);
|
|
|
|
|
|
|
|
return is_empty;
|
|
|
|
}
|
|
|
|
|
2010-01-22 11:06:57 +00:00
|
|
|
void BLI_thread_queue_nowait(ThreadQueue *queue)
|
|
|
|
{
|
|
|
|
pthread_mutex_lock(&queue->mutex);
|
|
|
|
|
2012-05-12 15:02:10 +00:00
|
|
|
queue->nowait = 1;
|
2010-01-22 11:06:57 +00:00
|
|
|
|
|
|
|
/* signal threads waiting to pop */
|
2012-06-10 12:26:33 +00:00
|
|
|
pthread_cond_broadcast(&queue->push_cond);
|
|
|
|
pthread_mutex_unlock(&queue->mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_thread_queue_wait_finish(ThreadQueue *queue)
|
|
|
|
{
|
|
|
|
/* wait for finish condition */
|
|
|
|
pthread_mutex_lock(&queue->mutex);
|
|
|
|
|
2019-03-27 13:16:10 +11:00
|
|
|
while (!BLI_gsqueue_is_empty(queue->queue)) {
|
2012-06-10 12:26:33 +00:00
|
|
|
pthread_cond_wait(&queue->finish_cond, &queue->mutex);
|
2019-03-27 13:16:10 +11:00
|
|
|
}
|
2012-06-10 12:26:33 +00:00
|
|
|
|
2010-01-22 11:06:57 +00:00
|
|
|
pthread_mutex_unlock(&queue->mutex);
|
|
|
|
}
|
|
|
|
|
2018-11-27 18:21:43 +01:00
|
|
|
/* **** Special functions to help performance on crazy NUMA setups. **** */
|
|
|
|
|
2019-03-06 16:20:36 +11:00
|
|
|
#if 0 /* UNUSED */
|
2018-11-27 18:21:43 +01:00
|
|
|
static bool check_is_threadripper2_alike_topology(void)
|
|
|
|
{
|
2020-03-24 10:27:12 +11:00
|
|
|
/* NOTE: We hope operating system does not support CPU hot-swap to
|
2018-11-27 18:21:43 +01:00
|
|
|
* a different brand. And that SMP of different types is also not
|
|
|
|
* encouraged by the system. */
|
|
|
|
static bool is_initialized = false;
|
|
|
|
static bool is_threadripper2 = false;
|
|
|
|
if (is_initialized) {
|
|
|
|
return is_threadripper2;
|
|
|
|
}
|
|
|
|
is_initialized = true;
|
|
|
|
char *cpu_brand = BLI_cpu_brand_string();
|
2020-07-02 16:19:18 +02:00
|
|
|
if (cpu_brand == nullptr) {
|
2018-11-27 18:21:43 +01:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
if (strstr(cpu_brand, "Threadripper")) {
|
2019-04-10 00:06:53 +10:00
|
|
|
/* NOTE: We consider all Thread-rippers having similar topology to
|
2019-02-11 10:51:25 +11:00
|
|
|
* the second one. This is because we are trying to utilize NUMA node
|
|
|
|
* 0 as much as possible. This node does exist on earlier versions of
|
2019-04-10 00:06:53 +10:00
|
|
|
* thread-ripper and setting affinity to it should not have negative
|
2019-02-11 10:51:25 +11:00
|
|
|
* effect.
|
|
|
|
* This allows us to avoid per-model check, making the code more
|
|
|
|
* reliable for the CPUs which are not yet released.
|
|
|
|
*/
|
2018-11-27 18:21:43 +01:00
|
|
|
if (strstr(cpu_brand, "2990WX") || strstr(cpu_brand, "2950X")) {
|
|
|
|
is_threadripper2 = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
/* NOTE: While all dies of EPYC has memory controller, only two f them
|
|
|
|
* has access to a lower-indexed DDR slots. Those dies are same as on
|
|
|
|
* Threadripper2 with the memory controller.
|
|
|
|
* Now, it is rather likely that reasonable amount of users don't max
|
|
|
|
* up their DR slots, making it only two dies connected to a DDR slot
|
|
|
|
* with actual memory in it. */
|
|
|
|
if (strstr(cpu_brand, "EPYC")) {
|
2019-04-10 00:06:53 +10:00
|
|
|
/* NOTE: Similarly to Thread-ripper we do not do model check. */
|
2018-11-27 18:21:43 +01:00
|
|
|
is_threadripper2 = true;
|
|
|
|
}
|
2018-11-29 08:22:15 +11:00
|
|
|
MEM_freeN(cpu_brand);
|
2018-11-27 18:21:43 +01:00
|
|
|
return is_threadripper2;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void threadripper_put_process_on_fast_node(void)
|
|
|
|
{
|
|
|
|
if (!is_numa_available) {
|
|
|
|
return;
|
|
|
|
}
|
2019-03-05 12:43:40 +01:00
|
|
|
/* NOTE: Technically, we can use NUMA nodes 0 and 2 and using both of
|
2018-11-27 18:21:43 +01:00
|
|
|
* them in the affinity mask will allow OS to schedule threads more
|
|
|
|
* flexible,possibly increasing overall performance when multiple apps
|
|
|
|
* are crunching numbers.
|
|
|
|
*
|
|
|
|
* However, if scene fits into memory adjacent to a single die we don't
|
|
|
|
* want OS to re-schedule the process to another die since that will make
|
|
|
|
* it further away from memory allocated for .blend file. */
|
2019-04-10 00:06:53 +10:00
|
|
|
/* NOTE: Even if NUMA is available in the API but is disabled in BIOS on
|
2018-11-27 18:21:43 +01:00
|
|
|
* this workstation we still process here. If NUMA is disabled it will be a
|
|
|
|
* single node, so our action is no-visible-changes, but allows to keep
|
|
|
|
* things simple and unified. */
|
|
|
|
numaAPI_RunProcessOnNode(0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void threadripper_put_thread_on_fast_node(void)
|
|
|
|
{
|
|
|
|
if (!is_numa_available) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
/* NOTE: This is where things becomes more interesting. On the one hand
|
|
|
|
* we can use nodes 0 and 2 and allow operating system to do balancing
|
|
|
|
* of processes/threads for the maximum performance when multiple apps
|
|
|
|
* are running.
|
|
|
|
* On another hand, however, we probably want to use same node as the
|
|
|
|
* main thread since that's where the memory of .blend file is likely
|
|
|
|
* to be allocated.
|
|
|
|
* Since the main thread is currently on node 0, we also put thread on
|
|
|
|
* same node. */
|
|
|
|
/* See additional note about NUMA disabled in BIOS above. */
|
|
|
|
numaAPI_RunThreadOnNode(0);
|
|
|
|
}
|
2019-03-06 16:20:36 +11:00
|
|
|
#endif /* UNUSED */
|
2018-11-27 18:21:43 +01:00
|
|
|
|
|
|
|
void BLI_thread_put_process_on_fast_node(void)
|
|
|
|
{
|
2019-03-05 12:43:40 +01:00
|
|
|
/* Disabled for now since this causes only 16 threads to be used on a
|
2019-04-10 00:06:53 +10:00
|
|
|
* thread-ripper for computations like sculpting and fluid sim. The problem
|
2019-03-05 12:43:40 +01:00
|
|
|
* is that all threads created as children from this thread will inherit
|
|
|
|
* the NUMA node and so will end up on the same node. This can be fixed
|
|
|
|
* case-by-case by assigning the NUMA node for every child thread, however
|
|
|
|
* this is difficult for external libraries and OpenMP, and out of our
|
|
|
|
* control for plugins like external renderers. */
|
|
|
|
#if 0
|
2018-11-27 18:21:43 +01:00
|
|
|
if (check_is_threadripper2_alike_topology()) {
|
|
|
|
threadripper_put_process_on_fast_node();
|
|
|
|
}
|
2019-03-05 12:43:40 +01:00
|
|
|
#endif
|
2018-11-27 18:21:43 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_thread_put_thread_on_fast_node(void)
|
|
|
|
{
|
2019-03-05 12:43:40 +01:00
|
|
|
/* Disabled for now, see comment above. */
|
|
|
|
#if 0
|
2018-11-27 18:21:43 +01:00
|
|
|
if (check_is_threadripper2_alike_topology()) {
|
|
|
|
threadripper_put_thread_on_fast_node();
|
|
|
|
}
|
2019-03-05 12:43:40 +01:00
|
|
|
#endif
|
2018-11-27 18:21:43 +01:00
|
|
|
}
|