Digital Art Zone

_ PJF _ - 07 September 2012 08:09 AM

boogazm - 07 September 2012 07:26 AM

Bad result for the extra CPU power!!!

So bad I’d check carefully that Bryce is actually rendering in high priority mode. Make sure it’s properly set just before you press the render button.

I always set priority to high, and seldom do anything else when Bryce is running. Got the old machines beside and a KVM-switch, not to bother the rendering one! Don´t want to slow it down further!

I even used to turn off processes going on in the background, but only those I knew didn´t effect the system! So, ok, there´s processes going on in the background but don´t think those can be the explanation. And there´s no ongoing virus scan or windows defender checks of the hdd so I put the money on the OS, shuffling around processes!

Made a screen dump early in the render, might be that the workload will be distributed to just 8 cores later on and the 4 threads remaining will evolve to be supports to the main ones, but don´t know right now!?

Testing should be done with a defined scene. Here’s a 45 KB ZIP file: http://www.horo.ch/raytracing/tests/zip/bosta03.zip It is a Bryce 5 file, you have to set the File Type filter to br5 to open it. I just rendered it on my i3 4 core (the i7 is busy) in High Priority. The task manager went to 100% and a short moment down to 99%. The scene finished in less than a minute. If you render the file on your 12-way CPU, CPU usage should go up to 67% which is 8 of 12.

Did a render test with your file, high priority mode, it clocked in at 20 seconds. You were right about the CPU usage, about 66%, varied some, but it wasn´t just running on 8 out of 12 threads. But the render finished so quickly that the diagrams gets a bit inconclusive! Made a screen dump of the process:

Ran another render over night, a couple of hours into the render the taskmanager showed a moderate but relative even load on 11 threads, the 12th thread showed a flat nothing???

Great test. I have that file because I know CPU load goes full throttle. There are files, when it doesn’t - something you have observed already. Do not be alarmed by how the computer distributes the work to the cores. In the picture above we see 8 cores quite high and 4 cores rather low utilized. Looking from Bryce, we would expect 8 cores maxed out and 4 completely idle. However, I have never seen that. Though my best machine is only a 8-way, I tested in Normal Priority when Bryce uses only half. Four cores are quite highly utilized, but not maxed, and the other 4 a bit. It resembles your screenshot, only with fewer cores.

Could it be differences of the OS´s or Bryce versions that make the differences in CPU-usage? My dual-core/4 threads also suffers from the same laziness, not maxing out but it runs on Vista 64bit? Going back in time, I remember Bryce running at full throttle!? Lots to gain in render times if it did today, even if there´s an 8 core limitation!?

I dunno. That example file was made at the time with Win 2000 (1 core), I’ve run it on XP (2 core) and also on Win 7 64-bit (4 core and 8-way) and all maxed out. I had one who run it on a Mac. So my ideas what’s the issue are exhausted. The only thing is the setting in the task manager. I have it at Normal.

Setting High Priority in the task manager was one of the first actions I tried but that didn´t have any major effect at all! Think it only gives Bryce first call on CPU resources when you have other apps open at the same time!?

Hopefully there´ll be a number 8 where these kind of shortcomings are gone, but as someone pointed out earlier, Bryce might not be a big moneymaker so we´ll have to wait and see!

I´ll throw some heavy stuff at Bryce later on and see what happens!???

So far only DOF, like in your test file, get´s Bryce going for full, in my case 67% at most. All other files I´ve tested, no matter how complex or what ever quality settings I use, it seldom creeps up to 60%, mostly doing around 30-40 or so!

Bryce is like a driver that goes 80 mph on a narrow, bumpy and curvy road and slows down to 30 when hitting the highway!!!???

boogazm - 09 September 2012 12:27 PM

Bryce is like a driver that goes 80 mph on a narrow, bumpy and curvy road and slows down to 30 when hitting the highway!!!???

Shouldn’t be. But there may be processes when Bryce doesn’t use all cores. I know that there are cases when it uses less than assigned with High Priority. But I haven’t found out yet which processes.

