|
|
QC killing my GPU? I've been using QC for about 7 months, and have had to restart my computer at least 25 times from QC crashing it, or rather me triggering crashes by putting in some value in a parameter that sends it over the top... However lately its seemingly worse. Sometimes it's triggered by simple things that wouldn't normally cause it to crash. Most recently while working with the OpenCL text extrusion composition. After a few crashes it wont even let me plug an image into the vertex displacement macro without crashing it. Upon restart and trying again I had some GUI glitching that didn't go away after closing quartz. By Crash I mean the computer. Have other users experienced much of this sort of thing? Running a mid 09 macbook pro with the 9600M GT and 3.06GHz Processor. Some of this stuff really shouldn't be causing it to crash the computer. Especially when it didn't before.. Thoughts? Thanks
|
It seems very similar to sporadic problem on my father's old white macbook (G4). Usually it recovers with one or two times of rebooting.
I believe your problem is not caused by OpenCL, GLSL and QC programming, but I can not prove it.
Post a bug report to Apple with the comps and a system profile. Otherwise it wont get fixed.
Seen that sort of thing before when crashing with OpenCL.
A few tips.
Avoid changing inputs for textures and image processing whilst rendering OpenCL live.
If you begin to get glitches, attempt to quit the composition, starting with the Viewer window, then quit QC and start again.
[Just a rough and ready impression, but QC related problems do seem to hang around in the cache or some other undetermined by me as yet, background state.]
Annotate the composition as to the parameters found to be 'safe' in working operation.
OpenCL does seem to be very fussy about what it will work with values wise. For instance I have a working OpenCL graphic routine, but even though it can, in theory, take a negative epsilon value, in practice, no doubt due in some small part to the the kernel routine itself, it will spin out when asked to turn the routine inverse upon the epsilon.
I'm still finding my way with OpenCL and find that the visualizers that I've been drumming up that exploit the .DAE & OpenCL facilities in QC4 comps can, when presented an unusually high or strong note, simply freeze up, flicker up and crash.
You are not alone in getting video glitch problems after an OpenCL crash.
The way I think of OpenCL and QC now is that although the workspace can be calculated automatically, none the less, that automatic space's real level of configurability is sometimes a process of discovery, trial & error.
I'd like to get to a rather clearer statement of what a routine really can, or can't do, OpenCL wise.
I don't think that's fixable -- OpenCL doesn't have memory protection, so a malformed kernel can read from/write to memory used by other applications. That typically causes crashes that look like the image above.
A single reboot should clear things up (that should be sufficient to re-initialize the GPU).
When using the term "restart", please specify if you're restarting the computer (i.e. powering off, powering back on), or if you're just restarting Quartz Composer (quit/force quit, relaunch).
i have been messing with the tl_particle examples the last few days and noticed a large increase in reboots. what i have found like cybero mentioned... if you notice the hang try and stop the render with apple period or even try and force quit qc while you can, but even then like chris mentioned there is some garbage left over in the buffer which sometimes creates some pretty cool non intentional glitching effects but requires a reboot to clear. i patched the boot kernels on my mbp to always run in high performance mode because i noticed problems when using 9600 in qc but running on 9400. i know when my screen blinks black then everything hangs there is no since in waiting, i just reboot. i must have rebooted 20 times the other day. it wasn't until i closed maya that the crashes stopped.
What a luxury that dual graphics on the mbpro is.
I haven't found the t-linked examples to be very crashable - well apart from the t-linked Julia and that shares the same problem I find with a couple of other fractal based compositions and is by no means confined to OpenCL, being a problem with GLSL and someone else might also find this to be true for CoreImage based fractal kernels - namely that negative values on certain crucial inputs can provoke a real hang.
In fact - the supersampling and the consequently discovered workaround that incorporates full screen and feedback capabilities has been an eye opener for me - so thanks to the original author Pascal Lesport for those examples. They all take static and certain types of dynamic structures as mesh really well.
Shall be posting results up to the usual video points.
Are you running in 32bit or 64bit? OpenCL is really unstable for me in 32bit mode (in the past), but with less problems like that in 64bit. I've had similar graphics glitches and am running the 9400/9600 combo with the 3.06...
Almost invariably 64 bit, apart from when working with 32 bit only patches and plugins .
I too find a slight performance hit when running in 32 bit QC.
I only have 9400 [sob, moan :-)]
I don't find a performance hit at all on my system, but editing the OpenCL Kernel is totally unstable in 32 bit.