|
|
Got OpenCL working on CPU in QC! In QC, go into preferences whilst holding down alt, go to system section, tick 'QCDisableCLOpenGLSharing'. Thats it really, reload QC and compositions that use openCL will now run on the CPU. It appears to work across the system, eg my itunes visualizer that uses 2D Fluid Simulation now works on my mac pro. This trick can also be used on systems that do have a functioning OpenCL GPU, but you want to see how your CPU performs, because QC will now use your CPU instead (you can check this using the Context patch but it will be pretty obvious from high CPU use.) Hope this is of use to some of you whilst waiting for Apple to fix bug or convince spouse that new computer is a good idea ;)
|
That seems off.
System wide qtz playback shouldn't be affected by a setting in the QC app, since the files need to work if you don't have QC installed.
I'm not saying what you are seeing isn't happening, just that it's a tremendous change in the way things have work if a setting in the QC app effects rendering in something like iTunes.
Its logical if you consider that part of the preferences is called system, rather than editor. I guess it sets something in the OS rather than a mere app preference.
itunes is the only thing Ive actually run a .qtz with OpenCL in to confirm this, but its pretty consistent for me, ie my cpu use rockets up on the laptop that does have a suitable GPU when I check that option, and my visualizer actually works on the mac pro where before it did not.
I think elbows is right on this -- the (System) options are seldom-used options that possibly are system-wide (I'll have to snoop some plists to know for sure, of course).
The only one that comes to my mind (on leopard) is the IBPalette option -- that does something in Interface Builder.
Works for me! Slow, for sure .. but it's there! I was totally shut out before. Yay! ATI RadeonHD 2600.
Interesting. Yeah, come to think of it, I'm thinking about some of the options under "Editor" not transferring (like multisampling), not ones under System.
Interesting observation to say the least... I wonder if this checkmark being enabled/disabled is why I was able to run on the X3100 with most things working? (I wonder if it was in the correct position on a pre-release version).
I'm not sure -- I think the state of things changed a lot between WWDC08 and 10.6.0. I know that initially (the first dev seed) it didn't work on my MacBook (GMA950). I followed the updates really closely, in the hopes that it would work. Eventually, it did work (not sure exactly when, but I was excited). It was slower than all get-out, but it stopped crashing/exploding.
Then, a few updates later, it stopped again. I'd be interested to see if it was that setting (and thus it never really worked), or if it was some subtle QC/GL/CL bug/driver quirk.
Maybe, though I am more inclined to guess that this option is merely happening to work around the part of the system that has the bug.
Likewise I cannot be sure whether using the CPU for OpenCL with this setting is a fair reflection of how OpenCL CPU in QC will perform when the bug is fixed. The feature that is being disabled may only work with GPUs anyway, eg feature that enables openCL data to pass to OpenGL without leaving the graphics card, but I cant be sure.
From what limited testing I have done so far using mesh OpenCL stuff, its going to take quite a powerful gpu to beat the performance of Kineme3Ds object stuff on the CPU, but I cant be sure if there are other bottlenecks in the QC OpenCL flow as I dont have a more pwoerful GPU to try yet. I need to double-check but I did seeem to get better framerates out of the qc mesh stuff using my CPU than the 8600M on my laptop, albeit with little CPU to spare for anything else. But 2D Fluid Simulator performed as well on my 8600M as it did using up to 600% of CPU on 8-core 2.8Ghz 2008 mac pro.
Just to clarify that I was responding to George, which is why my response seems a slightly obsolete response to chris's.
Anyway its certainly not as straightforward as it being ticked being a complete solution, as it stops OpenCL working on the GPU on those machines where it should be able to.
The option to disable GPU for OpenCL always amuses me because it doesnt seem to work, and I havent messed with any of the other ones yet to see what they do to performance.
I am still getting to grips with just what does and doesn't affect OpenCL performance upon a relatively low level OpenCL capable machine.
QCEnableCLProfiling will, for example, stop N-Body.qtz running on my machine [iMac 24"], probably just way too many threads to profile, whilst other OpenCL compositions, Snow.qtz, Grid.qtz & Quad.qtz and other Mesh rendering compositions do not fail to render with those set of preferences.
As you've previously noted, Steve, disabling OpenCL sharing will stop the GPU from playing its useful role, although it does give one the CPU fallback on [at the time of writing] non OpenCL compliant graphics hardware.
Funnily enough QCDisableCLGPUDevice will still allow N-Body.qtz to run, and quite actively too. :-)
Obviously more to discover, afore I, at least, get to see the wood for the trees.
Hope no one minds me bumping this but it appears to be broken now?! I just get a big red window when running the 2dflow.qtz in safari. ('QCDisableCLOpenGLSharing' ticked).
10.6.3 Intel Core 2 Duo 2.66 GHz ATI Radeon HD 2600 Pro
You shouldnt need to tick that option in 10.6.3. Try unticking it. Its also quite possible that its a problem with the composition rather than OpenCL being completely broken on your machine. Ive forgotten what 2dflow.qtz is.
Hi there!
I'm using OpenCL with QC. I use this for a system that will run all day. Unfortunately, after about two hours the system cache is full and I have to force quit my composition. What kind of cache is this? I have installed Cocktail to purge and swipe at a schedule daily, but there are so many different types of caches.. Kernel cache, virtual memory, temporary files, etc. What do I need to delete and ss there some option in QC to delete this? I hope you can tell me more about this! Thanks!
Paul
Without the composition I'll have to hazard a guess ...
Have a look in com.nVidia.OpenGL or com.AMD.OpenGL [or whatever is the name of the AMD equivalent to the nVidia OpenGL cache] within Library/Caches
and also look within ~/Library/Caches/com.apple.QuartzComposer.editor and ~/Library/Caches/com.apple.QuartzComposer.QCPlayer and ~/Library/Caches/com.apple.opencl
Actually come to think of it - this would have been better on a brand new thread - this original thread referred to the disabling of OpenCL GL Interop when OpenCL was rolled out for the first time and many machines did not have the hardware that was at that time supported by the OpenCL version 1.0 framework.
A lot has changed since then [2009-then , 2012-now]