diff options
Diffstat (limited to 'source/blender/compositor/COM_compositor.h')
| -rw-r--r-- | source/blender/compositor/COM_compositor.h | 78 |
1 files changed, 52 insertions, 26 deletions
diff --git a/source/blender/compositor/COM_compositor.h b/source/blender/compositor/COM_compositor.h index 2891d8cdfa0..b33a48464e1 100644 --- a/source/blender/compositor/COM_compositor.h +++ b/source/blender/compositor/COM_compositor.h @@ -26,7 +26,6 @@ #include "DNA_node_types.h" - /** * @defgroup Model The data model of the compositor * @defgroup Memory The memory management stuff @@ -38,7 +37,8 @@ * @mainpage Introduction of the Blender Compositor * * @section bcomp Blender compositor - * This project redesigns the interals of Blender's compositor. The project has been executed in 2011 by At Mind. At Mind is a technology company located in Amsterdam, The Netherlands. + * This project redesigns the interals of Blender's compositor. The project has been executed in 2011 by At Mind. + * At Mind is a technology company located in Amsterdam, The Netherlands. * The project has been crowdfunded. This code has been released under GPL2 to be used in Blender. * * @section goals The goals of the project @@ -47,32 +47,41 @@ * - Make the compositor work faster for you (workflow) * * @section speed Faster compositor - * The speedup has been done by making better use of the hardware Blenders is working on. The previous compositor only used a single threaded model to calculate a node. The only exception to this is the Defocus node. - * Only when it is possible to calculate two full nodes in parallel a second thread was used. Current workstations have 8-16 threads available, and most of the time these are idle. + * The speedup has been done by making better use of the hardware Blenders is working on. The previous compositor only + * used a single threaded model to calculate a node. The only exception to this is the Defocus node. + * Only when it is possible to calculate two full nodes in parallel a second thread was used. + * Current workstations have 8-16 threads available, and most of the time these are idle. * - * In the new compositor we want to use as much of threads as possible. Even new OpenCL capable GPU-hardware can be used for calculation. + * In the new compositor we want to use as much of threads as possible. Even new OpenCL capable GPU-hardware can be + * used for calculation. * * @section workflow Work faster - * The previous compositor only showed the final image. The compositor could wait a long time before seeing the result of his work. The new compositor will work in a way that it will focus on getting information back to the user. + * The previous compositor only showed the final image. The compositor could wait a long time before seeing the result + * of his work. The new compositor will work in a way that it will focus on getting information back to the user. * It will prioritise its work to get earlier user feedback. * * @page memory Memory model - * The main issue is the type of memory model to use. Blender is used by consumers and professionals. Ranging from low-end machines to very high-end machines. The system should work on high-end machines and on low-end machines. + * The main issue is the type of memory model to use. Blender is used by consumers and professionals. + * Ranging from low-end machines to very high-end machines. + * The system should work on high-end machines and on low-end machines. * * * @page executing Executing * @section prepare Prepare execution * - * during the preparation of the execution All ReadBufferOperation will receive an offset. this offset is used during execution as an optimization trick + * during the preparation of the execution All ReadBufferOperation will receive an offset. + * This offset is used during execution as an optimization trick * Next all operations will be initialized for execution @see NodeOperation.initExecution * Next all ExecutionGroup's will be initialized for execution @see ExecutionGroup.initExecution * this all is controlled from @see ExecutionSystem.execute * * @section priority Render priority - * Render priority is an priority of an output node. A user has a different need of Render priorities of output nodes than during editing. + * Render priority is an priority of an output node. A user has a different need of Render priorities of output nodes + * than during editing. * for example. the Active ViewerNode has top priority during editing, but during rendering a CompositeNode has. * All NodeOperation has a setting for their renderpriority, but only for output NodeOperation these have effect. - * In ExecutionSystem.execute all priorities are checked. For every priority the ExecutionGroup's are check if the priority do match. + * In ExecutionSystem.execute all priorities are checked. For every priority the ExecutionGroup's are check if the + * priority do match. * When match the ExecutionGroup will be executed (this happens in serial) * * @see ExecutionSystem.execute control of the Render priority @@ -82,7 +91,8 @@ * @section order Chunk order * * When a ExecutionGroup is executed, first the order of chunks are determined. - * The settings are stored in the ViewerNode inside the ExecutionGroup. ExecutionGroups that have no viewernode, will use a default one. + * The settings are stored in the ViewerNode inside the ExecutionGroup. ExecutionGroups that have no viewernode, + * will use a default one. * There are several possible chunk orders * - [@ref OrderOfChunks.COM_TO_CENTER_OUT]: Start calculating from a configurable point and order by nearest chunk * - [@ref OrderOfChunks.COM_TO_RANDOM]: Randomize all chunks. @@ -100,7 +110,8 @@ * @see OrderOfChunks * * @section interest Area of interest - * An ExecutionGroup can have dependancies to other ExecutionGroup's. Data passing from one ExecutionGroup to another one are stored in 'chunks'. + * An ExecutionGroup can have dependancies to other ExecutionGroup's. Data passing from one ExecutionGroup to another + * one are stored in 'chunks'. * If not all input chunks are available the chunk execution will not be scheduled. * <pre> * +-------------------------------------+ +--------------------------------------+ @@ -125,9 +136,12 @@ * </pre> * * In the above example ExecutionGroup B has an outputoperation (ViewerOperation) and is being executed. - * The first chunk is evaluated [@ref ExecutionGroup.scheduleChunkWhenPossible], but not all input chunks are available. The relevant ExecutionGroup (that can calculate the missing chunks; ExecutionGroup A) is - * Asked to calculate the area ExecutionGroup B is missing. [@ref ExecutionGroup.scheduleAreaWhenPossible] - * ExecutionGroup B checks what chunks the area spans, and tries to schedule these chunks. If all input data is available these chunks are scheduled [@ref ExecutionGroup.scheduleChunk] + * The first chunk is evaluated [@ref ExecutionGroup.scheduleChunkWhenPossible], + * but not all input chunks are available. The relevant ExecutionGroup (that can calculate the missing chunks; + * ExecutionGroup A) is asked to calculate the area ExecutionGroup B is missing. + * [@ref ExecutionGroup.scheduleAreaWhenPossible] + * ExecutionGroup B checks what chunks the area spans, and tries to schedule these chunks. + * If all input data is available these chunks are scheduled [@ref ExecutionGroup.scheduleChunk] * * <pre> * @@ -166,7 +180,8 @@ * * This happens until all chunks of (ExecutionGroup B) are finished executing or the user break's the process. * - * NodeOperation like the ScaleOperation can influence the area of interest by reimplementing the [@ref NodeOperation.determineAreaOfInterest] method + * NodeOperation like the ScaleOperation can influence the area of interest by reimplementing the + * [@ref NodeOperation.determineAreaOfInterest] method * * <pre> * @@ -188,8 +203,10 @@ * </pre> * * @see ExecutionGroup.execute Execute a complete ExecutionGroup. Halts until finished or breaked by user - * @see ExecutionGroup.scheduleChunkWhenPossible Tries to schedule a single chunk, checks if all input data is available. Can trigger dependant chunks to be calculated - * @see ExecutionGroup.scheduleAreaWhenPossible Tries to schedule an area. This can be multiple chunks (is called from [@ref ExecutionGroup.scheduleChunkWhenPossible]) + * @see ExecutionGroup.scheduleChunkWhenPossible Tries to schedule a single chunk, + * checks if all input data is available. Can trigger dependant chunks to be calculated + * @see ExecutionGroup.scheduleAreaWhenPossible Tries to schedule an area. This can be multiple chunks + * (is called from [@ref ExecutionGroup.scheduleChunkWhenPossible]) * @see ExecutionGroup.scheduleChunk Schedule a chunk on the WorkScheduler * @see NodeOperation.determineDependingAreaOfInterest Influence the area of interest of a chunk. * @see WriteBufferOperation NodeOperation to write to a MemoryProxy/MemoryBuffer @@ -198,27 +215,34 @@ * @see MemoryBuffer Allocated memory for a single chunk * * @section workscheduler WorkScheduler - * the WorkScheduler is implemented as a static class. the responsibility of the WorkScheduler is to balance WorkPackages to the available and free devices. + * the WorkScheduler is implemented as a static class. the responsibility of the WorkScheduler is to balance + * WorkPackages to the available and free devices. * the workscheduler can work in 2 states. For witching these between the state you need to recompile blender * * @subsection multithread Multi threaded * Default the workscheduler will place all work as WorkPackage in a queue. - * For every CPUcore a working thread is created. These working threads will ask the WorkScheduler if there is work for a specific Device. + * For every CPUcore a working thread is created. These working threads will ask the WorkScheduler if there is work + * for a specific Device. * the workscheduler will find work for the device and the device will be asked to execute the WorkPackage * @subsection singlethread Single threaded - * For debugging reasons the multi-threading can be disabled. This is done by changing the COM_CURRENT_THREADING_MODEL to COM_TM_NOTHREAD. When compiling the workscheduler + * For debugging reasons the multi-threading can be disabled. This is done by changing the COM_CURRENT_THREADING_MODEL + * to COM_TM_NOTHREAD. When compiling the workscheduler * will be changes to support no threading and run everything on the CPU. * * @section devices Devices - * A Device within the compositor context is a Hardware component that can used to calculate chunks. This chunk is encapseled in a WorkPackage. + * A Device within the compositor context is a Hardware component that can used to calculate chunks. + * This chunk is encapseled in a WorkPackage. * the WorkScheduler controls the devices and selects the device where a WorkPackage will be calculated. * * @subsection WS_Devices Workscheduler - * The WorkScheduler controls all Devices. When initializing the compositor the WorkScheduler selects all devices that will be used during compositor. + * The WorkScheduler controls all Devices. When initializing the compositor the WorkScheduler selects + * all devices that will be used during compositor. * There are two types of Devices, CPUDevice and OpenCLDevice. * When an ExecutionGroup schedules a Chunk the schedule method of the WorkScheduler - * The Workscheduler determines if the chunk can be run on an OpenCLDevice (and that there are available OpenCLDevice). If this is the case the chunk will be added to the worklist for OpenCLDevice's + * The Workscheduler determines if the chunk can be run on an OpenCLDevice + * (and that there are available OpenCLDevice). If this is the case the chunk will be added to the worklist for + * OpenCLDevice's * otherwise the chunk will be added to the worklist of CPUDevices. * * A thread will read the work-list and sends a workpackage to its device. @@ -227,7 +251,8 @@ * @see Device.execute method called to execute a chunk * * @subsection CPUDevice CPUDevice - * When a CPUDevice gets a WorkPackage the Device will get the inputbuffer that is needed to calculate the chunk. Allocation is already done by the ExecutionGroup. + * When a CPUDevice gets a WorkPackage the Device will get the inputbuffer that is needed to calculate the chunk. + * Allocation is already done by the ExecutionGroup. * The outputbuffer of the chunk is being created. * The OutputOperation of the ExecutionGroup is called to execute the area of the outputbuffer. * @@ -269,7 +294,8 @@ * @see bNodeTree.edit_quality * @see bNodeTree.render_quality * - * - output nodes can have different priorities in the WorkScheduler. This is implemented in the COM_execute function. + * - output nodes can have different priorities in the WorkScheduler. + * This is implemented in the COM_execute function. */ void COM_execute(bNodeTree *editingtree, int rendering); |