 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I seem to remember that Render Priority was switched off during developement
of the betas. If so, it would be nice if this was switched on again now.
Whatever the selection (low, normal, high) the render seems to take up the
full 100% cpu.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 09.05.10 10:47, Thomas de Groot wrote:
> I seem to remember that Render Priority was switched off during developement
> of the betas. If so, it would be nice if this was switched on again now.
> Whatever the selection (low, normal, high) the render seems to take up the
> full 100% cpu.
I think this is because the render priority and multi-threaded rendering
kind of logically conflict with each other. Having multiple threads and
using only part of the CPU is, while not mutually exclusive, not really
sensible.
Maybe reducing the number of threads would be sufficient for your purposes?
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 09.05.2010 11:04, schrieb Thorsten Froehlich:
> On 09.05.10 10:47, Thomas de Groot wrote:
>> I seem to remember that Render Priority was switched off during
>> developement
>> of the betas. If so, it would be nice if this was switched on again now.
>> Whatever the selection (low, normal, high) the render seems to take up
>> the
>> full 100% cpu.
>
> I think this is because the render priority and multi-threaded rendering
> kind of logically conflict with each other. Having multiple threads and
> using only part of the CPU is, while not mutually exclusive, not really
> sensible.
>
> Maybe reducing the number of threads would be sufficient for your purposes?
Hm... what happens if someone only has a single-core CPU? (Yeah, poor
sod, but still - POV-Ray 3.7 should be able to deal with this I think.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 09.05.10 11:58, clipka wrote:
>> I think this is because the render priority and multi-threaded rendering
>> kind of logically conflict with each other. Having multiple threads and
>> using only part of the CPU is, while not mutually exclusive, not really
>> sensible.
>>
>> Maybe reducing the number of threads would be sufficient for your
>> purposes?
>
> Hm... what happens if someone only has a single-core CPU? (Yeah, poor
> sod, but still - POV-Ray 3.7 should be able to deal with this I think.)
Yes, of course, but that problem should solve itself quickly ... few of
those CPUs are able to run a recent Windows _and_ still have resources to
spare for POV-Ray :-) Of course, your point still remains a valid argument
for a few more years.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trf de> schreef in bericht
news:4be67ab8$1@news.povray.org...
> On 09.05.10 10:47, Thomas de Groot wrote:
>> I seem to remember that Render Priority was switched off during
>> developement
>> of the betas. If so, it would be nice if this was switched on again now.
>> Whatever the selection (low, normal, high) the render seems to take up
>> the
>> full 100% cpu.
>
> I think this is because the render priority and multi-threaded rendering
> kind of logically conflict with each other. Having multiple threads and
> using only part of the CPU is, while not mutually exclusive, not really
> sensible.
You confirm my musing. So this means in fact that Render Priority has become
obsolete, if I understand this correctly. Then logically, the option should
be deleted, shouldn't it?
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> Maybe reducing the number of threads would be sufficient for your purposes?
Having a render priority being set low while still using all the cores in
the event that nothing else is running is a useful combination. Reducing the
number of cores is really only equivalent if you can do this in the middle
of a trace, which I don't think is currently possible. Having the render
automatically drop into the background when more urgent work(*) starts
running is a useful setting.
(*) What, more urgent than a POV-Ray render? I know, I know, but it
occasionally happens.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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).
In Unix-type systems you simple start povray with 'nice' (or renice it
afterwards with 'renice' or with 'top').
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tDOTdegroot@interdotnlanotherdotnet> wrote:
> I seem to remember that Render Priority was switched off during developement
> of the betas. If so, it would be nice if this was switched on again now.
> Whatever the selection (low, normal, high) the render seems to take up the
> full 100% cpu.
Btw, I'm curious to know why you wouldn't want POV-Ray taking all the
available CPU.
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.
(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.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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... :).
--
Jaime Vives Piqueres
http://www.ignorancia.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:
> 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... :).
Maybe because I'm using an "old" Pentium4, if I try to watch a
H.264-encoded video while povray is rendering, mplayer may have
difficulties (especially if the video has a relatively high resolution).
I have to renice povray if I want mplayer to be able to decode it in
real-time.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> That's a task for the operating system to do, not the program.
Isn't that what "render priority" does? Changes the "niceness" of the render
thread?
Because I don't want to renice the whole process. Just the render thread's
priority.
--
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 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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).
It's there already (since XP), right click on the process in task manager
and choose "Set Priority". But as already said, this changes the priority
of the whole process. What I assume most people want is the GUI thread to
be fully responsive, and the rendering thread to be on low priority. I
don't see an easy way for the task manager to handle this (unless the
program could "expose" certain threads to the OS that are flagged with names
and then show up in task manager). It seems simpler that the program itself
handles which of its threads can have the priority changed.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> schreef in bericht
news:4be7ebe4@news.povray.org...
> 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.)
I find the discussion in this thread rather interesting because I wonder now
why there is a Render Priority *button* at all, in POV for Windows.... :-)
well, at least in 3.7, because in 3.6 and earlier I had the definite
impression that it worked just fine...
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> 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?
Because it's roughly six to eight mouse clicks, if you know what you're
doing, to do it with the GUI. I find that inconvenient when it's something
that's likely to be a persistent setting. Especially since it's already
implemented in 3.6 and probably less than a dozen lines of code to carry
over. I honestly can't imagine why one would drop such a feature. (Which may
entirely be simply my lack of imagination.)
> 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).
It's supported. It's just inconvenient. It also means the UI also runs at
low priority if the render runs at low priority, which in my experience is
also annoying.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2010-05-09 14:55, Warp a écrit :
> 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).
>
> In Unix-type systems you simple start povray with 'nice' (or renice it
> afterwards with 'renice' or with 'top').
>
In Windows, you have 6 prioritys settings that you can sellect:
Real time (don't use that one if you want to do anything), high, higher
than normal, normal, lower than normal and low.
There is also the idle priority, but you can't chose it.
Any application that have the focus will have priority over other
applications that have the same base priority.
Minimised applications have ther priority further reduced, still
relative to applications that have the same base priority.
By default, POV-Ray runs at lower that normal priority.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Thomas de Groot <tDOTdegroot@interdotnlanotherdotnet> wrote:
>> I seem to remember that Render Priority was switched off during
>> developement of the betas. If so, it would be nice if this was switched
>> on again now. Whatever the selection (low, normal, high) the render seems
>> to take up the full 100% cpu.
>
> Btw, I'm curious to know why you wouldn't want POV-Ray taking all the
> available CPU.
Because you want other processes to have priority in getting CPU timeslices.
> 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.
Changing the render priority wouldn't help with overheating. That's a
totally different setting (duty cycle, which pauses and resumes render
repeatedly).
> (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.)
POV-Ray's "Render Priority" menu used to tell Windows to change the process
priority. That's all it did.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Reducing the number of cores is really only equivalent if you can do
> this in the middle of a trace, which I don't think is currently
> possible.
Maybe I'm missing the point, but can't you just stop the render, change
the number of cores, append "+c" to the command line and continue
happily? I just tried it, and it seemed to work...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In Windows there is a possibility to set affinity.
See this tip :
http://www.addictivetips.com/windows-tips/how-to-set-processor-affinity-to-an-application-in-windows/
You can choose the processors to use per program. On a quad-cpu system, you can
for example set POVRay on processor 1,2,3 and still have an entire processor for
your other programs.
I don't know if this will be implemented in the final POVRay 3.7 but duty cycle
was also useful.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2010-05-21 14:49, Rocco a écrit :
> In Windows there is a possibility to set affinity.
>
> See this tip :
>
http://www.addictivetips.com/windows-tips/how-to-set-processor-affinity-to-an-application-in-windows/
>
> You can choose the processors to use per program. On a quad-cpu system, you can
> for example set POVRay on processor 1,2,3 and still have an entire processor for
> your other programs.
>
> I don't know if this will be implemented in the final POVRay 3.7 but duty cycle
> was also useful.
>
>
Duty cicle was implemented to protect a computer in the space shuttle.
POV-Ray's priority on a windows system is set to "lower than normal".
It's the task of the OS to attribute CPU cycles. On a quad core, using
POV-Ray should not affect any application that have the focus and that
start with "Normal" priority increased by the fact that it have the
focus. If it causes a problem, you should complain to Microsoft so that
they correct the problem.
There is also the possibility that your systen is set to prioritize
background tasks.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Alain" <aze### [at] qwertyorg> schreef in bericht
news:4bf878b3$1@news.povray.org...
>
> POV-Ray's priority on a windows system is set to "lower than normal". It's
> the task of the OS to attribute CPU cycles. On a quad core, using POV-Ray
> should not affect any application that have the focus and that start with
> "Normal" priority increased by the fact that it have the focus. If it
> causes a problem, you should complain to Microsoft so that they correct
> the problem.
>
> There is also the possibility that your systen is set to prioritize
> background tasks.
>
I confess I start to get confused now with the many - sometimes
contradictory - posts in this thread.
My experience, with POV-Ray 3.7 on a dual core XP machine, with priority set
to "lower than normal", is that both cores take up the full 100% cpu during
render, slowing down all other applications having the focus during that
time. Again, I repeat myself, I seem to remember that Priority was disabled
during beta development, but I have had no confirmation of that until now.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot wrote:
> My experience, with POV-Ray 3.7 on a dual core XP machine, with priority
> set to "lower than normal", is that both cores take up the full 100% cpu
> during render, slowing down all other applications having the focus during
> that time. Again, I repeat myself, I seem to remember that Priority was
> disabled during beta development, but I have had no confirmation of that
> until now.
Getting 100% CPU usage is expected. But you shouldn't be getting any
slowdown.
Processes with low priority get all the CPU timeslices that aren't being
used by a process with higher priority. As soon as an app in normal priority
tries to use the CPU, POV-Ray will use less of it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Nicolas Alvarez" <nic### [at] gmailcom> schreef in bericht
news:4bfda97c@news.povray.org...
> Getting 100% CPU usage is expected. But you shouldn't be getting any
> slowdown.
>
> Processes with low priority get all the CPU timeslices that aren't being
> used by a process with higher priority. As soon as an app in normal
> priority
> tries to use the CPU, POV-Ray will use less of it.
>
I understand that. My experience however is that, with the (low priority)
3.7 render active in the background, all other rapplications I start/use,
regularly /hang/ for some time (seconds to tens of seconds) before resuming
again. This is not the case with version 3.6, or at least hardly noticeable.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 28.05.2010 09:19, schrieb Thomas de Groot:
>> Processes with low priority get all the CPU timeslices that aren't being
>> used by a process with higher priority. As soon as an app in normal
>> priority
>> tries to use the CPU, POV-Ray will use less of it.
>>
>
> I understand that. My experience however is that, with the (low priority)
> 3.7 render active in the background, all other rapplications I start/use,
> regularly /hang/ for some time (seconds to tens of seconds) before resuming
Same here.
I guess the Windows scheduler gives comparatively long time slices to
processes, and doesn't cut them short even if higher-priority processes
are ready. So while in /theory/ applications shouldn't bother about
scheduling, in /practice/ it would be good if POV-Ray yielded its time
slices now and again, at least on Windows systems.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 28 May 2010 12:36:58 +0200, clipka <ano### [at] anonymousorg> wrote:
>
> I guess the Windows scheduler gives comparatively long time slices to
> processes, and doesn't cut them short even if higher-priority processes
> are ready.
That is not what they say:
http://msdn.microsoft.com/en-us/library/ms685100.aspx
"If a higher-priority thread becomes available to run, the system ceases
to execute the lower-priority thread (without allowing it to finish using
its time slice), and assigns a full time slice to the higher-priority
thread."
A quick test on my own system shows that the GUI of other applications can
get slightly sluggish during a render, but not if I disable the preview
display. Perhaps POV-Ray spends a noticeable amount of time drawing the
preview (GDI functions are notoriously slow) and Windows does not want to
preempt that (either because some parts are non-reentrant or because
drawing to the screen temporarily boosts priority; I do not know).
--
FE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 28.05.2010 13:04, schrieb Fredrik Eriksson:
> On Fri, 28 May 2010 12:36:58 +0200, clipka <ano### [at] anonymousorg> wrote:
>>
>> I guess the Windows scheduler gives comparatively long time slices to
>> processes, and doesn't cut them short even if higher-priority
>> processes are ready.
>
> That is not what they say:
>
> http://msdn.microsoft.com/en-us/library/ms685100.aspx
>
> "If a higher-priority thread becomes available to run, the system ceases
> to execute the lower-priority thread (without allowing it to finish
> using its time slice), and assigns a full time slice to the
> higher-priority thread."
Then there must be some other reason for the effects I do see. Maybe
some effects due to priority boosts?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 28 May 2010 17:31:09 +0200, clipka <ano### [at] anonymousorg> wrote:
>
> Then there must be some other reason for the effects I do see.
What effects do you see? As I said before, for me any issues seem to only
be noticeable with the preview display active, so it might be something to
do with that.
> Maybe some effects due to priority boosts?
The conditions for priority boosts are described here:
http://msdn.microsoft.com/en-us/library/ms684828.aspx
The article also explains how to prevent priority boosts from happening.
--
FE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 28.05.2010 18:16, schrieb Fredrik Eriksson:
> On Fri, 28 May 2010 17:31:09 +0200, clipka <ano### [at] anonymousorg> wrote:
>>
>> Then there must be some other reason for the effects I do see.
>
> What effects do you see? As I said before, for me any issues seem to
> only be noticeable with the preview display active, so it might be
> something to do with that.
I virtually always have the preview display active, so yes - it might
indeed be related to that. Doesn't make it any better though.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot wrote:
> I understand that. My experience however is that, with the (low priority)
> 3.7 render active in the background, all other rapplications I start/use,
> regularly /hang/ for some time (seconds to tens of seconds) before resuming
> again. This is not the case with version 3.6, or at least hardly noticeable.
did you try with 3.7 using only one thread? The difference
in behavior compared to 3.6 might simply be that 3.6 could not
really stress your dualcore CPU.
Also you might check if memory is running low if the
system starts feeling unresponsive.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 28.05.2010 19:44, schrieb clipka:
>> What effects do you see? As I said before, for me any issues seem to
>> only be noticeable with the preview display active, so it might be
>> something to do with that.
>
> I virtually always have the preview display active, so yes - it might
> indeed be related to that. Doesn't make it any better though.
Having kept an eye open, I noticed that responsivity is poor only at
certain intervals, and I also have the impression that these indeed
correlates with the finishing of SMP sub blocks.
So I think this calls for closer examination and - if possible -
elimination of this issue.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <ano### [at] anonymousorg> schreef in bericht
news:4c02c2f7$1@news.povray.org...
> Having kept an eye open, I noticed that responsivity is poor only at
> certain intervals, and I also have the impression that these indeed
> correlates with the finishing of SMP sub blocks.
>
> So I think this calls for closer examination and - if possible -
> elimination of this issue.
Do you want me to issue a bug report?
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I think that Christoph has - maybe - tracked down the problem. See his post
of yesterday, just above.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
