hi @nathanletwory,
I didn’t had to do any renderings for quite some time. Now it’s time for that again. So I prepared a scene and wanted the pc to do a few renderings while I’m gone - which is a pretty common use case, I think.
With Rhino6 my only option to do so is to use a script or macro combined with “ViewCaptureToFile”, right? Now the problem is something I had observed way back in the WIP phase already. When using “ViewCaptureToFile” cycles doesn’t utilize the GPU (GTX1060) fully. Utilization jumps between 0 and 100% in varying frequencies depending on tile size and resolution. If I just use the viewport and set it to Raytraced - then the GPU is fully utilized, always close to 100%. Same resolution, tile size and samples of course.
I compared and the result is that when using “ViewCaptureToFile” the render time is much longer. In some cases render time is worse than double, again depending on the tile size and resolution.
The only tool that I’m aware of, which is able to correctly monitore the GPU utilization, frequencies, etc is MSI afterburner. Stuff like the new GPU monitore in the Windows10 taskmanager is useless. If you switch to the right graph (compute_0 in my case) you’ll see a curve that isn’t updated in a high enough frequency so it only shows a misleading, averaged curve. Everyone should be made aware that the Win10 taskmanager is basically useless in this case.
Now back to my actual problem:
How can I use batch rendering (or just ViewCaptureToFile) without being slowed down by this GPU-utilization bug?
That is quite a disappointing answer to me. The Rhino Homepage specifically mentions “fast rendering” and the utilization of modern GPUs. So new rendering capabilities are advertised strongly. Being limited to just making screencaptures of the raytraced viewport can’t be called a complete renderer imo.
To me the whole cycles integration in general feels more like a scam than an actually usable product. Not just because of the issue above but there is so much missing, incomplete and wrong about it, I don’t even know where to start. No offense @nathanletwory, certainly not your fault, since I don’t think ONE SINGLE DEVELOPER will ever be able to accomplish this task in the given time, no matter how skilled he is.
The way I see it is that the McNeel Group (whoever that is) realized it’s important to have a decent integrated renderer they could advertise. So they just used cycles which is completely free for them and hired one developer. This can’t be called an honest effort to deliver a decent render-integration. This is just the bare minimum to get the right to use cycles. The good reputation of cycles and blender is being abused here imo. This is basically a scam (nowadays you call that smart, I think).
Hmm wait, you were talking about viewcaptures, not rendering.
If you see alternating between 0 and 100% you possibly are seeing memory swapping between host and gpu memory. Check that your GPU memory isn’t maxed out (or close to) when starting a viewcapture.
With the test scenes locally I don’t see this flipfop in performance - they fit all at least twice in GPU memory.
I admire your tireless effort regarding cycles integration and your presence here in the forum.
Framebuffer? The two examples show the framebuffer “Speicher Auslastung” at roughly 50%. I have the 6GB version and the scene is not that complex. The file size is 78MB. Just to make sure it is not the framebuffer, I just tried a lower resolution (960x640@320TileSize) and didn’t use any textures this time. Still the same behavior when using ViewCaptureToFile. So no swapping I think. Btw this is also no throttling issue related to GPU temperatures, my temps max at around 70 degree celsius, which nowhere near throttling. Would be happy to find out this is just related to my setup and a workaround would be possible.
Btw, why I don’t just let rhino+cycles work in the background while I’m at the PC is because after some time the toolbars from rhino are in the foreground and there is no way to get them out of the way unless I cancel the rendering. Another one of those many annoying things. This basically forces me to do renderings when I don’t have to use the PC at the same time.
Well, I don’t see this throttling. I use ViewCapture a lot in my regression test suite with over 1000 render tests. I would have noticed if it suddenly took twice to complete…
No, I initially thought you meant rendering to the Render Window - that is something that for some reason has pingpong between 0 and 100. It is not a Cycles problem, but rather something with the data backend used to write pixel data to for showing. It is separate from ViewCapture*, since those don’t write anything to Rhino buffers until the very end.
OK, I get that, ViewCapture is different than rendering to the Render Window. I tried again with a new file containing just one simple geometry, still the same behavior - so it is not the lack of VRAM. Win10 is up to date, Rhino and drivers as well. Just telling me that you don’t have this problem is not supportive in any way. The problem exists and I hope it is fixable.
I’m not telling you which tools to use, I have GPU-Z as well. It is OK for basic monitoring but there is no chance these tiny graphs will make this kind of behavior recognizable. Only after you set the sensor refresh rate to 0.1 sec you get some idea about the jumps but still they are represented incorrect, in an averaged pattern due to the graph being so tiny. So there is a good chance you have this bug as well but just can’t tell based on the monitoring tool you use.
I can’t do much if I am unable to reproduce the problem. Probably I need more information - perhaps you can attach the settings XML file for Cycles: %APPDATA%\McNeel\Rhinoceros\6.0\Plug-Ins drill into the RhinoCycles plug-in folder, then into its settings folder.
Leave it for now. since rendering is done via macro mostly at night while I’m gone, the time isn’t that big of a concern. Of course I want to get the max performance from my hardware but it’s not a high priority bug at the moment.
Will make a complete reinstall of the whole system after my current project - that’s always a good thing to do from time to time.
