There’s a chance that if you don’t pester it for a minute or so, so that it can do its thing. It may render, though doing something like rotating the display often may or may not be fraught with laggyness, depending on things.
Keeping the mesh sizes/resolution small may help.
Keeping the textures small may help.
Keeping the passes/cycles/rays or whathaveyou set low may help.
Lowering the antialiasing may help set up the scene.
Also, Anisotropic filtering is costly, so, unless you are shooting vanishing-point perspective shots with fancy textures, you can make sure it’s low, like 2x.
I’ve found that the Cycles’s interactivity becomes poor with large scenes. AFAIK, At some point, with Cycles GPU rendering, things are sent in batches to the GPU. If the batches are small, the interactivity is good but the render-time is long. If the batches are large then the interactivity becomes poor.
There is an adjustment for this in Cycles, but I wish it adjusted more.
Though, IMHO, you can indeed save some pretty big renders to a file, though the interactivity requires patience, or Rhino will lock, and will often white-out just before you are one extra event from locking it.
Lastly, the MaxQ versions of nVidia GPU’s–even the ones I am looking at in Thinkpads–can only use a lower DTP than a desktop computer version. Your GPU likely takes less than 90 watts, whereas a desktop version of a 1070 likely takes 150 watts.
Some things that cannot preview on GPU can for some reason render on CPU, though it’s slow.
That stated, Cycles can do some nice renders. For some of these, I positioned and changed things, and then switched to rendered to check, and then did the final capture to file thing.
The biggest thing, so far I did was:
More here: