[Bf-cycles] Question about NVIDIA GPU resources capping when rendering

Impossible 3D impossible3d.media at gmail.com
Sat Feb 23 02:09:43 CET 2013

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 !!!

Many thanks,

On 13-02-21 10:50 PM, Impossible 3D wrote:
> Thank you Brecht for a fast answer and a detailed explanation. It is 
> very much appreciated. I see the problem.
> What I've noticed though is with a smaller tile size render times grow 
> really fast (almost double sometimes, although it's on a 
> frame-by-frame basis) although the UI does seem a bit more responsive 
> as you say.
> Would it be safe to say that to work around this issue, what we would 
> need is:
> 1 - a dedicated card (in this case the GTX560) for cycles.
> 2 - an OS/2d rendering card (I've got a 8800GT also which could be used)
> Booting Ubuntu with the 8800GT as primary (dvi), and not connecting 
> anything to the GTX 560. (am I right here?)
> But I wonder... is Blender gonna be able to distinguish between the 
> two cards? Is there gonna be an option to use the GTX560 (only) to 
> render ?
> Or is it going to get mixed up/uncontrolled results, particularly with 
> the Nvidia driver ?
> Or maybe there is a way to force it to use the proper card in Blender 
> (or Ubuntu, or both)...?
> Regards,
> Martin
> On 13-02-20 08:08 AM, Brecht Van Lommel wrote:
>> 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.
>> Brecht.
>> _______________________________________________
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-cycles

More information about the Bf-cycles mailing list