CGTalk > Software > Maxon Cinema 4D
Login register
Thread Closed share thread « Previous Thread | Next Thread »
 
Thread Tools Search this Thread Display Modes
Old 10-07-2012, 06:12 PM   #16
ThePriest
Bad Ass
 
ThePriest's Avatar
portfolio
Stuart Townsend
Environment artist
Berkeley, USA
 
Join Date: Jun 2005
Posts: 2,572
When I set affinity in the task manager and knock off a few cores, Cinema will often crash when you attempt a second render. Why is this?
__________________
۩PRIST

 
Old 10-07-2012, 09:52 PM   #17
selmo
Veteran
portfolio
Lars Norpchen
Octopus Motor
Pacifica, USA
 
Join Date: Sep 2009
Posts: 45
Quote:
Originally Posted by Scott Ayers
They have to come from a file on the system somewhere. But I can't find the file they are being pulled from.
I suppose it's possible that Maxon has these number hard coded into a .dll file where the users can't get at them. But I've never seen that before.
Usually every ID has a corresponding .h file and/or .res file somewhere in the file structure. It's just a challenge to find them sometimes.

-ScottA


Those particular prefs IDs would be plug in ID, and it is a little odd that they aren't listed. They usually are. I did find one -- PREFS_PROMAN for projection manager 465001636 in resource\c4d_symbols.h

Speaking as a programmer with no internal knowledge of C4D or Maxon, here's my take on why we don't see every ID in the headers:

No sane programmer would hard code IDs in the C4D source code, yet we have missing entries. Therefore the resource\c4d_symbols.h file we have is not the same file that the program was compiled against.

When I develop a plug in, I've got a C++ header that the compiler uses to generate the code, and a dynamic symbol definition file in the res folder. Two files read by two programs with similar but not identical purposes. But the two files consist entirely of common info that must stay in sync, so everything is a lot simpler if the same file can be used for both. (Maxon made their runtime symbol definition files in the res folder compatible with the C header file definitions to make this easier on developers). So usually the headers are the same file, but they don't have to be.

Maxon has an internal, private, and complete header(s) which defines all the symbols IDs for the compiler. Those numbers are baked in as immutable gospel, at least until the next recompile.

The public headers we have define dynamic functionality like connecting dialog UI elements to code, script parsing, (and SDK development). They are a subset of the original source code, with private symbols removed, things renamed to match documentation, cleaned up, etc. It's a manual process with potential for human error (no slight against anyone at Maxon, it's a big, complex file that probably changes frequently)

The SL numbers come from the compiled headers, so the SL doesn't lie. But it could be over-sharing. Using an undocumented value / raw number ID is taking a risk of breaking in a future release. Was that ID deliberately excluded from the public header files because it was private or subject to change? Or was it omitted by accident, the documentation not written yet, they didn't think we needed it, etc?

Since PREFS_PROMAN is a public symbol, it seems unlikely that the pref plug-in IDs are meant to be secret.

Or I could be wrong. Wandering way off topic too.
 
Old 10-07-2012, 10:11 PM   #18
selmo
Veteran
portfolio
Lars Norpchen
Octopus Motor
Pacifica, USA
 
Join Date: Sep 2009
Posts: 45
Quote:
Originally Posted by ThePriest
When I set affinity in the task manager and knock off a few cores, Cinema will often crash when you attempt a second render. Why is this?


I've had some render crashes, but nothing I'd attribute to affinity / cores / render threads / priority. Anything unusual about your system?
 
Old 10-08-2012, 12:47 AM   #19
ThePriest
Bad Ass
 
ThePriest's Avatar
portfolio
Stuart Townsend
Environment artist
Berkeley, USA
 
Join Date: Jun 2005
Posts: 2,572
No and it happens on all 4 machines.
__________________
۩PRIST

 
Old 10-08-2012, 08:29 AM   #20
doppelmonster
Veteran
portfolio
Matthias W
cologne, Germany
 
Join Date: Nov 2010
Posts: 32
@ selmo: thanks for the hint with the scriptlog! Thats a great way to get into scripting!

Unfortunateley just lowering priority never worked for me. you have all the time hickups where the system is not responding for a few seconds, thats why i usualy take away one of my 12 virtual cores for compensation.

@The Priest: are you using a second instance of Cinema or Netrender for a second render?
I had (since R14) no problems with parallel renders of cinema and net with changed priority/affinity settings....
 
Old 10-08-2012, 09:05 AM   #21
wbj
Expert
 
Join Date: Oct 2003
Posts: 614
Quote:
Originally Posted by ThePriest
When I set affinity in the task manager and knock off a few cores, Cinema will often crash when you attempt a second render. Why is this?


Most likely because you're fiddling with things whose timing you don't have under control.

Cinema sets the group affinity and uses newer Windows API calls that allow up to 256 threads - and does this since r13 to circumvent the limitations/bugs of older Win32 api functions that don't reliable return if you have 32 or more threads in your cpu.

Depending on the timing and the content of the thread pool and your affinity changes in the task manager, you might get in conflict with the settings Cinema is using or is trying to set.

If you're interested, feel free to submit a crashreport to MAXON with a description of what you've been doing - there seems to be no report from you (yet) in the database.

Summing up: Avoid fiddling with thread affinity, and if you feel you need to, do it at program start as Srek suggested.

