<div dir="ltr"><div><div><div><div><div>Hey all,<br><br></div>First off, I'd like to say that I'm trilled to be part of the Cycles artist module. I'm honored to have been chosen.<br><br></div>I've been pretty slammed this week, but I've been letting some ideas roll around in my head for ways I'd like to contribute in the long run. In the coming week I have a bit of downtime and I plan on working up some mockups that I think would be beneficial to Cycles development.<br>
<br>For now the one idea I wanted to throw out is a method for alleviating the dreaded "final bucket" syndrome. Anyone who has rendered a very complicated scene on a tight deadline will know what I'm talking about. For those unfamiliar, when rendering with buckets it is common for the render to reach its final bucket and hit a bit of a standstill as all other processing threads finish their jobs and remain idle. This means that for that final bucket on a modern processor, you're only utilizing ~12.5% of your processor. Over the course of an animation this time can add up to a substantial amount of wasted CPU time.<br>
<br></div>My proposal is a method that detects the final tile and separates it into tiles of its own equal to the user-defined maximum threads. This will allow for maximum CPU usage throughout the entire render process. In the coming week I hope to familiarize myself with the code base of Cycles itself (it's been a long time coming, honestly) to be able to give more well-informed explanations for things like this (and possibly even some of my own code contributions), but as it stands now I'm not sure how easy/difficult it would be to implement a system like this given the current design philosophy of Cycles as a whole.<br>
<br></div>Brecht, is this feasible? After coming to grips with the code base (I may poke you on IRC a few times if I run into GPU-related code I'm unfamiliar with) this may even be something I could take a stab at myself. I'd love to hear your input.<br>
<br></div>Thanks,<br><br>Matt Heimlich<br></div>