Hi Matheus, 1. The operation uses a mutex to make sure that that thread is safe to calculate the buffer. Most of the time you will see an initMutex in the initExcution. and in the initializeTileData a lock/unlock Mutex. Otherwise it is inherited from SingleThreadedOperation.
2. A chunk (what is a name that is being renamed to a tile at a later moment) is a part of the image that is being calculated. The user can select the tile size which is the size that the calculation is being done. (32x32, 64x64, etc). The output of every operation (or group of operations) are spliced in these tiles. The tile is scheduled in a workpackage. 3. The only downside I know is to identify which workpackages can be scheduled. I have a proposal in the wiki wich identifies this issue, but have not solve this in the current compositor. (https://wiki.blender.org/index.php/Dev:Ref/Proposals/Compositor2014) 4. A highlighted node will be drawn with a different color when it is being calculated. Artists can identify troublesome area's of the node setup. 5. All glare nodes & vector blur. Some settings of the glare nodes use old techniques, which can be improved with new techniques that are can be scheduled in a better way. Look at ghosting for example. Vector blur is a node that is the main pain as it is slow and the algorithm is quite complex. Part of the algorithm can be threaded (identify the depth and interesting area's for the blur) The blurring self in its current form is hard as it would write to the same memory from different threads. I hope this will help Greetings, Jeroen On 03/17/2016 07:44 PM, Matheus Sousa Faria wrote: > Hi, > > I thought that IRC would be better to not spamming the others with > questions related to my proposal. But you guys are right, we are in > different time zones, so it easier through here. > Here are my questions: > > 1. How can I identify nodes that require full buffer on the input (like > it says in the idea description)? > 2. What is a chunk? The chunk is the representation of a node? Because I > saw that the ExecutionGroup decide when is going to schedule an operation > by evaluating if the chunk is ready to be evaluated. > 3. WorkScheduler Queue: is it a bottleneck? Because it uses a single > queue for multiples threads in the device vector. Is there a real race > condition here or you managed to avoid it? If there is a race condition, > is > that a point where I should improve on my project? Because we can create > one queue for each thread, and when one thread gets idle it steals the > work > from the cold end of another queue. > 4. What is a highlighted node? > 5. What nodes should I look more carefully? Do you guys have an idea of > the most used or those that cause more time overhead for the artists? > > Thanks, > Matheus de Sousa Faria > > On Thu, Mar 17, 2016 at 9:35 AM Jeroen Bakker <[email protected]> wrote: > >> Hi Matheus, >> >> Monique's handle is mnq and mine is atmind. Best to reach us using this >> email list. >> >> Regards, >> Jeroen >> >> On 03/17/2016 07:23 AM, Sergey Sharybin wrote: >>> Hi, >>> >>> My IRC nick is hackerman. But why not ask questions here in the ML? It'll >>> be easier since we all are in different timezones so reading ML will make >>> it easier to follow all the conversation. >>> >>> On Thu, Mar 17, 2016 at 9:03 AM, Matheus Sousa Faria < >>> [email protected]> wrote: >>> >>>> Hello everyone! >>>> >>>> I'm Matheus, I am a Software Engineering Student. And I am applying for >>>> the Improved threadability of Compositor nodes project. I've already >>>> started to look into it. Right now, I am trying to identify the nodes >> that >>>> I will work on and figuring out how the compositor nodes architecture >>>> works. >>>> I am writing my proposal, but, to finish it, I need to clear out some >>>> questions with the possibles mentors of this project: Sergey Sharybin, >>>> Lukas Tönne, Jeroen Bakker, Monique Dewanchand. Where can I find them? >> I am >>>> already on IRC (@MatheusFaria), so if someone knows their nicks, I can >>>> contact them through there. >>>> >>>> Thanks, >>>> Matheus de Sousa Faria >>>> -- >>>> Matheus de Sousa Faria >>>> Software Engineering Student >>>> _______________________________________________ >>>> Bf-committers mailing list >>>> [email protected] >>>> http://lists.blender.org/mailman/listinfo/bf-committers >>>> >>> >> _______________________________________________ >> Bf-committers mailing list >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers >> _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
