While benchmarking E-Cycles I found some renderings to be extremely slow and I did some tests as I though it might be related to E-Cycles, but it seems to be a general issue with 2.8x. It seems that Hilbert Spiral is ridiculously slow. The scene is pretty large (7000px x 7000px) has a decent amount of geometry and textures in it.
System information: Windows 10, GTX 980 Ti, 32GB RAM, Bucket size 250px x 250px.
Here are some benchmarks …
2.82EC - Right to left … 43 min.
2.82EC - Hilbert Spiral … Canceled after an hour (less than 50% rendered)
2.79EC - Right to left … 46 min.
2.79EC - Hilbert Spiral … 1 h 2 min.
2.82 Nightly - Right to left … 1 h 8 min.
2.82 Nightly - Hilbert Spiral … Canceled after 1 h 8 min. (less than 50% rendered)
The most obvious thing is that GPU memory steadily increases with Hilbert. At the point of canceling it was almost 6GB. With R2L the memory did not exceed 4GB.
I’d be interested to learn what that could be.
I did some more tests and the issue seems to be Denoiser related. When the Denoiser is deactivated, the render times of Hilbert Spiral and Right to Left are the same.
Maybe report this as a bug
I always try to get more information about a problem before I file a bug report, as it also could be a user error or something that is already know. But as the threads don’t seem to get too much attention from developers, it might be best to file the bugs right away.
My theory would be that Cycles is running out of VRAM and starts offloading data into system memory, which is slower to access.
The temporary data needed for denoising can be a lot, and Cycles is unable to denoise a tile until all of its neighbors have been rendered. The “open border” of a hilbert spiral render is larger than that of a line-by-line render along the shorter edge, that’s why hilbert spiral takes more memory when denoising is enabled.
Thanks for the answer.
As I mentioned, VRAM steadily increased with “Hilbert Spiral” and your explanation makes sense considering that with such a big rendering a lot of data must be buffered until the denoiser can act. But knowing this it seems as if the Hilbert Spiral approach could be adapted to take care of this. Maybe something like a smaller spiral inside the overall spiral movement. I like that the spiral starts in the center where usually the most important content is located. The “Center” bucket order might suffer from the same problem then I guess.
The question now is, where to put this suggestion so that somebody in charge sees it? In the past I didn’t have any luck here.