[Bf-committers] Blender developer meeting notes - 24 June 2012

[j.bakker at atmind.nl]

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 ton at blender.org
Date: Sun, 24 Jun 2012 17:45:54 +0200
To: bf-committers at blender.org, editors at blendernation.com
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   ton at blender.org    www.blender.org
Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

_______________________________________________
Bf-committers mailing list
Bf-committers at blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://link.mail2web.com/mail2web