Processor Core Usage In Chief ?

[TheKitchenAbode]

I am trying to better understand the new capabilty to set the processor cores for Raytrace. Apologize for the length of this post.

 

Prior to X7 I assume that processor core managment was left to windows. My research into this indicates that windows by default makes all cores availabe to all running processes. There are also other peramiters such as priority that I assume windows also uses when managing throughput for best overall performance.

 

With X7 we can now define the number of cores. My initial asumption of this was that now I can direct windows to isolate those cores for the exclusive use of Raytrace and therefore the remainig core(s) are the only one(s) available for windows to manage.

 

Some other research I was doing indicates that in Windows there are already settings such as Affinity that allows me to assign cores to a specific program through the task manager. It is however my understanding that this does not isolate the cores but instead it tells windows that when managing all of the cores that it can only split the core specified program processing between the avaiable cores up to the programs defined limit. Under this scenario you are restricting the core defined program and that other processes not only have access to those cores but also have exclsive use of any additional cores that the defined core program does not have access to use.

 

Prior to X7 my system while running a Raytrace was obviously affected but it appeared that windows was on its own managing things reasonably well. Immediately after upgrading to X7 my system instantly demostrated a very noticable lag when running a Raytrace. The default Raytrace core setting is set to maximum cores. If I reduce this I can reduce this lag, which is how I came to my initial assumption that you are dedicating cores to Raytrace.

 

Now I'm a very curious sole so I fired up my computer, loaded a Raytrace with cores set at 4, my max. Brought up the task manager and obsereved the cpu graph for each core. As one would expect all four cores ran at essentialy 100%. Good so far, lets try 3 cores. Not what I was expecting which was 3 cores running 100% and 1 core runing near idle. Instead all cores were processing, 3 cores were runing around 80% and 1 core around 50%. Set cores down to two. All cores were still processing, 2 around 80% and the other 2 around 50%. Now 1 core. 1 core runing 80%, 1 core around 60% and the remaing 2 around 25%. From this I have to conclude that the Raytrace core assignment is not what we think it is. All cores are still being used, it seems to just force a redistribution which appears to be more of a cpu % usage control and not a core usage control.

 

To verify this I set the Raytrace cores back to 4. This time I used the windows affinity seting to assign core usage to Chief and rant the Raytraces again. 4 cores assigned, all 4 cores ran 100%. 3 cores assigned, 3 cores 100% 1 core idle. 2 cores assigned, 2 cores 100% 2 cores idle. 1 core assigned, 1 core 100% 3 cores idle. Exactly what I would expect.

 

Also, when the affinity cores were lower than the max. Then there was no effect when changing core assignment through Chief. The affinity settings over ruled.

 

Raytrace times were essentially the same and matched each core assignment whether they were set through Chief or Windows. I am wondering though if the difference in the way Chief manages cores compared to that of windows may be why we are experiencing these quirky slowdowns.

 

Hope so, otherwise I did all of this for nothing. Well not completly for nothing at least my curiosity seems to be satisfied for the moment.

 

Thanks for reading,
Graham

 

 

 

[Doug_Park]

The terminology in the dialog is technically inaccurate, but conveys the idea of what is happening reasonably well using terminology that most are familiar with.

 

What we do is more accurately described as controlling the number of threads being used by the ray tracer.

 

A thread is an OS level concept that says everything that is executed in a single thread is independent of other threads. Which allows the OS to assign the work to a single core or to spread it out over multiple cores if desired.

 

We leave the core assignment to the OS since we think the OS is better suited to manage that allocation than we are.

[TheKitchenAbode]

Thanks Doug for explaining what is actually being done here. Can't let the "technically inaccurate" comment pass by. I'm no more technically inaccurate than the Raytrace Dialog DBX terminology "Number of Cores Used".

 

I ran some other tests comparing the thread approach versus the core assignment method.  Agree that the thread approach appears to run smoother, the core assignment demonstrated lag sooner than the thread approach. Regardless of which approach was being utilized everything was running smoothly until all of the cores maxed out at 100%. Had some other programs running in the background with a Raytrace. There was still some available headroom so I started jumping around tabs & library items to load things up. A very noticeable lag was occurring once the cores all reach 100%. Ran this procedure twice and was able to get X7 to crash both times while flipping through the catalog.

 

