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.