 |
|
|
|
|
|
 |
| ||||||||
 |
 
|
|
|
|
|
|
|
|
|
| ||||||||
|
|
| 
| User list | Rules | You are not logged in.
I upgraded from my old PowerMac G5 to a Nehalem Mac Pro (8-core 2.93GHz, 12GB RAM), and upgraded from APP 1.4 to APG 2.0.
I set up APG to use 16 CPUs and a 4GB cache. I just did a first test with my new Gigapan Epic 100 motorized head and 28 frames from a Leica M8 with a 50mm f/1.4 (75mm-e). SIFT detection time is now ridiculously fast, and uses all 16 HT cores fully, but rendering only uses one core. I did not try enabling the GPU rendering as I only have a relatively slow nVidia GT120.
What gives? How can I have renders fully exploit the machine's parallelism?
Offline
Hi,
we will need to make some change in smartblend to be able to use all the power.
On your side, you can try multiband blender which won't remove any ghost but will definitively use all cores.
Offline
Thanks. Will Smartblend 2 be multicore-enabled?
Offline
I have exactly the same situation. Nehalem 8-core Mac, upgraded to APP 2.0. SIFT runs very quickly, but the render appears to be single-threaded. This is true with the multiband blender - the CPU is running consistently *under* 100% (i.e., less than one core), there are only 4 threads in the whole process, and virtually no disk activity (rendering to multi-layered psd). A partial gigapan of 208 images took 3-4 hours to render.
Another point: I'm running the 64-bit version. Should I try the 32-bit?
Offline
Another datapoint. I installed APP2 on linux using vmware on the same machine. Gave it 4 processors. This was able to render a sample 10-image pano in 1:26, whereas the same pano natively took 3:40.
Offline
Waouh. That's so strange. Did you try natively with 4 cores ?
Offline
Ah, that's the trick. Selecting '16' cores seems to cause the problem (I don't remember if this was auto-detected at 16 or if I chose that number). The same demo takes 1:13 with 8 processors natively, short enough that I can see the time is dominated by the single-threaded SmartBlend - the actual stitch took about 30s.
Offline
More info. I thought I'd play with the property list directly. I set general.nbThread to values in the range from 9-14, and I got the same symptoms - during render the thread count drops to 4 or 5, uses about one CPU.
The reason I'm persisting in this - with the CPU count set to 8 it never uses more than about half the power of the machine - I'm rendering right now and it's using only 12 threads. It's *fast*, but I think it can go faster. 8^)
Offline