 |
|
|
|
|
|
 |
| ||||||||
 |
 
|
|
|
|
|
|
|
|
|
| ||||||||
|
|
| 
| User list | Rules | You are not logged in.
Each time I start rendering I change the priority from normal to lowest.
Would be nice if default priority for rendering que can be set in settings of autopano.
Offline
Issue 633 opened
Offline
I notice that in new version 2.5.1. there is no more priority setting for rendering queue. Why was it removed and how is the priority for the queue now?
Regards,
Hans Keesom
Offline
In fact, because the priority could be changed easily with the type of thread we are using now. So, it's normal priority.
Offline
"type of thread"??? Apple speech? Would still like my initianal request.
Offline
Sorry for my confuse answer. We removed this feature because it was not compatible with the way we are managing now multicore.
Offline
At the moment I am frustrated again as I want to work on groups while rendering in the background. It is frustrating to see how the mainwindow is slow because there are some groups rendering. Lowering priority in taskmanager is not a solution as then the mainwindow also gets low priority.
Please bring back the prio-option for the rendering que. Or give me an option to limit the number of cores used by the rendering que.....
Offline
We cannot bring this option back because of how it works internally. Nevertheless, just reduce the number of thread in general setting and you will automatically limit the number of cpu used in the rendering.
Offline
AlexandreJ,
Your suggestion will also bring down the speed of the normal workspace as autopano is one programm and also only one process.
When I want to edit a series of groups, I now have to keep rendering for a later moment f.e. night.
This really brings productivity down and hurts one of the prima qualities autopano had, the fact you could really streamline your workflow.
Last edited by HansKeesom (2011-07-04 15:31:37)
Offline
Yes, whole autopano is affected by the reduction of cpu number, I agree.
Really, thread priority is something hard to get back in the new engine.
Another solution would be to have a different settings for the number of cpu, one for general usage and one for rendering.
But again here, I don't see that as a real solution. CPU is a limited ressource. When doing detection and rendering at the same time, you are sharing cpu and you are not as fast as doing detection then rendering.
Offline
At the moment I run autopano in low priority all the time. this does not hurt the interactive part and is what I want for the rendering.
When I want to work interactively I now pauze the rendering. Not ideal but it works. It just might take a bit longer to finish the rendering.
Offline
When in interactive mode I change anything regarding colors a process called color equilisations sometimes takes a lot of time to finish. In the task list I then see it takes only 12 % of CPU. this happens everytime so it seems like this process only takes one CPU. Because it is part of the interactive part of the programm it is a pity not all 8 cores of my machine are used. Hope you can change this as it would speed up things a lot.
Offline
Yes, we know this part is not multithreaded. Converting an algorithm to multithread is often really complicated. We did concentrate to make the most efficient use on the first algorithm that can really use them ( detection and rendering ), we are now at the place where second algorithms are beeing taken care of.
Offline
So everything that is not rendering is single-core only. I am under impression it was not like this.
Would it be an idea when each group would get it's own processor. Then I am able to detect 8 groups at the same time instead of one. As groups are rather seperated I would imagine spawning a separate process should not be to complicated.
Offline
Don't make me say what I didn't. Many algorithms are already multithreaded ( the detection in full, part of optimization, full rendering ), but some parts in the software are still monothreaded.
There's a huge job assigned to multithreading here and our partner Intel is helping us a lot on this part, but again, it takes time to get all algorithm done.
Offline
Alexandrej,
I hope we don't end up in an unfriendly discussion. I do care about your product and want it to be even better.
Your considerations why you change the whole technical implementation is problably right from a software-engineering point of view.
It seems however that you did not realise how I, and maybe many others, am/are using the programm. You might be interested in speeding up the rendering, frankly I don't care if a rendering job takes two hours instead of one. I do care about MY time behind the computer I ran Autopan on, that should be one hour instead of two. At the moment I feel I have to wait longer for detections to finish as they run on only one core.
Kind regards,
Hans Keesom
Last edited by HansKeesom (2011-07-11 17:16:22)
Offline
HansKeesom wrote:
I hope we don't end up in an unfriendly discussion. I do care about your product and want it to be even better.
No problem here. I like to understand how you work to see what I can do to make the product better.
HansKeesom wrote:
Your considerations why you change the whole technical implementation is problably right from a software-engineering point of view.
It seems however that you did not realise how I, and maybe many others, am/are using the programm. You might be interested in speeding up the rendering, frankly I don't care if a rendering job takes two hours instead of one. I do care about MY time behind the computer I ran Autopan on, that should be one hour instead of two. At the moment I feel I have to wait longer for detections to finish as they run on only one core.
Why not work this way ?
- Before doing anything, use pause on the batch rendering
- Do all your work on detection, edition, saving, and rendering with all cores. So you'll have full power during detection and edition.
- Unpause when leaving the computer. It starts rendering at this time only.
Offline
Hi AlexandreJ,
Yes I often work that way now as it is the best I can do now.
but...
"Do all your work on detection, edition, saving, and rendering with all cores". All cores? while doing work like detection, edition etc, only one core is being used as far as I can tell....
but.....
while working at my computer I have a lot of left-over CPU-power that is not being used. Sometimes I am behind computer for 10-12 hours. I would love the leftover-CPU-cycles to be used by a background task, like ....... rendering.
Regards,
Hans
Offline
HansKeesom wrote:
"Do all your work on detection, edition, saving, and rendering with all cores". All cores? while doing work like detection, edition etc, only one core is being used as far as I can tell....
If you did select 'automatic' in core selection in general menu settings, all cores will be used during detection, some part of the edition too ( but not all parts as said in the previous post ).
HansKeesom wrote:
while working at my computer I have a lot of left-over CPU-power that is not being used. Sometimes I am behind computer for 10-12 hours. I would love the leftover-CPU-cycles to be used by a background task, like ....... rendering.
I agree. But this is not totally possible with current settings.
Offline
AlexandreJ wrote:
HansKeesom wrote:
"Do all your work on detection, edition, saving, and rendering with all cores". All cores? while doing work like detection, edition etc, only one core is being used as far as I can tell....
If you did select 'automatic' in core selection in general menu settings, all cores will be used during detection, some part of the edition too ( but not all parts as said in the previous post ).
HansKeesom wrote:
while working at my computer I have a lot of left-over CPU-power that is not being used. Sometimes I am behind computer for 10-12 hours. I would love the leftover-CPU-cycles to be used by a background task, like ....... rendering.
I agree. But this is not totally possible with current settings.
I have no automatic setting, I can only choose between mono and multicore. When choosing multicore I can choose the number of cores. As rendering can not be set to low-prio, I guess I have to choose to use not all cores
Last edited by HansKeesom (2011-07-12 17:32:53)
Offline
Actually, this seems to work rather well, choosing to use only 6 out of 8 core's. I can continue doing other tasks on the computer, even do some editng in groups. Editing feels rather swift.
So now only 2 out of 8 cores are not used while I have to edit, but at least 6 are used and I don't need to hit the pause button on the batch queue.
for now, things are working fine again.
Offline
AlexandreJ wrote:
...
Another solution would be to have a different settings for the number of cpu, one for general usage and one for rendering.
...
I too am repeatedly frustrated when working on a batch of panos, having my system grind to a halt when rendering... I often render, check final output then change viewpoint perhaps then render a 2nd... or move on to the next pano...
The old autopano really was good for workflow and i really hope you can restore this much missed functionality. Your solution here does sound sensible.
Also, can the rendering be farmed out to a whole separate process? then perhaps the priority is easy to set again?
I'm loving how quick autopano is, but really not enjoying the workflow stopping... I agree that i'd rather have the rendering take longer than have the interactive ui slow down at all.
I'm giving the core limiting a go (2 instead of 4 for me)...
This is a great example of not knowing how good you've got it until it's gone...
Finger's crossed...
Offline
Added to our todo list.
Offline