[Bf-committers] x- and y-parts

[joe]

BTW, I have code in the DSM branch for efficiently figuring out which
faces are in which tiles (bucketing, essentially, the current method
of going over every single face/strand for every single tile is way
too slow for small tile sizes, and DSM needed small tile sizes).  It
really does help quite a bit, though I had to plug it into my tiling
disk cache to handle extreme cases (like fur) that might take a lot of
RAM.  But if we do end up with using a small tile size, I think it'd
be necessary to use something like this code.

Joe

On Fri, Jun 26, 2009 at 1:12 PM, Campbell Barton<ideasman42 at gmail.com> wrote:
> 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
> some cases.
> 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)
> http://www.graphicall.org/ftp/ideasman42/128_threads.png
> 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:
>>> Hi,
>>>
>>> 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
>>>> coherence.
>>>>
>>>
>>> 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.
>>>
>>> Brecht.
>>>
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>
>
> --
> - Campbell
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>