|
|
Leopard 64 bit Runtime problem on G5 Mac The following is the output of my console when I try to get my machine to render a composition in 64 bit runtime [Leopard]. 26/04/2009 20:56:26 [0x0-0x21021].com.apple.QuartzComposer.editor[223] objc[253]: GC: forcing GC OFF because OBJC_DISABLE_GC is set 26/04/2009 20:56:26 [0x0-0x21021].com.apple.QuartzComposer.editor[223] objc[253]: GC: forcing GC OFF because OBJC_DISABLE_GC is set 26/04/2009 20:56:26 [0x0-0x21021].com.apple.QuartzComposer.editor[223] objc[253]: GC: forcing GC OFF because OBJC_DISABLE_GC is set 26/04/2009 20:56:26 [0x0-0x21021].com.apple.QuartzComposer.editor[223] objc[253]: GC: forcing GC OFF because OBJC_DISABLE_GC is set 26/04/2009 20:56:49 [0x0-0x21021].com.apple.QuartzComposer.editor[223] objc[256]: GC: forcing GC OFF because OBJC_DISABLE_GC is set 26/04/2009 20:56:49 [0x0-0x21021].com.apple.QuartzComposer.editor[223] objc[256]: GC: forcing GC OFF because OBJC_DISABLE_GC is set 26/04/2009 20:56:50 com.apple.WindowServer[59] aped[59]: Attach failed: -1 (BSD: system 0x3F/0xFFF, err 16383), for QCPlayer[256] 26/04/2009 20:56:57 ReportCrash[258] Symbolication warning: fde.addrRange.location 0x7fff701cc140 isn't in the the __TEXT segment [0x7fff81678000 - 0x00004000) 26/04/2009 20:56:57 ReportCrash[258] Symbolication warning: fde.addrRange.location 0x7fff701cc148 isn't in the the __TEXT segment [0x7fff81678000 - 0x00004000) 26/04/2009 20:56:57 ReportCrash[258] Symbolication warning: fde.addrRange.location 0x7fff701cc148 isn't in the the __TEXT segment [0x7fff81678000 - 0x00004000) I would include the Log Message but one was not even generated. I had been dry running another forum members composition trying to figure out why it wouldn't work on an Intel Mac running Leopard. In the course of doing some runtime tests got several plugin error flags, both at 32 and 64 bit runtime, e.g: - wrong architecture for Kineme 3D for example. I cleared out all the offending items and had no problems at 32 bit Leopard runtime. 64 bit runtime testing just doesn't seem to work across the board, regardless of file used, including Apple's own examples in the Developer Tools folder. Should 64 bit runtime work on a PPC? |
Looks like you should disable GC, and provide a backtrace, and see if removing ape helps (I'm not anti-APE, mind you, but it is something to remove before pointing fingers elsewhere).
Kineme3D cannot work on 64bit ppc, as Autodesk refuses to build the FBXSDK for 64bit ppc (64bit intel is supported). I suppose I could remove all the FBX junk for 64bit ppc support, but then you're stuck with parametric surfaces and MD2 models only, which isn't particularly helpful.
Is there a reason why you're using 64bit?
I only got to the point of intriguingly disappointing myself with 64 bit runtime testing because I was seeking to find out why Spirograph2.qtz posted for help and advice by jersmi wouldn't work on an Intel Leopard setup.
I had satisfied myself that it rendered AOK for me as a screensaver, then tried other runtimes in case this would give me some clues about Jersmi's problem and instead got a lot of architecturally inapposite plugins error messages in the runtime log [they've been removed for the time being, including the Kineme 3D plugin and Particles plugin].
By the time I'd cleared out all the possible offenders, 64 bit runtime still wouldn't render a thing, my physical quartz extreme support is described as 32 bit so perhaps getting a fully 64 bit GPU would be an improvement / solution in the interim and obtain an Intel Mac in the longer term :-).
Will be removing APE at your suggestion.
I was wondering how to disable GC and set backtrace - globally or by application?
Thanks for your feedback.
GC is a per-application compiler-time setting. Look in xcode, at the project settings (there are 3 possible states, Required, Supported, and unsupported -- make sure it's not Required).
backtraces are generated automatically when an app crashes -- check out the crash log.
There are some known issues with QC+GC, so perhaps simply removing the GC requirement will make it happy? I have no idea really -- I've never had a PPC mac (and have zero experience with 64bit stuff in ppc-land, as Rosetta doesn't run 64bit ppc binaries, sadly)
Out of interest what is GC?
GC = Garbage Collection (specifically, automatic garbage collection)
Looks like that won't change much, but it's difficult to tell -- the log above has GC stuff for the QC editor only (possibly a plugin is trying to use it?).... Not sure about QCPlayer.
I slotted QC into an XCode Empty Project, ran it in debug mode, everything was plain sailing until, yet again, looking to run 64 runtime, 32 bit was OK, so was running Tiger compatible runtime compositions [still have a wealth of those left].
At 64 bit runtime the application spat its proverbial dummy out and gave me this output.
The first significant breakpoint came at
I am still making sense of this. It isn't exactly severe. It may be something that will only improve once I update my nVidia GeForce 5200 [well overdue].
There re certainly some Open Source and Commercial plugins that are only fully operational, or operationally efficient if run with either the newer graphics cards and / or newer processors [Intel to an experienced PPC user such as myself]
I honestly think that it is really a matter of updating to an Intel form factor Mac.
I hope I'm entirely wrong about that.
I can now help to put this one to bed.
Completely.
With warm milk and cookies :-)
I did completely strip out all the 3rd party plugins that had not provoked an error message in the QC runtime console log.
I ran QC as it was first installed [checked directory listings with original installation logs]
Ran the file that had provoked an error log response and null 64 bit rendering.
It ran, with a gaussian blur to replace the v002 blur patch, though this had not provoked an error response if it could be put into play. I was just experimenting with a purely default installation workbench.
I ran QC in Debug with Activity Monitor / Instruments and retained the record; Instruments worked unlike any non command line monitor I've ever worked with before - fantastic.
It transpired - rather unsurprisingly - that the file ran in Tiger, Leopard 32 and Leopard 64 bit runtime.
So Leopard 64 bit rendering is feasible and sustainable, although , more likely than not down to my graphics card, the default nVidia, I find that the 64 bit Leopard is really rather glacial.
Good news, little or no perceptible detioration to 64 bit rendering was resultant upon reinstalling Kineme Core.
Now I shall be testing each and every one of the 3rd party plugins and Developer plugins that I had previously installed via Official or 3rd Party API.
I shan't be boring you with any more of the details, suffice to say that I've learnt a considerable amount about how my PPC Mac can and also can't work with the QC framework and its indigenous and 3rd Party extensions. Thanks to all of you who gave such good advice about this. Much appreciated.
One thing is for sure, test bedding of materials for later edition Mac consumers is only going to be thoroughly feasible to some extent with a fairly up to date machine, although I shan't be giving this reliable workhorse up.
Anyway here's the picture, the proof. Don't wait for the movie :-)
I think I might well be using the slightly revised [Gaussian Blur for v002blur] Spirograph in my future testing of each separate plugin.
There was talk of a clean up app, snap-in for QC sometime ago, I wonder if it could be made to detect if there were any conflicts between the plugins called upon at runtime. I still am to find the miscreant but the good news is that Kineme Core is not one of the items causing any difficulty.
However, Kineme 3D is perceived in the QC runtime console as an unexpected architecture , although the 64 bit runtime still operates, as does 3D rendering, if called upon.
no matching architecture in universal wrapperKineme GL Tools does not provoke an error message.
Just as a matter of interest, how well do Intel machines cope with 64 bit runtime rendering? How often, if at all, do they drop to 32 bit operation?
When I find the actual miscreant, I'll let you all know.
Glad you got it somewhat worked out -- keep us posted on the malfunctioning 64bit stuff so we can address what we can (Kineme3D will likely never be 64bit ppc, but otherwise we should be able to support everything else).
Intel Macs generally don't run QC in 64bit. Almost all our development takes place in 32-bit mode (though with Snow Leopard that may change, depending on how pervasive 64bit apps are in 10.6). 32/64 bit operation is a per-application setting. Either an app is 64bit, or it's not. It can't change on the fly. All the QC-using apps I've seen thus far are 32-bit only, so 64bit is simply a novelty. we've toyed with a 64bit version of QuartzCrystal, but then QuickTime/QTKit become the weak points (API holes, etc).
KinemeCore should be 64-bit clean as of the latest round of betas -- we're working on updating/future proofing it a bit more for future beta releases (the majority of the code was written in my first 6 months of OS X programming, so lots of silly mistakes stuck around -- just finished a heroic cleanup this morning to redress most of that). If you find anything otherwise, please let us know.
From the profiling I've seen, 64bit Leopard is Intel optimized, not so much for PPC... the writing's on the wall, it seems...
Opened up Quartz Composer and the Kineme Core saw fit to call back home and so I thought lets send that useful information to Kineme, clicked submit and this ensued
Shut down QC, withdrew Kineme 3D & GL Tools restarted QC, all OK.
Definitely getting some odd results with QC at present.
How true indeed.
I'm fairly sure most of my reported problems will be reduced by getting an Intel workbench. A faster graphics card will speed up rendering too.
Thanks again for your informed input, I shall have to run and exploit all and any 3rd party plugins with real care.
32 bit rendering for the time being then [ I am given to understand that one potential incarnation of Snow Leopard will only have extensive deployment of 64 bit system & default applications for a fairly limited hardware set].
Thanks for confirming a whole load of things, oh and peeking my interest in Instruments - sweet bit of kit.