Graham

[Joe_Carrick]

Graham,

 

The generally preferred norm for RT is to set the system to use less than all cores.  IOW, if your system has 8 cores - set RT to use only 7.  This will leave a core free for other programs.  That's usually sufficient but if you have other needs you could limit RT to 6 or 5, etc.  IAE, the fewer cores RT has available the slower the RT will be.

[TheKitchenAbode]

Joe - I have a quad core with the core always set to 3 max. I am just playing around here to see what it takes to bog down X7 or make it crash. I've been able to crash consistently 5 times now. Using core set at 4, 3 & 2. Error message below. Always crashes when I am flipping through the catalogs.

 

 

..\source\ChiefQtApplication.cpp(174): Error #272000999

" Assertion failed: An unexpected error occurred. You should use "Save As" to save your current work in a NEW FILE and restart this program."

4/27/2015 4:56:06 PM

Build: 17.1.2.2x32

 

Graham

[Doug_Park]

The crash is concerning. That should not happen.

[Joe_Carrick]

Doug,

 

Graham is using the 32 bit version of X7.  Could that be the problem?

[TheKitchenAbode]

Just ran the same test with X6. All cores maxed out at 100% while running a Raytrace. Tab switching was fast a smooth catalogs came up quick, no real sign of lag.

 

There is a definite difference in X7.

 

This has been run on three different systems, all quad core. I also have the 64 bit version on other systems, same result.

 

It seems to happen only when the cores are maxed out. With a lot of multi tasking this is going to happen quite frequently.

 

Graham

[TheKitchenAbode]

Just downloaded the 64 bit version to the same system that I rand the 32 bit.

 

Seems to be smoother, but was still able to generate this crash.

 

..\source\ChiefQtApplication.cpp(174): Error #272000999

" Assertion failed: An unexpected error occurred. You should use "Save As" to save your current work in a NEW FILE and restart this program."

4/27/2015 5:52:19 PM

Build: 17.1.2.2x64

 

Graham

[Joe_Carrick]

Graham,

 

There was a similar problem with Library Browsing on systems with Intel HD Graphics.  Basically it was related to having a 3D view displayed and then displaying a 3D preview of a Library Symbol.  I'm not sure if that's been fixed or if's related but the problem you are having is not repeatable on my system with an NVidea Graphics Adapter.

[TheKitchenAbode]

Joe - I am using a Nvidia GeForce 650 Ti on this system. Another has a discrete Nvidia Geforce 310m mobile graphics adapter and another has integrated intel.

 

The only thing I find so far is that the better the system the more you have to push it to generate a crash. This would be expected as it only shows when the systems are being stressed out.

 

Graham

[Joe_Carrick]

Have you updated the Video Drivers?  None of those seem like current state of the art and the Drivers could well be out of date.

[TheKitchenAbode]

Joe - I keep my systems as up to date as possible, all auto update features are active and all windows versions are current. I should stress here that this crash is only something that I can induce by really putting my systems under severe stress. Under normal usage I rarely encounter a problem. However since X7 this has happened several times without me purposely doing anything special, at this point I can only assume that this stressing has always occurred at times during normal usage even prior to the release of X7. For reasons unknown to me it seems that X6 was able to handle this better. I  also have X6 and ran a comparison with X7 on the same system. X6 definitely appeared to run smoother and faster than X7 under the same type of stressing and I could get X7 to crash repeatedly.

 

Was driven to explore this from reading the other post concerning X7 Performance - Crashes?. Tech was expressing difficulty as they could not replicate their experience and users though experiencing problems could not find any specific association to help guide tech. What I have found may or may not be the cause, it is however something that can be replicated at least on my systems.

 

