Using ViewCaptureToClipboard, with a Raytraced view (Cycles device set to GPU) results in a “sluggish” computer experience doing other windows tasks, even though the CPU and GPU both show averages of 50% and 40%.
The only visual update in Rhino is the “Progress: Rendering viewport…” dialog.
Do other people experience this?
I know my system specs aren’t exactly top of the line today, but why is my system sluggish when less than half the CPU, and less than half the GPU, are being utilized?
I don’t think it’s just RAM. My RAM usage is sitting at 8.8 of 16 (all physical), even with other programs running (Chrome, excel, outlook, REVIT,…etc). The sluggishness isn’t constant either, but seems to hiccup with the GPU usage spikes (one spike per second or so).
No, I’m not actively using REVIT while Rhino Raytracing, it’s just sitting in the background.
The model in RHINO is very small (a logo), so perhaps that is why RAM is not used so much in my case. Also, this is only when Raytraced is running. Otherwise Rhino seems fine.
Test 2: Closed Revit and Navisworks (idling in the background), and now the USAGE by Cycles seems to be even greater. GPU spikes from 40 - 80%, and CPU runs from 50-80% as well, and system is almost impossible to use in other programs. It’s a chore just to type this!
Why is Cycles using the CPU so much? It’s not updating the display visually, only the little “rendering” dialog. I’d expect it to be more like Cycles in Blender, heavy on the GPU but not touching the CPU much during rendering.
How are you determining the GPU usage? With something like GPU-Z or MSI Afterburner? The numbers reported in the Windows taskmanager mean nothing wrt Cycles.
When you run Raytraced on a GPU that is also used as the display adapter you will see sluggishness. Cycles will try to use as much of the GPU as possible, making it hard for other processes to use it as well. It will for instance make your GUI in general feel sluggish.
Cycles isn’t using the CPU per se, but if you are doing large renders it will take CPU to transfer from GPU to host memory - with a view capture that should generally only happen on the very last pass though. I’d have to investigate to see what is going on really.
Note that your GTX 480 has only 1.5GB of VRAM, of which not all will be used by Cycles, since your other programs will be using it is well. If your scene needs more than available VRAM Cycles will also use host memory. This is a quite costly procedure and could explain the increased usage of CPU during rendering. Also, especially on lower-end machines, scenes that have reflective materials (metal, glass) will cause GPUs to have to do a lot more work, thus feel much more sluggish.
The best performance you will get by ensuring the GTX 480 isn’t also used as the display adapter. Perhaps you could get another GTX 480 in your machine as dedicated render device?
In my case I’m with i7 4770k + GTX1060 + 16gb ram, but still when I render while watching a movie for example I get noticeable stutter of the sound from the movie. That can’t be neither the GPU nor my soundcard.
Either RAM or CPU is overloaded even though I’ve set it to use the GPU. This is weird.
I must say, I understand nothing about rendering and I use it rarely, so might as well be my scene setups. I don’t really know what I’m doing there
That doesn’t sound weird, I have 32GB and 4 1080ti’s and I can’t really do much else while GPU rendering unless I specifically exclude my display card from the render. Video playback does make use of the GPU.
@JimCarruthers, that means the software is unstable. Whether it’s the GPU that’s been put on overdrive or RAM or CPU. Rhino is sucking more than it has to. It must leave the priority to be on windows and slowing its calculations instead of the opposite.
With such a machine you should be able without a problem to run even a second instance of Rhino and work smoothly with it while rendering.
I’ll give you example with CATIAv6 (3DEXPERIENCE) it is a huge software and even when you overload it you can do anything on that PC. You can record a video with camtasia while 3DEXP is rendering and the result will be as if nothing was running in background. If 3DEXPERIENCE stops responding you can launch any application on Windows and be able to stop 3DEXP process.
When Rhino gets overloaded you can’t move the mouse to start TaskManager, let alone click on the process in TaskManager to kill Rhino.
When I created the aforementioned thread, I was simply loading a huge model in Rhino, not even rendering but it got to a point where I could not move the mouse. I had to hard reset the machine. That’s why I asked for a different way of launching Rhino so I can quickly kill it without a problem.
Wasn’t there way to limit number of cores used for rendering in raytraced?
…or was that just for default rhino render…
wait… that was CPU core for rhino render… pls ignore.
Also optimizing tile size for ray trace may speed up renderings.
The problem is not with the affinity, it’s the priority of the process, it appears as if behind the scenes it’s set to Above Avarage or Highest in order for it to affect so much Windows performance.
Nathan, it looks like you’ve done your part to tell Windows to not hog the CPU or GPU. Thank you so much for bringing Cycles into Rhino!
On my machine, yes, I only have one card and it is being used as the display card for Windows. I was watching the GPU usage via the Windows task manager, but I’ll give one of the other programs you listed a shot.
For the fun of it I grabbed the latest copy of Blender, imported the file, set the camera to about the same place, fixed the materials so they were pretty close, set the final image size, switched the renderer to use GPU Compute (and device to CUDA), set total passes and hit render. Results are amazing! My Windows GUI does not feel sluggish, even with the roughly same 34% CPU usage.
When using Blender to render, the WINDOWS TASK MANAGER shows that only COMPUTE_0 is being used 100%, while the other graphs for the GPU seem to be fairly low usage (except of course the memory)
But during RHINO renders (viewcapturetoclipboard with cycles raytraced), the GPU is using both the 3D and COMPUTE_0. See attachments.
Why is there such a difference with how the GPU is used by Cycles, in Rhino vs Blender? And, will we see a significant change in how Cycles performs once we get a dedicated Cycles Render? (in other words, is the slowdown due to the fact that cycles is interacting with a 3D window in Rhino?)
If the problem lies with the same GPU being the primary display adapter, why does Blender Cycles not seem to care about that? I’m not upset, just curious. I know you’ve put a ton of work into integrating cycles into Rhino and really appreciate it.
My educated guess is that Blender GUI is also being fully drawn in OpenGL. Since each Cycles update triggers a (full) GUI redraw that probably shows up as much higher utilization.
With GPU-Z/MSI Afterburner you should see numbers much more expected from a render session.
I’m not sure why there is a difference. But I’ll be investigating more.
Can you share the .blend file you used for testing?
@nates, btw, if you have a 3dm file you can share with me for testing, please do so at rhino3d.com/upload with nathan@mcneel.com - user files are always great for burn testing (:
oddly enough, when all I do is ‘Raytraced’ mode (without viewcapturetoclipboard), the performance is more predictable (closer to 100% of COMPUTE_0), and the computer is a little more usable.
The strange behavior is more with ViewCaptureToClipboard (or …ToFile), this is where the stuttering GUI sluggishness is felt.
I’m trying to use ViewCaptureToClipboard (or …ToFile) as a render output. If there’s another way to get raytraced output at a larger resolution (higher pixel count than the regular viewport allows), I’m all for it!
Yes, I’m attempting to use Raytraced mode as a final render.
@ivelin.peychev, I agree that there is a process priority issue that’s blocking normal Windows program management, IE the ability to use the task manager when memory leaks or other runaway things happen with Rhino, but I don’t think it’s within the “Raytraced” (Cycles) rendering portion.
I think it’s deeper within Rhino, perhaps in how it handles the display pipeline (wild guess), and perhaps the deeper issue is also being triggered by Cycles? Dunno, We’ll see what they find.
If you want to do a Raytraced viewcapture of one that is currently running you should pause the viewport before doing the actual capture. What happens with different resolutions is that a second session is started - that includes reading the entire scene into VRAM again. I know, it is suboptimal, but it is how it currently works. Having two sessions at the same time running (the viewport, and the viewcapture) is like punishing your GPU. And then most likely your VRAM gets maxed out with the second scene, so you most likely see very bad performance due to combo of VRAM and CPU RAM being used instead of just all in VRAM.
To churn out Raytraced renders I’d suggest you use _TestPackageManager and install the rhino-render-next package, which is for rendering with the Cycles engine of Raytraced, but as a production render. So you don’t have to have a Raytraced viewport active, meaning more GPU VRAM and GPU compute cycles for the final render.
Who knows. There are some GUI glitches that happen when Cycles is active in a viewport, but they have been very hard to investigate. Some of the event handling code makes it quite hard to even put a finger on.
But that’s always something that gets investigated every now and then in case we figure out something new. Until now no solution found though
Wait, you guys developed an internal package manager for plugins? Yikes, That’s what I get for skipping the release notes! Kudos to whoever put it together.
Thanks for explaining what happens when one does a view capture, that completely makes sense, and I will play with the “Rhino Render Next”.
There might be a little bug in the properties | Current Render selection dropdown. I couldn’t change it to “Rhino Render Next”, but WAS able to do so using the regular RHINO Render menu.
Using the “Rhino Render Next” now, and things look a little better! The Compute_0 graph is smoother, only dipping down over 5 seconds or so otherwise maintaining about 80%. But the “3D” graph still shows a mirror image of the usage (unlike Blender), the CPU runs about 70%, and system still feels a little sluggish, although not as bad as before.
Thanks for help @nathanletwory ! I’ll plug along with “Rhino Render Next” (very catchy name there! Heh), and hope to see gradual improvements as the cycles integration continues.
