Dorian Fevrier's blog - Mot-clé - multithreadingJe m’appelle FEVRIER Dorian, je suis infographiste 3D passionné par mon métier, l’informatique en général, l’internet, la programmation et l’évolution de tout ce petit monde. Vous trouverez sur ce blog des tutoriaux, mes coups de cœurs, avis, etc.2024-01-02T23:48:05+01:00FEVRIER Dorianurn:md5:695d9c73474c33ce3dab043823509c4bDotclearMultithreading for Visual Effects book reviewurn:md5:bfffa7c4e38ece8de4f0ef6fccb0caee2014-08-24T19:14:00+02:002014-10-09T14:08:02+02:00NarannMes coups de coeurbookenhoudinilibeemultithreadingopenclopensubdivopenvdbprestoreviewtbbvfx<p><img src="https://www.fevrierdorian.com/blog/public/billets/2014_04_24_multithreading_for_vfx_review/multithreading_for_vfx_review_tn.png" alt="multithreading_for_vfx_review_tn.png" style="float:left; margin: 0 1em 1em 0;" title="multithreading_for_vfx_review_tn.png, août 2014" height="150" width="150" />In programming, nothing is better than a good book. You will often ear that from many experienced programmers.</p>
<p>Today I want to share my humble review of <a href="http://www.crcpress.com/product/isbn/9781482243567" hreflang="en">Multithreading for Visual Effects</a>.</p>
<p>This book has been created after the <a href="http://s2013.siggraph.org/attendees/courses/events/multithreading-and-vfx" hreflang="en">Multithreading and VFX courses session</a> at Siggraph 2013 where some companies were presenting how they used multithreading in their tools. The results where so interesting they decide to gather them and make a book.</p>
<p>As this kind of <em>niche</em> book is rare in the CGI, let's talk about it! :enerve:</p> <p><a href="https://www.fevrierdorian.com/blog/public/billets/2014_04_24_multithreading_for_vfx_review/multithreading_for_vfx_review_001.jpg" title="multithreading_for_vfx_review_001.jpg"><img src="https://www.fevrierdorian.com/blog/public/billets/2014_04_24_multithreading_for_vfx_review/.multithreading_for_vfx_review_001_m.jpg" alt="multithreading_for_vfx_review_001.jpg" style="display:block; margin:0 auto;" title="multithreading_for_vfx_review_001.jpg, août 2014" height="560" width="420" /></a></p>
<h3>Chapter 1: Introduction and Overview (by James Reinders)</h3>
<p>The prologue is an ode to multithreading (What a surprise :siffle: ). James Reinders is an engineer from Intel and we can say he know his job!</p>
<p>What I'd really liked is that multiple faces of multithreading are presented (multi task vs multi thread, vectorization, etc...), explaining technically how they work and giving pros and cons for each of them.</p>
<p>I must talk about how <a href="https://en.wikipedia.org/wiki/Threading_Building_Blocks" hreflang="en">TBB</a> is presented. In general TBB is considered as a serious choice for multithreading programs (Almost every program in the book use it). And from what I've read from the documentation, it deserves it. To be honest, TBB make we want to master C++ templates and I totally understand you would choose TBB if you are familiar with them.</p>
<p>But I regret James didn't spend more time and love presenting alternatives. I know it's a Intel guy but clearly, TBB receive a lot of emphasis and it totally hides the others. I think it's quiet a shame because a lot of chapters talk about TBB too. Alternatives are "presented" but not as in depth than TBB.</p>
<p>Anyway, you get the message: TBB is good, eat some! :banaeyouhou:</p>
<h3>Chapter 2: Houdini: Multithreading Existing Software (by Jeff Lait)</h3>
<p><img src="https://www.fevrierdorian.com/blog/public/logos/.houdini_black_s.png" alt="houdini_black.png" style="display:block; margin:0 auto;" title="houdini_black.png, sept. 2014" height="56" width="240" /></p>
<p>A lot of multithreading informations you can find here and there, even on books (including this one), are very academic. They explain how you <em>should</em> write code.</p>
<p>This chapter is interesting because it take the invert approach: How convert old code to modern multithreading. Jeff present different concrete problems and how they choosed to solve them, what they lost doing so and how, if it was possible, they can still save what can be.</p>
<p>What I really love in this chapter is how unacademic it is. Some example's code solution make you realize: "Yeah! I could do that... It's weird but it works pretty well!". The best examples are how Houdini handles the thread creation time (because create a thread is long actually) where the datas to compute doesn't worth the threads creation time. Easy trade of: If data_count < 5000 : compute in the main thread! :IFuckTheWorld:</p>
<p>You will never see this kind of solution on an academic book but you will never have more efficient that this! :D</p>
<p>Each case is interesting. While not relevant for a general experience, read them all train your brain in <em>why</em> you should avoid to do things like this and how to react when you see them.</p>
<p>I must confess I'd read <a href="http://www.multithreadingandvfx.org/course_notes/MultithreadingHoudini.pdf" hreflang="en">the original Side Effect paper</a> after the Siggraph 2013. This make me realize some work has been done to reorganize and better explain the examples. I remember I were pretty lost with some examples in the original paper but it was not a problem with the book so I guess this examples where better explained (or my general programming skills has increase from that time).</p>
<p>This chapter was frustrating for me because I wanted to know more! More examples, more tricky problems to solve, more "here boys is what you've got if you write code this way".</p>
<p>If you want to know more about how Houdini works under the hood you can find this <a href="http://forums.odforce.net/topic/17105-short-and-sweet-op-centric-lessons/#entry104263" hreflang="en">very interesting post</a></p>
<h3>Chapter 3: The Presto Execution System: Designing for Multithreading (by George ElKoura)</h3>
<p>Interactivity is the key of this chapter.</p>
<p>The first part is not very interesting. George explain the technical goals and constrains they had. This is good, but he spend too much time on things you often know without explain what where the specific implication in Presto ("vectorization is important because blah blah", "you should organized you data because blah blah"). Its kind of redundant with the first chapter. I would have put every general multithreading stuff explained in the first chapter and let the study case focus on implementation.</p>
<p>However, the second part is very interesting. Here are the smart choices they had to do. The way they handle threads in Presto (especially how graph computation is separate) is very different than an "academic" graph network. Indeed, Presto had to deal with "time" because time is the animator toy. He also talk about interactivity and the relation betweens "batch" threads (responsive of math computation) and UI threads and how they tried to avoid any kind of lag in interactivity (interrupt or not interrupt, that is the question). It's very well explained while not enough detailed for my taste. They finish with a small (2 pages) concrete code example of how a "naive" geometric deformer code can be multithreaded. It's an interesting code snippet because it present a general problem (but he give a "general" solution).</p>
<p>If you want to have an <em>overview</em> of how Presto work under the hood, you will like this chapter. The word <em>overview</em> is a good word here because George only focus on multithreading (it's what this book is supposed to do so...) but he often talk about things implicitly that (I guess) you could understand if you were familiar with Presto (what a rig look like in Presto?!). This "abstraction" of some technical details can be frustrating. :injures:</p>
<p>I also felt a "everything were fine and rosy" like if there was no complications, no multithreading specific "problems", no "what a silly idea we had there". I mean, in development, there is always moments where the vision and abstracted concepts face reality and involve serious trade of, moments where the academic approach can't be applied <em>as it</em>. This is even more glaring when you compare to the following chapter.</p>
<h3>Chapter 4: LibEE: Parallel Evaluation of Character Rigs (by Martin Watt)</h3>
<p>This one surprise me a lot! It shine in many places!</p>
<p>From the first pages of the chapter I was not very excited. LibEE is presented as a multithreaded Dependency Graph... You could almost read "Maya DG is not relevant anymore so there was no alternative: We have to write our own". I'm not a big fan of the classic "Dependency" Graph pattern. I'm not sure it's a good approach for multithreading and more I was reading the chapter more it confirm my humble opinion (but you know, I'm not working at Dreamwork so there is maybe a lot of valid reasons...). While the Dreamwork team seems to have done a big job to bypass some of the limitations a Dependency Graph could have, many sections make me realize "why" DG is not straightforward for massive multithreading. I tend to prefer a compiled approach like <a href="http://www.sidefx.com/docs/houdini13.0/vex/" hreflang="en">VEX</a> or what Presto team choosed but reading the rest of the chapter, I'm not sure the Dreamwork RnD team has all the needed discretion (and resources?) to choose a such approach.</p>
<p>And this is one point where this chapter is amazing: You "feel" the production. I mean, the deadlines, riggers ranting over the new tools <em>because-it-was-better-to-use-the-old-shitty-Maya-DG-before</em>. I'm a big fan of various few line examples of discussions betweens various peoples involved (copy of rigger mails make me ROFL). It also explained how they have to <em>train</em> riggers to <em>think</em> multithreaded. The various bench tools they provided to riggers to find where the <em>critical paths</em> were and when "cut" them (yet another point to stay away from DG IMHO). LibEE follow the typical VFX situation where tools are developed and used at the same time (unlike Presto team that seems to have worked far away the production before release even if this is not clearly stated). Handle such situation is an art from a development perspective as goals often change and this chapter explain (a little) how handle this.</p>
<p>The second impressive point is the experience they share with the tests they did in production. I was sad the Presto chapter where only mentioning few technical points to be aware of in general (NUMA, bandwith, Hyperthreading, etc...) without provide any graph or so, while the Dreamworks team not only explain, but show <em>where</em> this points are problematics, how they bench them and what they observed. And they became very far at this point. Once again, this is not academic, this is true use cases decorticates.</p>
<p>So a very cool and clear chapter! One of the most valuable of this book. I would have love the same level of in depth discussion with Presto.</p>
<h3>Chapter 5: Fluids: Simulation on the CPU (by Ronald D. Henderson)</h3>
<p>lol this one is massive. If you love code, maths and computer science, you would love it! :aupoil:</p>
<p>There is some interesting OpenMP/TBB comparison codes (with TBB C++11 lambdas, first time I read such! :gne2: ). If you are not comfortable with C++, that's gonna be hard (and kind of disrupting).</p>
<p>About maths, I must admit I've smiled a lot each time I realize "I don't get anything! :baffed: " after read some lines.</p>
<p>In others chapters of the book, a lot of explanation is often presented with sentences like: "We measure the core efficiency by dividing the bench time by the number of core" (you know, something humanly readable). In this chapter, such sentence are actually presented by a tiny mathematical formulation following by: "Where <em>p</em> is the relational infrastructured derived of the inversed logarithm's result of the number of core and <em>n</em> is the time of the benchmark expressed in second (ISU-CIPM 1967)". Yeah, I exaggerate of course but as I'm not used to mathematical formulations this is exactly the feel I had reading this kind of sentences for the first time. And I laugh even more when, after some digging minutes, I realize all of this could be said with a simple sentence. Haha! :smileFou:</p>
<p>But I had the opportunity to work with mathematicians (or peoples loving maths in general) and they tend to use math equations to model anything (even such trivial things than the average time peoples spend at lunch or to be late at a meeting) so it reminded me all this funny moments. :jdicajdirien:</p>
<p>I'd also really loved the quick <a href="http://www.openvdb.org/" hreflang="en">OpenVDB</a> presentation. I had often heard about OpenVDB and never know how it was working under the hood. This tiny presentation was perfect. There is a lot of widely open source libraries used in the CGI but they lack of easy-to-get presentations and there is a lot of CG artists, while not true developers, are very technical and would benefit of advanced presentations of such libraries in their day to day work. So VFX artists, this presentation is for you!</p>
<p>For the rest, it was too <em>mathematics</em> for me. If you find it hard to read mathematics equation you would be lost in this chapter. I did so I can't really comment how valuable it is. Actually, I think you could be right with it if you are familiar with all "fluid/liquid" simulation maths.</p>
<h3>Chapter 6: Bullet Physics: Simulation with OpenCL (by Erwin Coumans).</h3>
<p><img src="https://www.fevrierdorian.com/blog/public/logos/.Bullet_Physics_Logo.svg_s.png" alt="Bullet_Physics_Logo.svg.png" style="display:block; margin:0 auto;" title="Bullet_Physics_Logo.svg.png, sept. 2014" height="90" width="240" /></p>
<p>What a cool chapter I was not expecting. :bravo:</p>
<p>I'm not so much interested by physics in general but I must admit Erwin did a great work to decorticate his nice library. It's also the only chapter talking about <a href="http://en.wikipedia.org/wiki/OpenCL" hreflang="en">OpenCL</a> and GPU low level computation. While it's a very fast overview, it's well described and every steps of the various collision detection/repulsion computation of the Bullet libs that have been parallelized are well highlighted. This give a very interesting overview of how a physic engine can work which is something pleasant to know in VFX.</p>
<p>There is also a lot of tiny and very clear schema. I tend to prefer a lot of tiny, one problem focused, schema than bigger ones, you can see in the Presto eating places where some other schemas could have been interesting.</p>
<p>It finished on more advanced principles.</p>
<p>One of the clearest and pleasant chapter to read. :marioCours:</p>
<h3>Chapter 7: OpenSubdiv: Interoperating GPU Compute and Drawing (by Manuel Kraemer)</h3>
<p>I was waiting for this one impatiently and I've not been disappointed, very cool chapter. It's composed of two parts.</p>
<p>The first part talk about the iterative Catmull Clark subdivision, its history, why a "universal-matching" subdivision is needed, how it was working and how they multithread it. If you are not familiar with geometry <a href="http://www.flipcode.com/archives/The_Half-Edge_Data_Structure.shtml" hreflang="en">hard edge data structure</a> you will certainly be lost. They also give some shy benchmarks and conclude iterative subdivision design, while a need for off-line rendering, does not fit well to realtime constraints. I've been surprised they didn't talk about how they organize the memory to improve cache and benefit vectorization. I'm not an expert but after have read the previous chapters, I wonder if there was not other things to do to improve performances. I guess they are just not presented because the benefit where not such interesting who know... But to have distantly followed OpenSubdiv development I have the impression they quickly jump to the GPU side as it was maybe a more important step for the studio (Presto seems to rely on it), leaving the CPU code as "good enough".</p>
<p>The second part talk about how OpenSubdiv use GPU (and OpenGL) to offer realtime subdivision using realtime tessellation shaders available with OpenGL. Once again, I enjoyed the GPU presentation and how you are supposed to organize your batchs to benefit from it (and deal with strong GPU limitation). Edge Crease (a pivotal point of OpenSubdiv) seems to have been a problem (so does the triangle/quad/polygon) but I really like how they handle it: They separate each set of the geometry to apply different algorithms. The separation process is done once as the topology doesn't change, and the GPU simply recompute the tessellation shader according to the face set. Interesting and pragmatic approach to apply the most efficient algorithm to various part of a single geometry (while I guess it should complicate the code).</p>
<p>Off topic, I wonder if creases were a good idea for an open subdiv library. It fit very well with the <em>surface limit</em> concept dear to Renderman but:</p>
<ul>
<li>This concept doesn't seems to fit well with raytracers that need true geometry to raycast.</li>
<li>It seems that you need high subdivision levels to benefits of strong (but still smooth) crease edges were a simple bevel or double edge could do the job (it certainly make the geometry more complex indeed).</li>
<li>It seems to complicate and fragment the subdivision code.</li>
<li>Fragmented code? Fragmented data structure? What impact it could have on memory (efficient access and size)?</li>
</ul>
<p>If you can't subdivide for hell, a last option could be to represent creases modifying the normal but you would have to deal with shading stuff and this is not what OpenSubdiv is supposed to do (beside all the troubles you could have to "merge" the other shading normals).</p>
<p>So I wonder if creases where not something Pixar (and mainly Pixar) absolutely needs and this would explain while a such "exotic" concept fall in OpenSubdiv.</p>
<p>Notice the <a href="http://www.fxguide.com/quicktakes/opensubdiv-3-0-coming/" hreflang="en">next OpenSubdiv is coming</a> and seems to have some other studios contributions. It's a good thing as it seems to became a strong part of Maya. :)</p>
<h3>Conclusion</h3>
<p>Well... Good book! :D</p>
<p>There is inconsistencies between chapters. Some are very deep (LibEE, Fluids, Bullets), and others just touch the surface and finish too soon (Houdini, Presto).</p>
<p>So this book is exactly what it states: Multithreading for Visual Effects. And it focus on how multithreading can be/is used in VFX. But as the chosen softwares are very interesting (Seriously, Side Effect, Pixar, Dreamworks!) it can be sometime frustrating!</p>
<p>The book is very nice (hard cover!) while a bit pricey (hard cover?). But it's about a specific domain so it's ok (is there any book that talk about such softwares?). Most of the time it will be your studio that will buy it so... :P</p>
<p>Does it worth it? If you have to code on VFX softwares, don't hesitate. You will not find massive "ready to use" resources but it's like if you had talks with this guys sharing their experience, they explain how their babies works, what is important and what is a mess. Not sure you can find such infos everywhere.</p>
<p>If you are an artists enjoying technical stuff, I wouldn't recommend this book. It's very focus on development, you will not find multithreading tricks that will enhance your work. Anyway, I encourage to prick it to your RnD and see by yourself! :P</p>
<p>After reading this book, I'm sure I could pay for books (even with soft cover!) that focus on in depth architecture of a specific VFX software from a dev point of view (Houdini, Presto, Maya, Nuke). How datas are managed, what data structures look like, how a specific kind of operations are done etc... And not just an overview!</p>
<p>From the time I've been on the artistic side, I've tried to understood how softwares where technically working (because most of the time they were working bad/not as expected/I DIDN'T SAVE MY WORK!!!! etc...). I'm now able to understand the "logic" part of them so I want to read such high end code more!</p>
<p>Unfortunately, I missed a lot of valuable informations because of my lack of mathematic skills. I'm more familliar with computer science in general. I mean, I know what 4x4 matrices are, what they are used to, I know what a dot/cross product is and how it can be used to achieve various stuff but thats pretty much all. I was angry against myself to not be able to read and understand some advanced part of the code (I skip a lot of the Fluids chapter. :( ).</p>
<p>What is also interesting is to gather interesting Siggraph courses to make a book. I really like the idea while I would suggest to favor courses that go more in depth or with a lot of implementation studies (Once again, Presto is very frustrating). I also tend to prefer books than pdf.</p>
<p>I don't know about the success of this book but I've heard many peoples interested in it so we could hope for... Let say... "Alembic/OpenVDB/OpenEXR code review and use cases" with a lot of in depth explanation of the foundation and infrastructure of each of this libs. :D</p>
<p>Hope you enjoyed this humble review! I would be very interesting to ear your opinion if you also read this book so feel free to comment. :)</p>
<p>Dorian</p>
<center>:marioCours:</center>
Le livre Multithreading for Visual Effectsurn:md5:2f9c1853ac39265f4efdfd1782d0fbd02014-08-24T19:13:00+02:002014-09-19T15:48:46+02:00NarannMes coups de coeurfrhoudinilibeelivremultithreadingopenclopensubdivopenvdbprestotbbvfx<p><img src="https://www.fevrierdorian.com/blog/public/billets/2014_04_24_multithreading_for_vfx_review/multithreading_for_vfx_review_tn.png" alt="multithreading_for_vfx_review_tn.png" style="float:left; margin: 0 1em 1em 0;" title="multithreading_for_vfx_review_tn.png, août 2014" height="150" width="150" />En code, rien ne vaut un bon bouquin. Vous entendrez souvent ce conseil de la part de développeurs expérimentés.</p>
<p>Aujourd'hui je vous propose un billet sur le livre <a href="http://www.crcpress.com/product/isbn/9781482243567" hreflang="en">Multithreading for Visual Effects</a>.</p>
<p>Ce livre a été publié après <a href="http://s2013.siggraph.org/attendees/courses/events/multithreading-and-vfx" hreflang="en">la session de cours Multithreading and VFX</a> au Siggraph 2013 où un certain nombre de studios présentaient comment ils avaient utilisés le multithreading dans leur outils. Les papers étaient suffisamment intéressant pour qu'ils décident de les rassembler en un livre.</p>
<p>Dans la mesure ou ce type de livre fait parti du marche de <em>niche</em> que sont les VFX, parlons en! :enerve:</p> <p><a href="https://www.fevrierdorian.com/blog/public/billets/2014_04_24_multithreading_for_vfx_review/multithreading_for_vfx_review_001.jpg" title="multithreading_for_vfx_review_001.jpg"><img src="https://www.fevrierdorian.com/blog/public/billets/2014_04_24_multithreading_for_vfx_review/.multithreading_for_vfx_review_001_m.jpg" alt="multithreading_for_vfx_review_001.jpg" style="display:block; margin:0 auto;" title="multithreading_for_vfx_review_001.jpg, août 2014" height="560" width="420" /></a></p>
<h3>Chapitre 1: Introduction et vue d'ensemble (par James Reinders)</h3>
<p>Le prologue est une ode au multithreading (Sans blagues :siffle: ). James Reinders est ingénieur pour Intel et on peut dire qu'il connait son boulot!</p>
<p>J'ai pas mal apprécié comment les multiples facettes du multithreading sont présentées (multi tache vs multi thread, vectorisation, etc...) ainsi que les explications techniques sur comment chacune d'elle fonctionne, avec leurs avantages et inconvénients.</p>
<p>Je me dois de parler de la manière dont <a href="https://en.wikipedia.org/wiki/Threading_Building_Blocks" hreflang="en">TBB</a> est présenté. TBB est généralement considéré comme une (la?) librairie de choix pour des logiciels multithreadés (Presque tous les logiciels du livre l'utilisent). Et de ce que j'ai pu lire de la documentation, c'est mérité. Pour être tout à fait honnête, TBB me donne réellement envie de maitriser les templates C++ et je comprends parfaitement qu'on puisse se tourner vers TBB rien que pour ça.</p>
<p>Mais je trouve dommage que James n'ai pas passé autant de temps et d'amour à présenter les alternatives. Je sais bien, c'est un bonhomme d'Intel mais clairement, TBB reçoit tellement d'éloge dans ce chapitre (et tout au long du livre) qu'il en occulte complètement les autres librairies (qui sont "présentées" mais pas de manière aussi clair que TBB).</p>
<p>Bref, vous comprenez assez vite le message: <em>TBB cay bon, mangez-en!</em> :banaeyouhou:</p>
<h3>Chapitre 2: Houdini: Multithreader un logiciel existant (par Jeff Lait)</h3>
<p><img src="https://www.fevrierdorian.com/blog/public/logos/.houdini_black_s.png" alt="houdini_black.png" style="display:block; margin:0 auto;" title="houdini_black.png, sept. 2014" height="56" width="240" /></p>
<p>Bon nombre des informations qu'on peut trouver ici et la, y compris dans les livres (celui ci inclus), sont très académiques. Elles expliquent comment vous <em>devriez</em> écrire du code.</p>
<p>Ce chapitre est très intéressant car il prend l'approche inverse: Comment convertir du vieux code en un code <em>scalable</em> (qui se parallélise efficacement). Jeff présente différents problèmes concrets, la ou les les méthodes qu'ils ont choisis pour les résoudre, ce qu'ils ont perdus au passage et ce qu'il ont pu sauver.</p>
<p>Ce que j'adore dans ce chapitre est à quel point il est anti-académique. Certains code d’exemples m'ont vraiment fait réagir: "Je pourrais faire ça... Ça serait bizarre mais ça marcherait plutôt pas mal!". Le meilleur exemple est la façon dont Houdini gère la latence de création des threads (car créer un thread est assez long) quand la quantité de données a calculer ne vaux pas le temps de création des threads. Accrochez vous: If data_count < 5000 : compute in the main thread! :IFuckTheWorld:</p>
<p>Vous ne trouverez jamais ce genre de "solutions" dans un livre académique mais vous ne trouverez jamais plus efficace que ça sans avoir à modifier le code à milles endroits! :D</p>
<p>Chaque exemple est intéressant (bien que souvent très spécifique). Les lires entraine votre cerveaux sur <em>pourquoi</em> vous devriez faire les choses de tel ou tel façon et comment réagir quand vous voyez un truc qui semble louche.</p>
<p>Je dois avouer que j'avais lu <a href="http://www.multithreadingandvfx.org/course_notes/MultithreadingHoudini.pdf" hreflang="en">le paper original de Side Effect</a> après le Siggraph 2013. J'ai d'ailleurs remarqué qu'un petit travail de réorganisation a été fait et certains exemples m'ont paru mieux expliqué. Je me rappel avoir été un peu perdu avec certains des exemples du paper original mais je n'ai eu aucun soucis à comprendre ceux du livre. J'en conclu donc qu'une bonne relecture a été faite (ou que je suis plus capable de lire du code qu'avant ce qui est fort probable).</p>
<p>J'ai été super frustré par la fin du chapitre qui arrive trop vite... On en veut encore! :grenadelauncher: Plus d'exemples, plus de problèmes tordu (mais concrets) à résoudre!</p>
<p>Si vous souhaitez en savoir plus sur comment Houdini fonctionne sous le capot, <a href="https://www.fevrierdorian.com/blog/post/2013/04/24/Houdini-sous-le-capot">j'avais traduis</a> <a href="http://forums.odforce.net/topic/17105-short-and-sweet-op-centric-lessons/#entry104263" hreflang="en">un post très intéressant</a> que je vous invite à lire.</p>
<h3>Chapitre 3: Le système d’exécution de Presto: Architecturer pour le Multithreading (par George ElKoura)</h3>
<p>L'interactivité est le mot clef de ce chapitre.</p>
<p>La première partie n'est pas particulièrement intéressante. George explique les ambitions et les contraintes techniques. C'est chouette pour la partie animation (temps de latence, interactivité, etc...), mais il passe définitivement trop de temps sur des choses que tu connais souvent déjà sans vraiment expliquer les implications spécifiques à Presto ("La vectorisation du code est importante car blabla", "Il faut organiser ces données comme ça sinon blabla"). Le coté très général des conseils fait presque redondance avec le premier chapitre. Il aurait peut être été préférable de développer tout ces points dans le premier chapitre (plutôt que de brosser TBB dans tous les sens :trollface: ) et laisser chacun des autres chapitre se focaliser sur l’implémentation.</p>
<p>Cela dit, la second partie est vraiment superbe! Vous y trouverez pleins de petites choses qu'il faut avoir en tête si vous souhaitez développer pour des logiciel d'animation. La gestion des threads dans Presto (tout particulièrement la manière dont le graph d'evaluation est compilé puis exécuté) m'a semblé vraiment moderne, bien pensé et concret. Par concret j'entends qu'on est pas dans des choses génériques mais vraiment spécifiques. La gestion du temps (cache des géométries), la gestion de l'interface utilisateur avec une anticipation des valeurs modifié pour mieux préparer les "batchs" de thread (si un utilisateur modifie les contrôleurs d'un personnage, on peut vraisemblablement penser qu'il ne modifiera pas le cache des autres, inutile d’arrêter leurs threads car un thread coute cher à lancer rappelez vous). Chaque détail permettant d'éviter des ralentissements et d'augmenter le "rendement" des graphs est présenté.</p>
<p>Tout ceci est très clairement expliqué même si ça manque un peu de détails à mon gout (j'aime bien avoir des explications de cas un peu tordu).</p>
<p>Ils finissent avec un petit exemple de code (2 pages) sur comment multithreader un déformer géométrique simple. C'est un exemple intéressant car il présente un cas assez général mais qu'on peu rencontrer souvent en prod quand on est rigger. Vous vous en doutez, la solution est tout aussi "général".</p>
<p>Si vous souhaitez avoir un survole de comment Presto fonctionne sous le capot il y a de fortes chances que vous appreciez ce chapitre. Le mot "survol" est le bon terme car George ne se focalise que sur l'aspect multithreading (c'est le titre du livre donc difficile de le lui reprocher...) mais il parle souvent de choses implicites qu'il est difficile de cerner si on n'est pas habitué a Presto (j'imagine). A la fin du chapitre, on ne sais pas vraiment a quoi ressemble un rig dans Presto (relation entre les nodes et la UI, les nodes les plus bizarres/spéciaux/gros, etc...). Cette "abstraction" de certains détails techniques est souvent frustrante. :injures:</p>
<p>J'ai également ressenti une sorte de "tout va pour le mieux dans le meilleur des mondes". Comme si il n'y avait jamais eu de complication, aucun souci spécifique au multithreading (qui est pourtant un techno assez jeune en terme de paradigme), aucun "on a pensé faire ça car blabla mais on c'est rabattu sur ça car blabla". Sincèrement, en développement il y a toujours des moments ou la vision "abstraite" des concepts (vision nécessaire à l’architecture général d'un logiciel, surtout dans les premières années) se mange les cas non prévus de la réalité dans les dents. Des moments ou un juste milieu, un moindre mal est nécessaire. C'est d'autant plus flagrant quand on compare avec le chapitre suivant.</p>
<h3>Chapitre 4: LibEE: Évaluation en Parallèle des Rigs des Personnages (par Martin Watt)</h3>
<p>Celui là m'a littéralement surpris! Il se lit comme une histoire!</p>
<p>J’avoue que les premières page ne m'ont pas particulièrement fait sauté au plafond . LibEE est présenté comme un graph de dépendance (Dependency Graph ou DG) multithreadé... On pourrais presque lire entre les lignes "Le DG de Maya est totalement à l'Ouest alors on l'a réécrit". Le problème c'est qu'un graph de dépendance "a la Maya" ne rime pas forcément avec performance, surtout dans le cas d'un rig. Le fait que chaque node soit exécuté indépendamment puis passe son résultat au node suivant via des attributs, le tout badigeonné d'une dépendance inter-attributs (ou certains attributs d'entrés peuvent modifier certains des attributs de sortie mais pas tous) et vous obtenez un graph qui passe plus de temps a évaluer les dépendances pour savoir quel node exécuter qu’exécuter réellement les calculs des nodes (avouez que c'est con quand le node ne fait au final qu'une simple addition :siffle: ). Et c'est vrai pour Maya comme pour n'importe quel autre implémentation qui suit cette approche. La vitesse d’exécution d'un graph dépend souvent énormément de son "allure" et il n'est pas rare qu'un graph un peu tordu plombe drastiquement les performances. J'ai tendance à préférer l'approche compilé d'un <a href="http://www.sidefx.com/docs/houdini13.0/vex/" hreflang="en">VEX</a> ou d'un Presto mais en lisant le reste du chapitre, je ne suis pas sur que la RnD de Dreamworks ait pu disposer de toute la latitude (et des ressources?) nécessaires.</p>
<p>Après, je ne suis pas dev a Dreamworks et il y a peut être un autre paquet de bonnes raisons... :dentcasse:</p>
<p>Mais bien que l'équipe de Dreamworks semble avoir fait un travail colossale pour contourner les limitations qu'implique ce type de DG, plusieurs sections tendrons a confirmer mes (humbles) hypothèses.</p>
<p>Et quand je parle de travail colossale je ne suis pas en dessous de la vérité. C'est la raison principal pour laquelle ce chapitre est exceptionnel: Vous "sentez" la production. Vous savez, les deadlines, les riggers qui râle sur les nouveaux outils "car-le-vieu-DG-de-Maya-il-aytay-mieu". Je suis un gros fan des quelques exemples de discussions entre les différentes personnes impliquées dans le projet (avec une petite copie d'un mail bien senti lol). Il explique aussi comment ils on eu à <em>apprendre</em> à leurs riggers à <em>penser</em> multithreadé (chose qui n'était pas prévu au départ). La présentation des différents outils de bench fourni au riggers pour qu'ils puissent trouver eu même les <em>critical paths</em> de leur code et qu'ils les "coupe" ou "blend" la logique en un seul node (un autre argument pour se tenir loin d'un DG IMHO). LibEE semble avoir suivi la situation typique d'une prod de VFX/anim ou les outils sont développé et utilisé en même temps (à l'inverse de Presto ou l'équipe semble avoir travaillé loin de la production, même si ce n'est pas clairement dit, avant de relâcher leurs outils). D'un point de vu développement, gérer une tel situation est un art en soit dans la mesure ou les objectifs/contraintes changent au fil du temps et ce chapitre explique (un petit peu) comment gérer ça.</p>
<p>Si vous êtes développeur et que vous pensez que les studios de VFX échouent car ils ne sont pas assez carré, passez ce chapitre, vous allez détester car c'est vraiment des situations de terrain, du vécu. Les autres, si vous voulez bosser en VFX il y a vraiment de quoi vous inspirer (ou vous faire fuir, au choix!). Et les derniers, ceux qui bossent déjà en VFX habitué des <em>patchs-en-prod-parce-que-cay-super-plus-urgent-que-les-autres-urgences</em>, vous allez vous sentir moins seul! :baffed:</p>
<p>Le second point concerne les expériences et tests qu'ils ont effectués en prod ou de manière plus formel. J’étais déçu que le chapitre Presto ne mentionne que quelques points techniques souvent assez connus (effet <a href="https://fr.wikipedia.org/wiki/Non_Uniform_Memory_Access" hreflang="fr">NUMA</a>, bande passante de la RAM, Hyperthreading, etc...) sans fournir aucun graph ou expliquer en quoi ces problèmes impactaient directement Presto. Ici, non seulement les gars de Dreamworks expliquent ce qui les amènes à faire tel ou tel test mais ils fournissent une quantité de détails impressionnant qui explique, de manière très clair, <em>comment</em> et <em>pourquoi</em> tel ou tel effet apparait. Et on peut dire qu'ils ont poussé le bouchon très loin. Une fois encore, tout ces exemples ne sont pas académiques, ce sont de vrais <em>use cases</em> décortiqués et analysés très clairement. Certains tests expliquent même pourquoi un effet attendu n'est, en pratique, pas un problème.</p>
<p>C'est donc un chapitre super chouette! Un des plus intéressant du livre. J'aurais aimé que le chapitre de Presto sois aussi poussé.</p>
<h3>Chapitre 5: Fluides: Simulation sur le CPU (par Ronald D. Henderson)</h3>
<p>lol celui la est massif. Si vous aimez le code et les maths vous allez être servi! :aupoil:</p>
<p>Il y a quelques codes de comparaison entre OpenMP et TBB (avec du lamdbas C++11, première fois que j'en vois! :gne2: ). Si vous n'êtes pas à l'aise avec le C++, ça risque d'être assez dure (et un peu déroutant).</p>
<p>Pour ce qui est des maths, je dois admettre que j'ai pas mal rigolé chaque fois que je me disais "tin mais je capte rien! :baffed: " après quelques équations (et leur magistrales explications).</p>
<p>Dans les autres chapitres du livre, beaucoup d'explications se font sous la forme de phrases assez basiques tel que: "Nous mesurons l’efficacité des cores en divisant le temps de calcul par le nombre de core" (enfin un truc compréhensible quoi...). Dans ce chapitre, de tel phrases serait plutôt présenté sous la forme d'une petite équation de math bien senti suivi d'un: "Ou <em>p</em> est la dérivé relationnel d'infrastructure de la logarithme du nombre de core et <em>n</em> est le temps de calcul exprimé en second (ISU-CIPM 1967)". Bien sûr j'exagère mais dans la mesure ou je ne suis pas habitué aux équations mathématiques c'est exactement l'effet que ça m'a fait à la première équation. Et j'ai d'autant plus rie quand, après m’être bien trituré pour déchiffrer et comprendre tout ça j'ai réalisé qu'on pouvait résumer ça en une phrase... Haha! :smileFou:</p>
<p>Mais j'ai eu l’opportunité de travailler avec des matheux (ou des gens qui apprécient les maths d'une manière général) et ils ont cette tendance à jouer avec les équations mathématiques partout, y compris pour des trucs anodins (comme le temps moyen que passe les gens à la cantines en fonction des menus proposé, ou bien le temps de retards moyen des réunions suivant les dates de livraison) et ça m'a rappelé tout ces moments assez drôles. :jdicajdirien:</p>
<p>J'ai également apprécié la petite présentation de <a href="http://www.openvdb.org/" hreflang="en">OpenVDB</a>. J'ai souvent entendu parlé de OpenVDB mais je n'ai jamais compris comment il marchait sous le capot. Cette petite présentation est parfaite! Il y a un bon nombre de librairies open source utilisé dans en CGI mais elles manques souvent de présentations faciles à comprendre alors qu'il y a beaucoup de graphistes qui, bien qu'il ne soit pas développeurs, sont assez techniques et pourrais bénéficier d'une meilleur compréhension de ces librairies dans leur travail au quotidien. Donc les VFX boys, cette présentation est pour vous!</p>
<p>Pour le reste, c'était malheureusement trop <em>mathématiques</em> pour moi. Si vous trouvez difficile de lire des équations mathématiques, vous serez perdu dans ce chapitre. Ça été le cas en ce qui me concerne et je ne peut pas vraiment dire si ce qui est présenté dans le reste du chapitre est intéressant ou classique. En fait, je pense que vous pourriez vous en tirer si vous êtes un temps soit peu habitué au solver de fluides/liquides.</p>
<h3>Chapitre 6: Bullet Physics: Simulation avec OpenCL (par Erwin Coumans).</h3>
<p><img src="https://www.fevrierdorian.com/blog/public/logos/.Bullet_Physics_Logo.svg_s.png" alt="Bullet_Physics_Logo.svg.png" style="display:block; margin:0 auto;" title="Bullet_Physics_Logo.svg.png, sept. 2014" height="90" width="240" /></p>
<p>Un chapitre bien sympa auquel je ne m'attendais pas vraiment. :bravo:</p>
<p>Je ne suis pas spécialement intéressé par la physique (au sens mécanique) mais je dois admettre qu'Erwin a fait un gros travail pour décortiquer et présenter sa librairie. C'est un des deux chapitre à aborder <a href="http://en.wikipedia.org/wiki/OpenCL" hreflang="en">OpenCL</a> et le calcul GPU (le second étant le chapitre sur OpenSubdiv) mais c'est surement celui qui le fait le mieux. Bien que l'aperçu soit assez rapide, il décrit très bien les différentes étapes de créations des batchs de calcul pour le GPU et revient dessus à chacune des (très) nombreuses étape de détection de collision/calcul de répulsion. C'est d’ailleurs un très bon aperçu de comment fonctionne un moteur physique ce qui est quelque chose de très intéressant à savoir quand bon bosse en VFX.</p>
<p>Il y a aussi beaucoup de petits schémas qui sont tous très clair, chacun ne se focalisant que sur un seul problème. J'ai tendance à préférer cette approche plutôt que peu de gros schémas qui essaient d’expliquer milles choses.</p>
<p>Il fini sur des choses plus avancés.</p>
<p>Surement le chapitre le plus clair et plaisant à lire. :marioCours:</p>
<h3>Chapitre 7: OpenSubdiv: Interoperating GPU Compute and Drawing (par Manuel Kraemer)</h3>
<p>J'attendais ce chapitre avec impatience et je n'ai pas été décu. Très chouette, il est composé de deux parties.</p>
<p>La première partie explique succinctement comment la subdivision itérative Catmull Clark fonctionne, sont histoire, pourquoi une "subdivision universelle" était nécessaire, et comment ils ont choisi de la multithreader. Si vous n'êtes pas familier avec la structure de donnée géométrique en arc dur (dite <a href="http://www.flipcode.com/archives/The_Half-Edge_Data_Structure.shtml" hreflang="en">hard edge data structure</a>) vous allez surement être un peu paumé. Manuel donne quelques benchs timides et conclu que le design itératif de la subdivision Catmull Clark, bien que nécessaire pour le rendu non temps réelle (<em>off-line rendering</em>), ne s'adapte pas très bien au contraintes du temps réel. J'ai été assez surpris qu'il n'aborde pas du tout comment ils organisent leur données dans la mémoire pour améliorer le cache et bénéficier d'une meilleur vectorisation. Je ne suis pas un expert, mais après avoir lu les chapitres précédents, je me demande sérieusement si il n'y avait pas d'autres axes de recherche pour améliorer les performances. Je suppose que Manuel n'en parle pas car les gains n'était pas substantiels. Qui sait... Mais pour avoir suivi le développement d'OpenSubdiv de loin, j'ai l'impression qu'ils ont rapidement sauté sur le GPU. Comme si c'était quelque chose de plus important pour le studio (Presto semble s'appuyer dessus) et que le code CPU serait "suffisant". Les nouvelles versions de Renderman s'appuyant massivement sur du raytracing (et donc, une subdivision CPU), j'en viens à me demander si Renderman s'appuie réellement sur OpenSubdiv.</p>
<p>La seconde partie présente comment OpenSubdiv utilise le GPU (et OpenGL) pour permettre un rendu d'une subdivision temps réelle en utilisant les shaders de tesselation. Une fois encore, j'ai bien apprécié la présentation du fonctionnement d'un GPU, leurs différences (contraintes surtout) par rapport à un CPU et comment organiser et préparer ces batchs pour en bénéficier. Les Edges Creases (un "truc" très présent dans OpenSubdiv) semble avoir été un problème (tous comme la gestion des triangles/quads/polys le sont dans une algo de subdivision) mais je trouve qu'ils ont été assez ingénieux dans la façon de le gérer: Ils ont séparé chaque set de géométrie pour lui appliquer différents algorithmes. Dans la mesure ou la topologie ne change pas, le processus de séparation est fait une seul fois et le GPU ne fait que recalculer les position des points avec le shader de tesselation associé à son "set de topologie". Une approche intéressante et pragmatique pour appliquer différents algorithmes de subdivision à une seule géométrie (bien que ça semble pas mal compliquer le code).</p>
<p>Je dérive un peu pour étaler mon point de vu: Je me demande vraiment si il était pertinent de garder les Creases dans OpenSubdiv. Le concept s’accommode parfaitement avec le principe de <em>surface limite</em> cher aux rendu REYES. Mais:</p>
<ul>
<li>Cette approche ne semble pas particulièrement adapté au ray tracer qui nécessite une vrai géométrie à raycaster.</li>
<li>Des Creases un peu fort nécessite d'augmenter pas mal le niveau de subdivision pour avoir un rendu correct là où un simple bevel ou une double edge aurait fait la blague (mais complexifié la géométrie c'est vrai). Encore une fois, quand on cherche à diminuer la taille des géométrie pour les faire rentrer dans la mémoire, augmenter drastiquement la subdivision pour récupérer l'équivalent d'un bevel me semble un peu dommage.</li>
<li>Il semble complexifier et fragmenter pas mal de partie du code.</li>
<li>Code fragmenté? Structure de donnée fragmenté? Quel impact sur la mémoire (accès et taille)?</li>
</ul>
<p>Une des dernière alternative que je vois au coté gourmand (en géométrie) du Creases si on ne peut pas subdiviser à tout va c'est de modifier la normale au niveau de l'edge (pouah! Le temps de calcul du truc). Mais cela faisant, vous devez prendre l'information en compte au niveau du shading et ce n'est pas ce que OpenSubdiv est supposé faire (sans compter les petits soucis qu'on pourrait avoir pour "blender" les normales). Mais il faut avouer que ça marcherait pas mal!</p>
<p>Bref, je me demande si les Creases n'était pas un truc dont Pixar (et seulement Pixar) a besoin. Ça pourrait expliquer pourquoi un concept aussi "exotique" se retrouve dans OpenSubdiv.</p>
<p>Notez que <a href="http://www.fxguide.com/quicktakes/opensubdiv-3-0-coming/" hreflang="en">la prochaine version de OpenSubdiv arrive</a> et semble avoir bénéficier des contributions et feedbacks d'autres studios (Dreamworks?). On dirait qu'ils ont isolés la partie algorithme de la partie structure de donnée ce qui est clairement une bonne chose car devoir passer sa géométrie dans une structure de donnée externe pour la récupérer ensuite est vraiment contre productif. Je suis content de voir qu'OpenSubdiv semble aller dans la bonne direction. C'est d'autant plus important qu'il devient une partie intégrante de Maya. :)</p>
<h3>Conclusion</h3>
<p>Et bien... Un très bon livre! :D</p>
<p>Il y a une inconsistance entre les chapitres. Certains vont vraiment au bout des choses (LibEE, Fluids, Bullets), et d'autres ne font qu'effleurer la surface (Houdini, mais surtout Presto).</p>
<p>Donc ce livre est exactement ce qu'il prétend être: Multithreading for Visual Effects. Et il ne se focalise que là dessus, laissant certains points, qui mériteraient aussi d’être abordé, de coté. Mais les logiciels choisis son tellement intéressants (Sérieusement: Side Effect, Pixar, Dreamworks!) que ça en est frustrant!</p>
<p>Le livre est super classe (hard cover! :laClasse: ) bien que le prix me semble un chouilla élevé (hard cover? :ideenoire: ). Mais il s'agit d'un domaine de niche donc on va pas cracher dans la soupe (vous en connaissez vous des livres à lire dans votre canap' qui parle des logiciels les plus cools du monde? :sauteJoie: ). Et puis faut bien l'avouer, la plupart du temps c'est votre studio qui va l'acheter... :P</p>
<p>Est ce qu'il vaut le coup? Si vous avez à coder des softwares lié au VFX, n'hésitez pas une seconde! Vous n'y trouverez pas de ressources "clef en main" mais c'est un peu comme si vous aviez une discussion avec des gars brillants qui partage leur expériences autour de leur logiciel. Pas sur que vous puissiez trouver de tels infos ailleurs.</p>
<p>Si vous êtes un graphiste un peu technique, je ne vous recommanderais pas forcément de le prendre. Il est vraiment tourné autour du développement, vous n'y trouverez pas de trucs et astuces en multithreading pour améliorer votre travail. Cela dit, je vous encourage à le piquer à votre RnD ( :IFuckTheWorld: ) et à le feuilleter. Le début de chacun des chapitre est souvent assez clair.</p>
<p>Après avoir lu ce livre, je me dis que je pourrais bien payer pour d'autres du même genre qui passe en revu et en profondeur (un truc advanced j'entends) l'architecture des logiciels de VFX (Houdini, Presto, Maya, Nuke). Comment les données transitent, a quoi ressemble les structures de données utilisées, comment un type spécifique d'opération s’exécute, etc... Et pas juste un aperçu. Les docs des logiciels sont souvent trop timide sur le sujet.</p>
<p>Avant, j'étais incapable de lire et comprendre de tels codes. Je tentais de déduire le fonctionnement et la logique sous-jacente des logiciels que j'utilisais par dichotomie. Maintenant que je sais lire du code, autant y aller et voir directement le code des dis logiciels! :D</p>
<p>Malheureusement, je suis passé à coté de pas mal d'informations intéressantes à cause de mon incapacité à lire des équations de mathématiques. Je veux dire, je sais ce qu'est une matrice 4x4, les raisons pour lesquelles ont pourrait les utiliser, je sais ce qu'est un dot product, un produit en croix et comment je peut les utiliser pour obtenir un effet souhaité mais c'est à peut près tout... Je m’énervais contre moi même de n'être pas capable de déchiffrer les équations (qui au final ne semblaient pas super compliqué :nervous: ). Idem pour certains morceaux de code que j'ai eu du mal a comprendre :gne: . Je suis passé à coté de pas mal de choses dans le chapitre des Fluids.... :triste:</p>
<p>Ce qui est très intéressant c'est d'avoir rassemblé des cours d'une session Siggraph sur un sujet donnée et d'en faire un livre. J'adore l'idée car je passe des heures derrière un ordi et j'apprécie de pouvoir lire ce genre de chose sur du papier plutôt que mon écran de PC (lire un PDF me fatigue assez vite).</p>
<p>Je n'ai aucune idée du succès du livre mais j'ai entendu pas mal de gens intéressé donc on pourrait imaginé... Je ne sais pas... "Alembic/OpenVDB/OpenEXR under the hood and use cases" avec un maximum d'explications sur les fondations et l'infrastructure, jusqu'aux points clefs du code. :smileFou:</p>
<p>J'espère que vous avez apprécié cette humble review! N'hésitez pas à commentez si vous avez vous aussi lu ce livre. Je serais curieux de savoir ce que vous en pensez. :sourit:</p>
<p>Dorian</p>
<center>:marioCours:</center>