|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> In most modern OS's you can set process priorities on a
> per-process basis.
Yep. Except it's inconvenient in Windows because (a) it has a UI that runs
in the same process as the render and (b) one doesn't normally launch it
from the command line where setting the priority is trivial.
It would seem straightforward to continue to support render priority threads
(and UI priority threads as well) in the Windows version, given that it
already had separate render threads and UI threads, yes?
--
Darren New, San Diego CA, USA (PST)
Ada - the programming language trying to avoid
you literally shooting yourself in the foot.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> schreef in bericht
news:4be705db@news.povray.org...
> Btw, I'm curious to know why you wouldn't want POV-Ray taking all the
> available CPU.
In general, I want POV to take all available cpu. It is only when I want to
do other things alongside a render that I experience a severe
slowdown/stalling of those other processes. I do not care too much but
sometimes that is annoying.
>
> The only thing I can think of is if you are suffering from overheating
> problems and you want the CPU to be eg. at 50% at maximum in order for it
> to not to overheat.
Overheating can sometimes be an issue, especially during summer, but can
this not be resolved by the Duty Cycle?
>
> (If what you want is that other tasks get more CPU than POV-Ray, rather
> than the OS distributing the CPU evenly, that's the OS's problem, not
> POV-Ray's. In most modern OS's you can set process priorities on a
> per-process basis.)
Well, I suppose so, but Render Priority worked well with 3.6 and lower and I
wondered if something equivalent was possible with 3.7 (and multicores of
course).
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jaime Vives Piqueres" <jai### [at] ignoranciaorg> schreef in bericht
news:4be70e78$1@news.povray.org...
> On 05/09/2010 08:55 PM, Warp wrote:
>> In Unix-type systems you simple start povray with 'nice' (or renice it
>> afterwards with 'renice' or with 'top').
>>
>
> I never needed to renice povray... when my CPU it's at 100% tracing a
> scene, I barely notice it on my regular work. In fact, I sometimes forget
> that there is a scene rendering into another desktop (usually I remember
> about it when I just clicked on the "shutdown" button... :).
>
I agree with you, as long as this is 3.6 or megapov and with Render Priority
set to normal or low. However, with 3.7 my experience is that all other
applications are severely hampered during render, whatever the Render
Priority setting. Using WinXP on a dual core by the way.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 09.05.2010 20:55, schrieb Warp:
> Darren New<dne### [at] sanrrcom> wrote:
>> Having the render
>> automatically drop into the background when more urgent work(*) starts
>> running is a useful setting.
>
> That's a task for the operating system to do, not the program. All
> modern multitasking operating systems have process priorities (although
> I don't remember if you can actually fine-tune it manually in Windows).
While you're right in theory, practice mandates otherwise. MS Windows
(at least XP with default configuration) is still rather poor at dealing
with process priorities; setting POV-Ray's process priority low may
reduce the total time spent on rendering, but it doesn't seem to improve
system responsiveness much. I guess Windows uses comparatively long time
slices, and refuses to cut them short when a higher-priority process
becomes ready.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Yep. Except it's inconvenient in Windows because (a) it has a UI that runs
> in the same process as the render and (b) one doesn't normally launch it
> from the command line where setting the priority is trivial.
Why should it be inconvenient? The only thing Windows needs is that in
the Task Manager you could set the priority of running tasks. It would be
a question of a few mouse clicks (eg. if there would be a spinbutton or a
dropdown menu alongside each task in the list).
Eg. in KDE (and I'm sure that also in Gnome and basically any other
Windowing system for Unix/Linux) you don't have to go to the command line
to renice a running process. You can run the KDE System Guard (which is
largely equivalent to Windows' Task Manager) and you can renice processes
there with a few mouse clicks.
I don't know if any Windows version supports this, but if they don't,
it's not because it would be hard to implement (at least interface-wise).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tDOTdegroot@interdotnlanotherdotnet> wrote:
> "Warp" <war### [at] tagpovrayorg> schreef in bericht
> news:4be705db@news.povray.org...
> > Btw, I'm curious to know why you wouldn't want POV-Ray taking all the
> > available CPU.
> In general, I want POV to take all available cpu. It is only when I want to
> do other things alongside a render that I experience a severe
> slowdown/stalling of those other processes. I do not care too much but
> sometimes that is annoying.
Usually it's the responsibility of the operating system to offer the user
the means to set process priorities. It doesn't make much sense for each
individual program to have to do that.
Now, I don't know if Windows offers the means for a user to raise or lower
process priorities, but I would be quite surprised if it didn't. (I have only
used XP and not the newer ones, but I must admit I don't remember now if there
was a way to do this in XP. I would guess there is a way to do this in Vista
and Windows7.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> While you're right in theory, practice mandates otherwise. MS Windows
> (at least XP with default configuration) is still rather poor at dealing
> with process priorities; setting POV-Ray's process priority low may
> reduce the total time spent on rendering, but it doesn't seem to improve
> system responsiveness much. I guess Windows uses comparatively long time
> slices, and refuses to cut them short when a higher-priority process
> becomes ready.
If that's so, then why would it help of POV-Ray attempted to set this
priority itself?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 10 May 2010 13:20:04 +0200, Warp <war### [at] tagpovrayorg> wrote:
>
> Usually it's the responsibility of the operating system to offer the
> user the means to set process priorities. It doesn't make much sense
> for each individual program to have to do that.
It does make sense if you want different parts of the program to have
different priorities. In the case of POV-Ray, you would want the main UI
thread to remain at normal priority even with the render threads running
at low priority.
--
FE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 10.05.2010 13:20, schrieb Warp:
> Usually it's the responsibility of the operating system to offer the user
> the means to set process priorities. It doesn't make much sense for each
> individual program to have to do that.
It does if you frequently want part of a program to run at low priority,
because it saves you quite some mouse clicks or keystrokes each time you
fire up those tasks.
Another issue in this context is that POV-Ray for windows doesn't start
a separate process (aka task) for the back-end, just separate threads,
which might be difficult to identify in a task manager even if it
supported per-thread renicing. Though I don't know whether Windows
supports assigning scheduler priorities on a per-thread basis at all.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 10 May 2010 13:54:22 +0200, clipka <ano### [at] anonymousorg> wrote:
> Though I don't know whether Windows supports assigning scheduler
> priorities on a per-thread basis at all.
It does, but as you said, there is no UI for changing per-thread
priorities.
--
FE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |