[Bf-cycles] Cycles GPU capping?

Impossible 3D impossible3d.media at gmail.com
Mon Feb 25 16:45:53 CET 2013

Oh Hi Andrew!

Kinda weird that you didn't see the whole post (I suspect gmail as the 
culprit but let me know if you get another truncated reply!). Well, let 
me add a bit more information for anyone interested in how this "lag" 
was solved but also the new surprising feature(s) that will become 

So, as Brecht said at the end of his post, what did the trick (until 
real GPU resource control can be added, of course) is adding a second 
GFX board on the motherboard, so 2nd nvidia GPU (I've tried an identical 
model AND a different, slightly older one, and they both react 
differently but still very good), and NOT even in SLI mode; they should 
still be detected properly in nvidia-settings and Ubuntu, mind you, I 
wouldn't know about AMD and/or Windows); I was actually very surprised 
on how easy it was, having had so many problems in the past with SLI 
mode, and hours of playing with the /etc/X11/Xorg.conf file with only 
mitigated results. Just put it in, the NVIDIA drivers will do the rest. 
Also, word of advice, some motherboards don't like it if you put 2 GFX 
cards (you may lose all your displays when booting), so you may have to 
switch your display cables to the other GFX card (I've found that those 
PCI express slots closest to the CPU would be primary for display 

Anyways, after booting Ubuntu, in Blender (at least in 2.66, I don't 
know how long the feature has been there), there's a nice little option 
that will appear in the User Prefs - System tab - CUDA options called 
(well, depending on your GPUs of course): "GeForce 560GTX (2X)" -- 
notice the 2X will appear IF they are identical -- so it will send jobs 
to both GPUs at the same time, effectively cutting in half the renders 
-- proof of that is that I see two render tiles at the same time instead 
of only one -- (although the lag I was mentioning originally in my post 
(desktop, mouse,etc) comes back of course, since both GPUs get occupied; 
But, the VERY -VERY- nice thing is that you can easily switch back and 
forth in the same prefs panel from two GPUs to only one GPU (or the 
other) and thus the desktop naturally comes back and, low and behold, no 
more lag (so, heavy viewport modeling, the OS display in general, and 
even "compiz" effects, all while rendering), all controllable on a click 
of a button in Blender, so you can turn it on and off without 
rebooting/changing GPU options. It's just a really REALLY great feature 
to have in our workflow.

You see, you can go from heavy modeling to heavy rendering and/or both 
at the same time depending of needs!
My only hope is that this feature never gets removed!

Best regards,
Martin Levasseur

Impossible 3D

Original reply was:

Hi there,

Problem solved!
Thank you Brecht. It worked.. it's amazingly smooth and it's possible to 
select which GPU to use for rendering in the System Preferences tab. I 
didn't know, but the feature was already there!

Amazing !!!


On Tue, Feb 19, 2013 at 9:20 PM, Impossible 3D
<impossible3d.media at gmail.com>  wrote:

> I was wondering if someone knew if resources capping was available in
> the nvidia driver and if Blender could maybe get control over it which
> would allow such a feature (I was putting forward a suggestion that a
> textbox option besides the "GPU compute" option that would allow for a
> maximum percent value to be entered and thus would allow some sort of
> control by the user, for example during the day it would render frames
> at 60-80% GPU (and hopefully, the computer would stop lagging), and at
> night or when afk for a long time, it would go back at 100% GPU). It may
> not even need this level of granularity in case it's a pain to
> implement, even a low/medium/high/unrestricted selector would be most
> welcome.

We could do better here but it's fairly complicated. The way a GPU
works is that once you send it a job, it can't do anything else until
that job is finished, it's not possible to do 80% rendering and 20%
drawing simultaneously. The problem is that if you send it too small a
job it will not work efficiently, if you send it too large of a job it
will not be able to redraw the screen until it's done.

Using smaller tile sizes will give you smaller jobs and so more
responsive UI. We could have an extra option here to also do nothing
after each job, I think this would lower the heat but not necessarily
make the UI much more responsive.

But the only way to get really smooth interaction is to use separate
GPU's for rendering and display, as most GPU render engines recommend.

More information about the Bf-cycles mailing list