Please keep in mind that many users including myself use Chief for far less demanding work than others. For myself I only need to render interiors, primarily kitchens & baths. I appreciate and often envy those users with truly cutting edge systems and understand that their work load justifies and requires this. It would however be a shame if these types of systems are required in order to do my type of work.

 

Graham

[Doug_Park]

The 32 bit version can run out of memory and crash. Assuming that isn't the case, which it doesn't appear to be, it would be good for you to get with our support team and walk them through the steps to reproduce the crash.

 

It is possible the crash is associated with threaded operations inside of Chief. A test would be to turn off "Optimize for Multi-Core CPUs" in preferences and see if you can reproduce the crash that way. If you can't that narrows down the possible areas.

 

Thanks for the stress test. This something we do in testing, but everyone does things a bit differently so knowing exactly what you did is helpful.

[Chief_QA]

Just downloaded the 64 bit version to the same system that I rand the 32 bit.

Seems to be smoother, but was still able to generate this crash.

..\source\ChiefQtApplication.cpp(174): Error #272000999

" Assertion failed: An unexpected error occurred. You should use "Save As" to save your current work in a NEW FILE and restart this program."

4/27/2015 5:52:19 PM

Build: 17.1.2.2x64

Graham

Did you send the report in? I am not able to reproduce the crash, I tried on 2 systems, with multiple 3D views, plan view, 1 raytrace going, 1 raytrace queued, generating 3D views, flipping through the library, CPUs maxed, fans screaming away and nothing. If you send the report in we can look at the action report and maybe better able to determine what is going on. When you get the assertion failure, there should be a send report button, just press it and we will have an action report. How easy is that?

[TheKitchenAbode]

A test would be to turn off "Optimize for Multi-Core CPUs" in preferences and see if you can reproduce the crash that way.

 

I don't see this as an option in preferences. Are you referring to Chief or Windows?

[jbaehmer]

Here is where you can change the number of cores being used.

[jbaehmer]

Sorry....mis-read the statements.  Here is the "Optimize for Multi-Core CPUs" location

[TheKitchenAbode]

Sorry....mis-read the statements.  Here is the "Optimize for Multi-Core CPUs" location

 

Thanks Jared - That's the one I wasn't aware of. Will give it a try and see what happens.

 

Graham

[TheKitchenAbode]

With the "Optimize for Multi-Core CPUs" turned off it was quite easy to generate a crash. Sent report to Tech.

 

Had Raytrace set to maximum cores. Was running a Raytrace and then rapidly bouncing between different catalogs in the library. The crash seems to happen only when a catalog does not have enough time to fully display before another catalog is selected. It's as if it has difficulty dealing with multiple catalog requests.

 

Graham

[Joe_Carrick]

Hmmm.....

 

Might be an easy fix.

  disable_mouse - sleep_while_catalog_not_displayed - enable_mouse

or just loop within an error_block.

[TheKitchenAbode]

Hmmm.....

 

Might be an easy fix.

  disable_mouse - sleep_while_catalog_not_displayed - enable_mouse

or just loop within an error_block.

 

Ok Joe got me on that one. Can you guide me to that setting and I will give it a try.

 

Graham

[Joe_Carrick]

Ok Joe got me on that one. Can you guide me to that setting and I will give it a try.

 

Graham

Funny,

 

I was suggesting how it might be fixed by programming, not any user settings. 

[TheKitchenAbode]

Thank goodness Joe. I was starting to really sweat up here.  Thanks for your quick response. I really was starting to click through Chief & Windows settings trying to find it. I really enjoy a challenge but like to think I have at least a chance.

[Chief_QA]

Thank you, we have your report.  We will be entering a critical bug on this and maybe our developers can fix the issue.  However, I have the identical video card you have and am still not able to repro this crash.  Your driver is a bit old, it is from 7/2/14 9.18.13.4052.  My driver is 2/5/15 9/18/13.4752.  This could be part of it, you should check your other systems as well and see if they are also out of date and update.  X7 uses some of the latest OpenGL commands and it is imperative to have the latest drivers to fully benefit from these newer OpenGL commands for system performance and stability.  We still shouldn't crash, that is bad, and we will see if we can fix this.