[Bf-cycles] Cycles GPU capping?

Wed Feb 27 20:11:44 CET 2013

I should quickly just chip in two quick points from practical experience that can save people some headache with this:
- the reason you lose displays when changing up GPUs is a mechanism in many BIOSes that simply assumes that when you add a GPU (or more), you will want to start using that GPU as your main for your display. It thus disables built-in GPU and transfers output to (one of) your NVIDIA cards. It will do this every time you make a change in most cases (Windows ignores this, but you'll have a blank screen until it loads). This is by design and not an "error"
- SLI performance is terrible (and should be avoided). If you want to see some fun graphs on exactly *how* terrible, take a look at this: http://www.systemagnostic.com/faqs/my-gtx-590gtx-690-or-sli-setup-isnt-performing-whats-going-on/


OJ 

--
Ole Jakob Skjelten
olesk at pvv.org
+41 79 832 2976


On 25. feb. 2013, at 16:45, Impossible 3D <impossible3d.media at gmail.com> wrote:

> 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 
> available.
> 
> 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 
> detection)...
> 
> 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
> http://www.impossible3d.com
> 
> 
> 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 !!!
> ----------------------------------------------------------------------------------------------
> 
> Hi,
> 
> 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.
> 
> 
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20130227/cabb2d91/attachment.htm