archive/blender-archive
Archived
1
1
Fork 0
Code Pull Requests Packages Activity
This repository has been archived on 2023-10-09. You can view files and clone it, but cannot push or open issues or pull requests.
Files
e122dc0748f6a4d77b236e26beba93e2a9a36bf0
blender-archive/source/blender/blenlib/BLI_threads.h

140 lines
4.1 KiB
C++
Raw Normal View History

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
/*
*
*
* ***** BEGIN GPL LICENSE BLOCK *****
*
* 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,
correct fsf address
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.
*
* The Original Code is: all of this file.
*
* Contributor(s): none yet.
*
* ***** END GPL LICENSE BLOCK *****
*/
#ifndef BLI_THREADS_H
#define BLI_THREADS_H
doxygen: add blenlib under core as module.
2011-02-18 13:58:08 +00:00
/** \file BLI_threads.h
* \ingroup bli
*/
Render & Compositing Thread Fixes * Rendering twice or more could crash layer/pass buttons. * Compositing would crash while drawing the image. * Rendering animations could also crash drawing the image. * Compositing could crash * Starting to rendering while preview render / compo was still running could crash. * Exiting while rendering an animation would not abort the renderer properly, making Blender seemingly freeze. * Fixes theoretically possible issue with setting malloc lock with nested threads. * Drawing previews inside nodes could crash when those nodes were being rendered at the same time. There's more crashes, manipulating the scene data or undo can still crash, this commit only focuses on making sure the image buffer and render result access is thread safe. Implementation: * Rather than assuming the render result does not get freed during render, which seems to be quite difficult to do given that e.g. the compositor is allowed to change the size of the buffer or output different passes, the render result is now protected with a read/write mutex. * The read/write mutex allows multiple readers (and pixel writers) at the same time, but only allows one writer to manipulate the data structure. * Added BKE_image_acquire_ibuf/BKE_image_release_ibuf to access images being rendered, cases where this is not needed (most code) can still use BKE_image_get_ibuf. * The job manager now allows only one rendering job at the same time, rather than the G.rendering check which was not reliable.
2009-09-30 18:18:32 +00:00
#include <pthread.h>
Two fixes in renderpipe... - Renderwin still used a thread-unsafe malloc, in the header text print - Setting clipping flags in vertices for parts required a mutex lock after all... I thought it would go fine, but noticed on renders with small amounts of faces that sometimes faces disappear from a render. (was doing movie credits, so all faces are visible! Otherwise it would have hardly been noticable...)
2006-03-13 11:01:17 +00:00
Render Monster support: (part 1) Removed all limitations from render code for maximum threads. The only define for this now is in BLI_threads.h, and currently set to 8. Note that each thread renders an entire tile, and also allocates the buffers for the tiles, so; more threads might work better with smaller tiles. IMPORTANT: node system won't work yet with more than 2 threads! So, don't try material nodes or compositing with over 2 threads. That I'll commit later today. What does work (should work :) is AO and soft shadow now.
2006-11-29 17:01:09 +00:00
/* for tables, button in UI, etc */
- change max threads from 8 to 64, need to keep an eye on stack memory use here. - reload fix didnt work last commit.
2010-01-28 19:18:35 +00:00
#define BLENDER_MAX_THREADS 64
Render Monster support: (part 1) Removed all limitations from render code for maximum threads. The only define for this now is in BLI_threads.h, and currently set to 8. Note that each thread renders an entire tile, and also allocates the buffers for the tiles, so; more threads might work better with smaller tiles. IMPORTANT: node system won't work yet with more than 2 threads! So, don't try material nodes or compositing with over 2 threads. That I'll commit later today. What does work (should work :) is AO and soft shadow now.
2006-11-29 17:01:09 +00:00
struct ListBase;
Render & Compositing Thread Fixes * Rendering twice or more could crash layer/pass buttons. * Compositing would crash while drawing the image. * Rendering animations could also crash drawing the image. * Compositing could crash * Starting to rendering while preview render / compo was still running could crash. * Exiting while rendering an animation would not abort the renderer properly, making Blender seemingly freeze. * Fixes theoretically possible issue with setting malloc lock with nested threads. * Drawing previews inside nodes could crash when those nodes were being rendered at the same time. There's more crashes, manipulating the scene data or undo can still crash, this commit only focuses on making sure the image buffer and render result access is thread safe. Implementation: * Rather than assuming the render result does not get freed during render, which seems to be quite difficult to do given that e.g. the compositor is allowed to change the size of the buffer or output different passes, the render result is now protected with a read/write mutex. * The read/write mutex allows multiple readers (and pixel writers) at the same time, but only allows one writer to manipulate the data structure. * Added BKE_image_acquire_ibuf/BKE_image_release_ibuf to access images being rendered, cases where this is not needed (most code) can still use BKE_image_get_ibuf. * The job manager now allows only one rendering job at the same time, rather than the G.rendering check which was not reliable.
2009-09-30 18:18:32 +00:00
/* Threading API */
prevent images from freeing gpu buffers if not run within the main thread, instead they are queued to be freed the next time GPU_image_free() is run from the main thread.
2010-04-13 12:51:03 +00:00
/*this is run once at startup*/
void BLI_threadapi_init(void);
Render Monster support: (part 1) Removed all limitations from render code for maximum threads. The only define for this now is in BLI_threads.h, and currently set to 8. Note that each thread renders an entire tile, and also allocates the buffers for the tiles, so; more threads might work better with smaller tiles. IMPORTANT: node system won't work yet with more than 2 threads! So, don't try material nodes or compositing with over 2 threads. That I'll commit later today. What does work (should work :) is AO and soft shadow now.
2006-11-29 17:01:09 +00:00
void BLI_init_threads (struct ListBase *threadbase, void *(*do_thread)(void *), int tot);
int BLI_available_threads(struct ListBase *threadbase);
int BLI_available_thread_index(struct ListBase *threadbase);
void BLI_insert_thread (struct ListBase *threadbase, void *callerdata);
void BLI_remove_thread (struct ListBase *threadbase, void *callerdata);
Add a function to join thread by index in the thread list. This can be safely merged in trunk, in case anyone needs something like that.
2008-08-14 23:48:52 +00:00
void BLI_remove_thread_index(struct ListBase *threadbase, int index);
Keep persistent results for retargeting. Easier weight adjustement. Will have to do a second pass tomorrow to fix some leftovers.
2008-09-25 20:29:15 +00:00
void BLI_remove_threads(struct ListBase *threadbase);
Render Monster support: (part 1) Removed all limitations from render code for maximum threads. The only define for this now is in BLI_threads.h, and currently set to 8. Note that each thread renders an entire tile, and also allocates the buffers for the tiles, so; more threads might work better with smaller tiles. IMPORTANT: node system won't work yet with more than 2 threads! So, don't try material nodes or compositing with over 2 threads. That I'll commit later today. What does work (should work :) is AO and soft shadow now.
2006-11-29 17:01:09 +00:00
void BLI_end_threads (struct ListBase *threadbase);
prevent images from freeing gpu buffers if not run within the main thread, instead they are queued to be freed the next time GPU_image_free() is run from the main thread.
2010-04-13 12:51:03 +00:00
int BLI_thread_is_main(void);
Thread rendering stability commit. I noticed still several cases where the Imbuf library was called within a thread... and that whilst the Imbuf itself isn't threadsafe. Also the thread lock I added in rendering for loading images actually didn't work, because then it was still possible both threads were accessing the MEM_malloc function at same time. This commit nearly fully replaces ImBuf calls in compositor (giving another nice speedup btw, the way preview images in Nodes were calculated used clumsy imbuf scaling code). I've also centralized the 'mutex' locking for threading, which now only resides in BLI_threads.h. This is used to secure the last ImBuf calls I cannot replace, which is loading images and creating mipmaps. Really hope we get something more stable now!
2006-02-11 15:55:00 +00:00
Render & Compositing Thread Fixes * Rendering twice or more could crash layer/pass buttons. * Compositing would crash while drawing the image. * Rendering animations could also crash drawing the image. * Compositing could crash * Starting to rendering while preview render / compo was still running could crash. * Exiting while rendering an animation would not abort the renderer properly, making Blender seemingly freeze. * Fixes theoretically possible issue with setting malloc lock with nested threads. * Drawing previews inside nodes could crash when those nodes were being rendered at the same time. There's more crashes, manipulating the scene data or undo can still crash, this commit only focuses on making sure the image buffer and render result access is thread safe. Implementation: * Rather than assuming the render result does not get freed during render, which seems to be quite difficult to do given that e.g. the compositor is allowed to change the size of the buffer or output different passes, the render result is now protected with a read/write mutex. * The read/write mutex allows multiple readers (and pixel writers) at the same time, but only allows one writer to manipulate the data structure. * Added BKE_image_acquire_ibuf/BKE_image_release_ibuf to access images being rendered, cases where this is not needed (most code) can still use BKE_image_get_ibuf. * The job manager now allows only one rendering job at the same time, rather than the G.rendering check which was not reliable.
2009-09-30 18:18:32 +00:00
/* System Information */
int BLI_system_thread_count(void); /* gets the number of threads the system can make use of */
/* Global Mutex Locks
*
* One custom lock available now. can be extended. */
#define LOCK_IMAGE 0
#define LOCK_PREVIEW 1
Fixes for thread related render / compositing crashes: * Viewer node could free image while it is being redrawn, viewer image buffers now need acquire/release to be accessed as was already the case for render results. * The Composite node could free the image buffers outside of a lock, also causing simultaneous redraw to crash. * Especially on Windows, re-rendering could crash when drawing an image that was freed. When RE_RenderInProgress was true it would access the image buffer and simply return it while it could still contain a pointer to a render result buffer that was already freed. I don't understand why this case was there in the first place, so I've removed it. Possibly fixes bugs #20174, #21418, #21391, #21394.
2010-03-16 16:58:45 +00:00
#define LOCK_VIEWER 2
#define LOCK_CUSTOM1 3
Fix #22123 and #22124: some problems with mutex locks, also tweak to how removing opengl textures from outside main thread is done so it happens as part of the main loop.
2010-04-25 10:49:13 +00:00
#define LOCK_RCACHE 4
#define LOCK_OPENGL 5
Fix #29084: material/texture nodes crash introduced in 2.60, execdata is being lazely created but this wasn't done in a thread safe way.
2011-10-31 17:00:59 +00:00
#define LOCK_NODES 6
Render & Compositing Thread Fixes * Rendering twice or more could crash layer/pass buttons. * Compositing would crash while drawing the image. * Rendering animations could also crash drawing the image. * Compositing could crash * Starting to rendering while preview render / compo was still running could crash. * Exiting while rendering an animation would not abort the renderer properly, making Blender seemingly freeze. * Fixes theoretically possible issue with setting malloc lock with nested threads. * Drawing previews inside nodes could crash when those nodes were being rendered at the same time. There's more crashes, manipulating the scene data or undo can still crash, this commit only focuses on making sure the image buffer and render result access is thread safe. Implementation: * Rather than assuming the render result does not get freed during render, which seems to be quite difficult to do given that e.g. the compositor is allowed to change the size of the buffer or output different passes, the render result is now protected with a read/write mutex. * The read/write mutex allows multiple readers (and pixel writers) at the same time, but only allows one writer to manipulate the data structure. * Added BKE_image_acquire_ibuf/BKE_image_release_ibuf to access images being rendered, cases where this is not needed (most code) can still use BKE_image_get_ibuf. * The job manager now allows only one rendering job at the same time, rather than the G.rendering check which was not reliable.
2009-09-30 18:18:32 +00:00
void BLI_lock_thread(int type);
void BLI_unlock_thread(int type);
/* Mutex Lock */
typedef pthread_mutex_t ThreadMutex;
Fix #22123 and #22124: some problems with mutex locks, also tweak to how removing opengl textures from outside main thread is done so it happens as part of the main loop.
2010-04-25 10:49:13 +00:00
#define BLI_MUTEX_INITIALIZER PTHREAD_MUTEX_INITIALIZER
Render & Compositing Thread Fixes * Rendering twice or more could crash layer/pass buttons. * Compositing would crash while drawing the image. * Rendering animations could also crash drawing the image. * Compositing could crash * Starting to rendering while preview render / compo was still running could crash. * Exiting while rendering an animation would not abort the renderer properly, making Blender seemingly freeze. * Fixes theoretically possible issue with setting malloc lock with nested threads. * Drawing previews inside nodes could crash when those nodes were being rendered at the same time. There's more crashes, manipulating the scene data or undo can still crash, this commit only focuses on making sure the image buffer and render result access is thread safe. Implementation: * Rather than assuming the render result does not get freed during render, which seems to be quite difficult to do given that e.g. the compositor is allowed to change the size of the buffer or output different passes, the render result is now protected with a read/write mutex. * The read/write mutex allows multiple readers (and pixel writers) at the same time, but only allows one writer to manipulate the data structure. * Added BKE_image_acquire_ibuf/BKE_image_release_ibuf to access images being rendered, cases where this is not needed (most code) can still use BKE_image_get_ibuf. * The job manager now allows only one rendering job at the same time, rather than the G.rendering check which was not reliable.
2009-09-30 18:18:32 +00:00
void BLI_mutex_init(ThreadMutex *mutex);
void BLI_mutex_lock(ThreadMutex *mutex);
void BLI_mutex_unlock(ThreadMutex *mutex);
void BLI_mutex_end(ThreadMutex *mutex);
Thread rendering stability commit. I noticed still several cases where the Imbuf library was called within a thread... and that whilst the Imbuf itself isn't threadsafe. Also the thread lock I added in rendering for loading images actually didn't work, because then it was still possible both threads were accessing the MEM_malloc function at same time. This commit nearly fully replaces ImBuf calls in compositor (giving another nice speedup btw, the way preview images in Nodes were calculated used clumsy imbuf scaling code). I've also centralized the 'mutex' locking for threading, which now only resides in BLI_threads.h. This is used to secure the last ImBuf calls I cannot replace, which is loading images and creating mipmaps. Really hope we get something more stable now!
2006-02-11 15:55:00 +00:00
Render & Compositing Thread Fixes * Rendering twice or more could crash layer/pass buttons. * Compositing would crash while drawing the image. * Rendering animations could also crash drawing the image. * Compositing could crash * Starting to rendering while preview render / compo was still running could crash. * Exiting while rendering an animation would not abort the renderer properly, making Blender seemingly freeze. * Fixes theoretically possible issue with setting malloc lock with nested threads. * Drawing previews inside nodes could crash when those nodes were being rendered at the same time. There's more crashes, manipulating the scene data or undo can still crash, this commit only focuses on making sure the image buffer and render result access is thread safe. Implementation: * Rather than assuming the render result does not get freed during render, which seems to be quite difficult to do given that e.g. the compositor is allowed to change the size of the buffer or output different passes, the render result is now protected with a read/write mutex. * The read/write mutex allows multiple readers (and pixel writers) at the same time, but only allows one writer to manipulate the data structure. * Added BKE_image_acquire_ibuf/BKE_image_release_ibuf to access images being rendered, cases where this is not needed (most code) can still use BKE_image_get_ibuf. * The job manager now allows only one rendering job at the same time, rather than the G.rendering check which was not reliable.
2009-09-30 18:18:32 +00:00
/* Read/Write Mutex Lock */
ThreadedWorker New functions to easily dispatch work to a limited number of thread, transparently. NOTE: Could be merged in trunk, if needed.
2008-08-16 22:47:33 +00:00
Render & Compositing Thread Fixes * Rendering twice or more could crash layer/pass buttons. * Compositing would crash while drawing the image. * Rendering animations could also crash drawing the image. * Compositing could crash * Starting to rendering while preview render / compo was still running could crash. * Exiting while rendering an animation would not abort the renderer properly, making Blender seemingly freeze. * Fixes theoretically possible issue with setting malloc lock with nested threads. * Drawing previews inside nodes could crash when those nodes were being rendered at the same time. There's more crashes, manipulating the scene data or undo can still crash, this commit only focuses on making sure the image buffer and render result access is thread safe. Implementation: * Rather than assuming the render result does not get freed during render, which seems to be quite difficult to do given that e.g. the compositor is allowed to change the size of the buffer or output different passes, the render result is now protected with a read/write mutex. * The read/write mutex allows multiple readers (and pixel writers) at the same time, but only allows one writer to manipulate the data structure. * Added BKE_image_acquire_ibuf/BKE_image_release_ibuf to access images being rendered, cases where this is not needed (most code) can still use BKE_image_get_ibuf. * The job manager now allows only one rendering job at the same time, rather than the G.rendering check which was not reliable.
2009-09-30 18:18:32 +00:00
#define THREAD_LOCK_READ 1
#define THREAD_LOCK_WRITE 2
2.5 Preview renders: - Added proper button type (BUT_EXTRA) for preview buttons, to handle drawing better. It now first draws an alpha mask, to ensure the preview is correctly fitting inside the widget style. It then draws the outline. - Added protection for executing preview renders while regular rendering, that's not going to work...
2009-06-08 10:00:14 +00:00
Render & Compositing Thread Fixes * Rendering twice or more could crash layer/pass buttons. * Compositing would crash while drawing the image. * Rendering animations could also crash drawing the image. * Compositing could crash * Starting to rendering while preview render / compo was still running could crash. * Exiting while rendering an animation would not abort the renderer properly, making Blender seemingly freeze. * Fixes theoretically possible issue with setting malloc lock with nested threads. * Drawing previews inside nodes could crash when those nodes were being rendered at the same time. There's more crashes, manipulating the scene data or undo can still crash, this commit only focuses on making sure the image buffer and render result access is thread safe. Implementation: * Rather than assuming the render result does not get freed during render, which seems to be quite difficult to do given that e.g. the compositor is allowed to change the size of the buffer or output different passes, the render result is now protected with a read/write mutex. * The read/write mutex allows multiple readers (and pixel writers) at the same time, but only allows one writer to manipulate the data structure. * Added BKE_image_acquire_ibuf/BKE_image_release_ibuf to access images being rendered, cases where this is not needed (most code) can still use BKE_image_get_ibuf. * The job manager now allows only one rendering job at the same time, rather than the G.rendering check which was not reliable.
2009-09-30 18:18:32 +00:00
typedef pthread_rwlock_t ThreadRWMutex;
void BLI_rw_mutex_init(ThreadRWMutex *mutex);
void BLI_rw_mutex_lock(ThreadRWMutex *mutex, int mode);
void BLI_rw_mutex_unlock(ThreadRWMutex *mutex);
void BLI_rw_mutex_end(ThreadRWMutex *mutex);
/* ThreadedWorker
*
* A simple tool for dispatching work to a limited number of threads
* in a transparent fashion from the caller's perspective. */
ThreadedWorker New functions to easily dispatch work to a limited number of thread, transparently. NOTE: Could be merged in trunk, if needed.
2008-08-16 22:47:33 +00:00
struct ThreadedWorker;
/* Create a new worker supporting tot parallel threads.
* When new work in inserted and all threads are busy, sleep(sleep_time) before checking again
*/
struct ThreadedWorker *BLI_create_worker(void *(*do_thread)(void *), int tot, int sleep_time);
/* join all working threads */
void BLI_end_worker(struct ThreadedWorker *worker);
/* also ends all working threads */
void BLI_destroy_worker(struct ThreadedWorker *worker);
/* Spawns a new work thread if possible, sleeps until one is available otherwise
* NOTE: inserting work is NOT thread safe, so make sure it is only done from one thread */
void BLI_insert_work(struct ThreadedWorker *worker, void *param);
Threads: added queue for passing data between threads. Includes a function to wait for an item to be put in the queue and then pop immediately without, this makes it possible to avoid sleep() while waiting for the results of a thread.
2010-01-22 11:06:57 +00:00
/* ThreadWorkQueue
*
* Thread-safe work queue to push work/pointers between threads. */
typedef struct ThreadQueue ThreadQueue;
- added GCC warning -Wstrict-prototypes - fixed bug in paste material, exposed by stricter warnings. - removed/renamed various shadowed vars. - removed BGE lamp.colour, only allow lamp.color attribute.
2010-12-03 12:30:59 +00:00
ThreadQueue *BLI_thread_queue_init(void);
Threads: added queue for passing data between threads. Includes a function to wait for an item to be put in the queue and then pop immediately without, this makes it possible to avoid sleep() while waiting for the results of a thread.
2010-01-22 11:06:57 +00:00
void BLI_thread_queue_free(ThreadQueue *queue);
void BLI_thread_queue_push(ThreadQueue *queue, void *work);
void *BLI_thread_queue_pop(ThreadQueue *queue);
void *BLI_thread_queue_pop_timeout(ThreadQueue *queue, int ms);
int BLI_thread_queue_size(ThreadQueue *queue);
void BLI_thread_queue_nowait(ThreadQueue *queue);
ThreadedWorker New functions to easily dispatch work to a limited number of thread, transparently. NOTE: Could be merged in trunk, if needed.
2008-08-16 22:47:33 +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
#endif
Copy Permalink