Easily Switching Between GPU and CPU

Hello!

I have purchased a new computer specifically for my Rhino/Grasshopper use. I have noticed that when doing complex or large definitions in grasshopper the computer really has to be swtiched to my CPU for things to resolve quickly.

However, when I am raytracing I need to switch to my GPU.

I wanted making a button in rhino so I could just press it and switch to CPU or GPU when I wanted, but Cycles are not supported in button making.

Is there any way to make it so my CPU is used for everything except ray tracing?

Thank you!

What do you mean by “switched to your CPU?” Switch what?

1 Like

Basically I would like my CPU to do all the heavy lifting so it can handle the math quicker.
It’s a Ryzen 7 3700x with 32gigs of ram and my GPU is an RTX 2600 Super 8g. The GPU does a great job rendering, but does not do things like a 3d grid of spheres very quickly.

Hmmm…I’m still not clear what that setting has to do with what you’re talking about, that’s only for the Cycles raytracing mode. All the other display modes are through OpenGL with your video card, everything else Rhino does is CPU-only unless you do some CUDA programming yourself.

1 Like

Well, for example, it froze the program for about 2 seconds to just draw this: 1000 spheres

Okay…that has nothing to do with that setting? Are you trying to run these things with cycles on? It has to copy display data over to the GPU, that can I suppose take time, and in the meantime it just shows the OpenGl mode as I recall.

1 Like

Hmm, I do have cycles on. I’ll turn it off any report back!

Negative. I did not have cycles on for this display setting.

I just don’t understand why with this computer it isn’t snappy and instant changing the properties in Crossreference is causing 5-10 seconds of freezing of the program while it does the math.
This is supposed to be my fancy CAD machine!!

1 Like

Well, compared to what? Adding a thousand objects to the model is not simply a matter of drawing some curves, THAT you can do pretty instantly, but the actual Rhino model is a database, there’s a lot of extra baggage and housekeeping that goes along with each object that is added to it. One polysurface with a thousand surfaces will be snappier than doing something to a thousand simple spheres.

1 Like

Ok.

Maybe I am expecting too much?
Thank you for all your input.

Maybe? Your example is kind of trivial, not really representative of anything. Using Grasshopper is also another layer.

But yeah this is what a lot of people don’t understand when they wonder why Rhino doesn’t seem to be as fast as some game engine. Aside from the fact they have more people working on optimizing single parts of their graphics than the entire Rhino development team a game is a STATIC thing, nothing happens that hasn’t been accounted for already. “Content creation” is a different thing, and shoving polygons to the video card is a small part of what happens when you create or edit anything. If you just make an array of 1000 balls, you can see how quick it can preview that, but that’s because it’s not saving undo states or setting up the data structures for materials or whatever other hundred things it has to do when you’re actually working with the model itself.

2 Likes

I understand! Thank you for the explanation. I guess I had just thought a computer like this was invincible. At least it raytraces in nearly real time. It’s also unlikely I will be drawing designs that require 1000 elements at once. I just noticed while going through some of the tutorials that it slowed down a lot while trying to reproduce the algorithms that are being taught in the examples.

Well the lesson of that example would be that every object has an amount of “baggage” with it, no matter how small, so 1000 spheres–and they aren’t blocks, every one is totally duplicated-- has more overhead than one object with 1000 surfaces in it.

1 Like

FYI, best to not push your data through a panel to other components - instead directly connect the series to your crossref. Pushing the data through the Panel component causes unnecessary data conversions that slow down your work. Only connect series to the panel when you really want to see what it generates. Disconnect it otherwise.

3 Likes

Also remember difference on double precision and float precision numbers/coordinates.

Games almost always use float that is fast and imprecise, whereas we appreciate that you can have 100km scenes and still millimeter precision!!

I agree that sometimes gh is slow to add to the rhino preview. If speed is an issue, then create mesh spheres instead, and do a join mesh before you preview. This will speedup a lot.

this is not correct. Double values, although consuming more memory, can be faster regarding simple arithmetics. Prozessors nowadays are optimised for double values. The reason why floats in render and game engine are used is due to the fact, that RAM and memory on graphic cards is (or used to be) limited.
Precission is not a big deal until you do a lot of numerical computation, such as computing Nurbs Intersections etc. Its about the rounding error, but for simple pick and placing objects, floating precission is totally ok. Millimeter precission on 100 km doesn’t make any sense if you ask me, and I don’t think this was intented when McNeel advertises that they are using double precission :slight_smile:

Hi Tom,
My bad. You’re right that most processors are optimized for doubles! Float being faster is an outdated perception…