Best regards,

wbj
 
Old 10-08-2012, 11:15 AM   #22
doppelmonster
Veteran
portfolio
Matthias W
cologne, Germany
 
Join Date: Nov 2010
Posts: 32
hmm, i wildly changed thread affinity in R13 while rendering and never had a problem. I didnt realized any changes between R12 and R13 regarding renderthreads. For me its R14 were the changes take place, but only in combination with Win 7. Vista x64 and R14 play together as usual...
 
Old 10-08-2012, 11:25 AM   #23
wbj
Expert
 
Join Date: Oct 2003
Posts: 614
Quote:
Originally Posted by doppelmonster
hmm, i wildly changed thread affinity in R13 while rendering and never had a problem. I didnt realized any changes between R12 and R13 regarding renderthreads. For me its R14 were the changes take place, but only in combination with Win 7. Vista x64 and R14 play together as usual...


There is no difference in Cinema regarding the thread handling on Vista or Win7 (Cinema uses the same OS functions on both OS versions). It all comes down to timing...

Best regards,

wbj
 
Old 10-08-2012, 01:50 PM   #24
selmo
Veteran
portfolio
Lars Norpchen
Octopus Motor
Pacifica, USA
 
Join Date: Sep 2009
Posts: 45
Quote:
Originally Posted by wb
It all comes down to timing...

Best regards,

wbj


I dunno about timing being the cause .... a crash because of a race condition in changing affinity while c4d is setting up render threads sounds plausible, but it would be rare and not reliably reproducible. The theory doesn't fit the data. If I understand ThePriest correctly, when he changed affinity, C4D crashes later on, with the second render, not when he's changing the affinity. It is as if the crash happens when C4D is setting up the render threads for the second render and crashing because the number of available cores /threads is not what it expected ( I don't think that is happening, but the conditions and timing of the crash is similar). A simple test/fix would be to set affinity, at startup as Srek and WBJ suggested, and see if the second render crash goes away. If it doesn't fix it, the problem is elsewhere.

Many of us have had no problem changing affinity on the fly with reckless abandon, so I don't think there is something broken inside C4D regarding affinity....Multithreading, core assignment, and task switching is a very low level , ring-zero kernel thing, not under application control so Maxon would need to be doing something seriously unusual to break that. But if that seems to be causing trouble, don't do it. It's not officially supported and task manager does warn you that changing the priority / affinity settings may break something. Setting it at startup is safer.
 
Old 10-08-2012, 01:50 PM   #25
selmo
Veteran
portfolio
Lars Norpchen
Octopus Motor
Pacifica, USA
 
Join Date: Sep 2009
Posts: 45
(oops, dupe post)

Last edited by selmo : 10-08-2012 at 01:54 PM. Reason: duplicate
 
Old 10-08-2012, 02:32 PM   #26
wbj
Expert
 
Join Date: Oct 2003
Posts: 614
Quote:
Originally Posted by selmo
I dunno about timing being the cause .... a crash because of a race condition in changing affinity while c4d is setting up render threads sounds plausible, but it would be rare and not reliably reproducible. The theory doesn't fit the data. If I understand ThePriest correctly, when he changed affinity, C4D crashes later on, with the second render, not when he's changing the affinity. It is as if the crash happens when C4D is setting up the render threads for the second render and crashing because the number of available cores /threads is not what it expected ( I don't think that is happening, but the conditions and timing of the crash is similar). A simple test/fix would be to set affinity, at startup as Srek and WBJ suggested, and see if the second render crash goes away. If it doesn't fix it, the problem is elsewhere.

[...]


It is hard to say esp. as ThePriest has no bugreports or a detailed description (of what he did) submitted to MAXON.

Best regards,

wbj
 
Old 10-08-2012, 03:00 PM   #27
doppelmonster
Veteran
portfolio
Matthias W
cologne, Germany
 
Join Date: Nov 2010
Posts: 32
Quote:
There is no difference in Cinema regarding the thread handling on Vista or Win7 (Cinema uses the same OS functions on both OS versions). It all comes down to timing...


I have 2 vista systems and 2 win7 systems running. Vista systems are obeying the affinity settings. Win7 are resetting the settings. So this is reproducable....


@selmo: what system combination do you have?
 
Old 10-08-2012, 03:53 PM   #28
selmo
Veteran
portfolio
Lars Norpchen
Octopus Motor
Pacifica, USA
 
Join Date: Sep 2009
Posts: 45
Quote:
Originally Posted by doppelmonster
@selmo: what system combination do you have?


Windows 7 x64 Core i7 980 @ 4Ghz w/24GB RAM

I also tested it on one of my renderboxen and it does keep the affinity as set across multi-frame render. WinXP x64 AMD FX-8120 @4.2Ghz w/12GB RAM.

So yah, sounds like the affinity reset in multiframe renders is windows 7 specific...
 
Old 10-08-2012, 03:53 PM   #29
CGTalk Moderation
Lord of the posts
CGTalk Forum Leader
 
Join Date: Sep 2003
Posts: 1,066,480
Thread automatically closed

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.
__________________
CGTalk Policy/Legalities
Note that as CGTalk Members, you agree to the terms and conditions of using this website.
 
Thread Closed share thread


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright 2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 08:23 PM.


Powered by vBulletin
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd.