[Bf-committers] x- and y-parts
wahooney at wahooney.net
Fri Jun 26 14:09:41 CEST 2009
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.
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
More information about the Bf-committers