Hi, I did a analyze of the parts that 'might' be blocking the keying workflow in Mango. See here a list of nodes and some concerns I have.
List is not ordered. VectorBlur: this node still uses the old implementation that is heavely optimized for single threaded execution. As vector blur is mostly in the beginning of a nodetree it can block execution. The implementation makes use of the QualitySetting. Glare: this nodes are buffer operations. The implementation calculates everything to a buffer and reads the result using tiles. The calculation of the buffer blocks all threads. Tonemap: this nodes calculates an average (needs access to all input color samples). The average is cached. The calculation of this average blocks all threads. ViewLevels: this nodes calculates an average (needs access to all input color samples). The average is cached. The calculation of this average blocks all threads. Defocus: Current implementation is still not optimized. By adding a lookup grid (1/16th of the original size) containing the inverse radius the node will be 5-20 times faster on CPU. Node can also by OpenCL'd but that is step 2. Node does not blopck any execution. More information about the inverse radius can be found in the prototype we did at BConf 2010. [http://sicg.atmind.nl/index.php?option=com_content&view=article&id=30:blend er-opencl-released&catid=8:blender&Itemid=12] Dilate/Erode: When using Dilate/Erode in the 'Step' algorithm the result is calculated single threaded in a buffer. This buffer is read by tiles. Blocks system and node is common used in a keying setup. DoubleEdgeMask: this nodes is a buffer operation. The implementation calculates everything to a buffer and reads the result using tiles. The calculation of the buffer blocks all threads. KeyingNode: Keying node is very complex and makes use of different operations and some are calculation sensitive and some are blocking the execution. 1. KeyingBlur (used for pre/post blur) uses a 'bokeh blur with gaussian type flat' in the YCC color space on color channels 2+3. in 4k this can be very slow. I would really like to see a different algorithm here. as the bokeh type of formular is 2. The dilate function uses the step algorithm that is blocking. [see Dilate/Erode] as this operation is one of the last added it blocks visual feedback, until almost the whole node is calculated. 3. The KeyingClip operation also uses a kernel. I am not sure what would be a common value. The larger the slower it gets. KeyingScreen: Blocks execution. Not sure if we can cache this like we did with distort/undistort. don't know how much time it takes. and if this process can be breaked! perhaps this is a really interesting part to investigate. MaskNode: this nodes is a buffer operation. The implementation calculates everything to a buffer and reads the result using tiles. The calculation of the buffer blocks all threads. Normalize: this nodes calculates an average (needs access to all input color samples). The average is cached. The calculation of this average blocks all threads. LensDistorion: Can be optimized by using different sampling algorithms for low/medium/high quality. Only mentioning this as it is widely used in the Glare setup of Andy. Not blocking. I have checked possible issues with ImBuf, but couldn't see that it was blocking that much; reading 51MB openexr was far below a second. I would put my money on the keying nodes as it really is complex. Campbell can you run a QML profiler on a blocking mango file with COM_CURRENT_THREADING_MODEL on COM_TM_NOTHREAD? You can also enable COM_DEBUG that will put a dot-graph to the console for the execution graph. First optimize the operations by using different same quality algorithms. If it is still blocking we can use OpenCL for it. Regards, Jeroen Original Message: ----------------- From: Ton Roosendaal [email protected] Date: Sun, 24 Jun 2012 17:45:54 +0200 To: [email protected], [email protected] Subject: [Bf-committers] Blender developer meeting notes - 24 June 2012 Hi all, And here's a summary of today's topics at irc.freenode.net #blendercoders 1) Blender 2.64 progress - Bug tracker is now down to 262 open issues - 45 new reports came in in last week, 74 were closed. - Linux maintainer (Sergey Sharybin) will remove trunk/lib/ for linux libraries, it gives more issues than benefits. The compile docs will get updated. - Tiles Compositor is currently a showstopper for release; it has issues artists perceive as a regression. If this would be fixed, the tile system would show off much better. Issues as noted are: - Make the common nodes tile aware (if node requires a buffers it blocks the process). Jeroen Bakker will make a list of 'bad' nodes, so everyone can help fixing - Provide user with ways to work with non-tile nodes nicer (draw early tile previews or disable node) - Buffered nodes: for fast viewing, and to ensure recomposites only do the minimum required buffers. - Minimize pre-process (no perceivable delay between interaction and updates) - Solve issue with slow recomposites (as if threads refuse to stop) - Solve issue on load of .blend, auto-recomposites with image file loading block the UI now - Other developers (Sergey, Campbell and Brecht) are available to help Jeroen with Compositor work. - In order to tackle open issues, proposal is to postpone release to end of July. Ton Roosendaal suggested to then also allow for the next weeks work on approved topics in svn - like cycles updates, mask editing, Opencolor, etc. - Sergey proposes to release a testbuild this week, he'll coordinate it. 2) Other projects - Bastien Montagne: works on improvements for Grease Pencil to curve tool. * link all strokes into a single curve * record timing in strokes, to make a real-time path animation possible http://www.pasteall.org/33199/diff - Lukas Toenne works on custom nodes/node groups in 2.65. Below a sneak peek: http://www.pasteall.org/pic/show.php?id=33737 3) GSoC - There were no issues to note for the meeting log. Laters, -Ton- ------------------------------------------------------------------------ Ton Roosendaal Blender Foundation [email protected] www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers -------------------------------------------------------------------- mail2web - Check your email from the web at http://link.mail2web.com/mail2web _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