Some new data.  I ran Argus monitor.  The first test, Bryce uses all 6 physical cores of CPU0 to the max and even goes to max turbo boost on the xeon i5 2630.  It uses nothing of cpu1.  So if you want Bryce to use 8 cores, you need an 8 core cpu. 

Second test after a couple of days ( and reboots).  Bryce used nothing of CPU0 and all of CPU1.  Go figure.  This is odd.  The only BIOS change I made was to set the cpu’s to performance. 

Why did Bryce change from cpu0 to cpu1?  Clearly, it only sees one CPU.  Apparently not the same one every time.

...
So, now some more comparisons between medium and priority and resmon vs argus….

Regardless of medium or high priority render, Bryce used all 6 physical cores of cpu1 to max frequency (turbo boost) in argus, but in resmon, it showed about 10 percent usage of 8 cores in resmon (mix of virtual and actual) on cpu1.

A while back I saw 6 cores in resmon slammed to the max. 

I have no idea what is going on.

On low priority that is only supposed to use one core, I saw spike on both CPU’s to max for all cores in argus.  It would run one CPU to max, then back off and run the other to max.  Resmon showed one core to 80 percent and 3 more to lower levels around 10 to 20 percent.

Either the monitors are glitchy or Bryce is random in its cpu usage.

...

Time test..
I ran a benchmark render.  Sorry I didn’t time it accurately.

With low priority it was around 10 minutes and hardly used the resmon.  Argus was random but several of the cores on cpu1 ran up a bit.

With medium priority it was half the time, about 4 minutes.  Funny.  Argus slammed cpu1 as expected.  nothing on cpu0.  But here’s the interesting thing.  On resmon, 6 cores ran about half way on usage for the main render, then on AA, 4 cores (and they were different cores, went to max.  Argus just showed all 6 cores of cpu1 on both main render and AA at max.

So there is a difference in how resmon reads cpu usage and how argues does. 

With high priority, on the main render, resmon showed 10 cores in use on cpu1 and none on cpu0.  On anti aliasing, 8 cores at 90 percent and 2 at 20 percent. on cpu1 and nothing on cpu0. 

Just over 3 minutes for the full render.

So it appears that Bryce might use more than 8 cores(virtual and actual) and it might use some virtual cores fully.

Very random.

Interesting results, but confusng, as were mine render tests! FYI Maxwell Render also has two different priority settings but auto detects CPU usage so on LOW setting it uses all cores/threads to 100% if no other processes needs CPU power! That´s great, you don´t risk starting a render going on half CPU capacity just by mistake or forgetfulness!

My old Bryce test for multi core processors:

http://www.bryce-3d.narod.ru/bryce_test_multi_eng.html

Nice to see you back, Poser-user. I looked at your tests. They confirm that multi-threading only adds about 15%. The i7-920 is a 4 core multi-threadable CPU. On normal priority, Bryce uses the 4 cores, at high priority it adds multi-threading to the 4 cores. My old test is here http://www.horo.ch/raytracing/tests/rendertest.html
With new machines, I tested again with the same file and here are the results: http://www.horo.ch/raytracing/tests/rendertest71.html

... multi-threading only adds about 15%.

This is a very poor result. Where do you see the main reason for the small increase in rendering speed?

Poser-User - 21 October 2012 06:01 AM

... multi-threading only adds about 15%.

This is a very poor result. Where do you see the main reason for the small increase in rendering speed?

As I understand it hyper-threading was introduced to streamline the sharing of processor resources, the additional cores that come into play with hyper-threading are virtual cores, on normal priority Bryce has access to 4 real cores.  On high, 4 real and 4 virtual.  The virtual cores can only be whatever bits of processing power is left over from the real cores while whatever process is using the real cores is off twiddling its thumbs.  Now since Bryce is a number-crunching monster, the real cores hardly get any respite, so in this case there isn’t much down time, and hence not many slack clock cycles for the virtual cores to take advantage of.  As I understand it.  Remember I’m an artist not a hardware engineer.