[Bf-committers] x- and y-parts
ideasman42 at gmail.com
Fri Jun 26 21:12:35 CEST 2009
a few points....
* I'd not have blender render the next from once its run out of tiles
on the first one, the extra ram used could give bad results/crash in
If you know you have enough memory just run 2 blenders up rendering at
the same time.
* a while ago I had blender to render 128 threads at once just to see
how well it worked. I was surprised to find overall render time of the
test scene was about the same as 2 threads (on a 2 core system)
Even though 128 threads is probably a lot worse with some scenes it
does make me think that Brecht's suggestion of rendering many more
smaller tiles would be good.
* One thing I like about blender is that bugs reported on the users
system can often be re-produced by others, if tricky settings like
this are added I think its worth keeping some way to run predictably.
* re Wahooney: sorting tiles by faces, then rendering most -> least
would be useful (its predictable too!)
On Fri, Jun 26, 2009 at 5:09 AM, Wahooney<wahooney at wahooney.net> wrote:
> I'm going to pipe in here now :)
> I think that it's Brazil R/S that defines a tile size for each "bucket"
> that gets rendered and the order of the bucket is based on the mesh
> density of the scene, ie. the scene is discreetly sliced into the
> buckets that will be rendered and then sorted by the number of faces
> then rendered most -> least faces, which is pretty handy in many cases,
> especially test rendering.
> Another cool feature in Brazil R/S's bucket rendering is that the
> current bucket is outlined, so you can see where it's rendering, useful
> when rendering scenes with largely black backgrounds.
> - Keith
> Brecht Van Lommel wrote:
>> On Fri, 2009-06-26 at 07:53 -0400, Yves Poissant wrote:
>>> From: "Jeroen Bakker" <j.bakker at atmind.nl>
>>>> Or do I mis something?
>>> Memory access coherence. It is probably not relevent to the discussion
>>> because Blender rendering architecture is not designed to maximize memory
>>> access coherence and even though the render seems to be processed as tiles,
>>> every pixels needs to be completely shaded before shading the next. But for
>>> the sake of covering all angles, when rendering in tiles, small tiles, it is
>>> possible to design the rendering architecture to maximize memory access
>> The original parts were there for Panorama render, it gets more accurate
>> as you use more X-parts, only later that got extended to threads.
>> Next to memory coherence, memory usage is also lower with smaller tiles
>> (render passes, a-buffer, caches, ..). The ideal tile size is a bit
>> difficult to determine, but what would be an improvement is to define it
>> in pixels. Note also that threads == number of tiles is suboptimal for
>> load balancing, not all threads will finish at the same time due to
>> varying difficulty of certain parts of the scene to render, smaller
>> tiles help here.
>> I think generally something like 32x32 tile size + automatically even
>> smaller ones for large number of threads compared to image size, would
>> probably work well.
>> Bf-committers mailing list
>> Bf-committers at blender.org
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers