DR: Subdivide Final Buckets

[Lehm_2001]

Was thinking about the whole issue of a few buckets holding up a render. Would it be possible that once all buckets have been assigned and computers start to finish. Rather than have them become idle, it will take an unfinished bucket, stop it, and sudivide it into 16 peices and then have the machines work on the smaller peices instead.

[AXONN]

This would be indeed a very very nice feature and not only for DR, for all renders.

[DanielBrew]

+1 I've often thought this would be good. Usually while I'm waiting for the last bucket to finnish on an dual quad core .

Dan

[AXONN]

waiting for the last bucket to finnish on an dual quad core .

Dan

Indeed, very frustrating

[Morbid Angel]

unfortunately this is not possible. Once a bucket gets a cpu assignment and starts rendering, there is no way to stop that and add more cpus to it. What you may do is just set your buckets to smaller size. If you have too many cpus...then having them at 32x32 or 48x48 for average size images is going to make a difference.

[duke2]

You could do it so that the final (cpu amount) of buckets get divided in 2 or 4, so if you have 4 cpu's and the bucketsize is 32x32, the last 4 buckets are divided in 16x16 or 8x8. I don't know if this would help though.

[Morbid Angel]

from my conversations with vlado, this is not an easy task. I thought of something else rather, you can assign a cpu to a number of rays, rather then buckets, and then specify the depth of the rays...the further the depth the better the rendering is...but that way. each cpu can work in a bulk of rays, probably increasing overall performance.
Not sure how practical that would be though.

[duke2]

from my conversations with vlado, this is not an easy task. I thought of something else rather, you can assign a cpu to a number of rays, rather then buckets, and then specify the depth of the rays...the further the depth the better the rendering is...but that way. each cpu can work in a bulk of rays, probably increasing overall performance.
Not sure how practical that would be though.

Sounds like people are better off just waiting for the damned bucket

[Morbid Angel]

I guess you could make it so that the last set of buckets is internally subdivided into smaller ones. But what that would mean is, if a last bucket on one thread would render for couple of minutes, if its devided between say 4 smaller buckets, and gets 4 threads, its not that better, because each bucket border has to be anti-aliased twice to ensure smooth transition. Its just the same as if you make the default bucket to be 8x8 for example, and even if you have 50 threads, they will render much longer, because of the high aa in the border areas.

[3LP]

and the time that the cpus will take to calculate these "more AA" will be longer than the fact that there will be more power allocated to the bucket initial size ?

lets say :
1 core = 1 bucket = 10 minutes
"normaly" : 10 cores = on 1 bucket = 1 minute

due to the fact that the AA hase to be calculated, say that with 10 core it's not 1 minute but 2

you will still have win some time 10min VS 2min, even with the fact that it have to calculate that AA.

maby am I wrong, and that the AA is "so" long that even with more core, the cpu power doesn't reverse the time waiting?

Stan

[Morbid Angel]

Im not a math genius by far, but the x2 aliasing along the border will not equal to 2 minutes as oppose to 1. Its something more like minutes power of 2, not sure though.
Its simple, run a small test, with smaller bucket size vs an average size.

[DP]

If the buckets are a known number, and the number of threads known, could the last buckets be divided before they are assigned?

So if there's 8 buckets left to assign, and 4 threads, the last 4 buckets are halved in before they are assigned.

[Morbid Angel]

I guess its possible. But, I can assume its a hell of a lot of code, for a small speed increase...

[Morbid Angel]

so I ran some tests. Not in vray however, because I don't have it at work. But the formula should be relatively similar between mr and vray.

I had rendered a some what complicated scene with a resolution of 64x64 and using bucket size of 64, thus only one thread had rendered it out of the 8 that I have.
Then I have subdivided the bucket size into 16 pixels, which ment 4 threads have rendered the scene. Then I have subdivided into 8 pixels, which ment that 8 threads have rendered the scene.

The times were:
for 1 thread of 64 pixels, for 64x64 (resolution) I got 24 seconds.
for 4 threads of 16 pixels, for 64x64 (resolution) I got 7 seconds.
for 8 threads of 8 pixels, for 64x64 (resolution) I got 4 seconds.

So I guess it does indeed makes sense to subdivide final buckets into say 4 or 8, it could be a user specified option.

[Morbid Angel]

and lastly I ran a test with vray in 3ds max. same setup as before single scene with 64x64 pixels on single 64 pixel thread has rendered in 30 seconds, then with 4 threads at 16 pixels in 15 seconds, and 8 threads with 8 pixels in 7 seconds.