Quartz Composer OpenCL Snow Leopard Tips: Heightfield with CL Kernel - VideoImage Extrusion Example Composition (Composition by

Excellent hands on exposition and demonstration drawn from the Apple developer examples.

I'm sure it'll help to make the OpenCL ready kit owners who might just be dipping their toes in the OpenCL waters feel more confident in using this new technology.

Great! Really nice! Could you perhaps also post the link to those OpenCL example compositions at the Apple Developer Connection?

OpenCL Heightfield - VideoImage Extrusion Example - Shadows (Snow Leopard).qtz: 0.95-1.26 FPS

2.8 GHz Intel Core 2 Duo. 2 GB 667MHZ DDR2 SDRAM. ATI RadeonHD 2600 with 'QCDisableCLOpenGLSharing' checked in QC System Preferences.

oops. Comment is to gtoledo. I hit the wrong reply button.

I didn't explicitly state the URL because I think people should poke around :)

Here it is, in case anyone has problems finding it (though it is ultra easy to find).

http://developer.apple.com/mac/library/samplecode/OpenCL/index.html

That's pretty rough FPS! What do you typically get with something like the "Depth Bomb" file I have here at the repository, or any of the Rutt Etra stuff?

I didn't mean to mess up your intended search prompt. I'll therefore go ahead and ignore the link and do that search as you wished. Thanks.

Depth_Bomb_01 has quite a range: 15-60 FPS. For the latest v002 RuttEtra plugin using the Vertex Noise with Texturing example that vade provided, a similar range: 20-56 FPS typically, with a few spikes down to 15 and up to 75. Other provided examples vary but all perform well, imho.

No biggie.

I think that the Procedural Grass and Terrain example, and the Procedural Geometric Displacement example were two cool projects (OpenCL and Xcode, non QC).

I was happy to see some other stuff updated.

Conceptual folder got skimpier, but it has good compositions. Thanks so much for the alert. Sincerely appreciated.

The vertex noise uses the noise3D function, which frankly is slow, but is easy to get working. If you did a bit of work you could get something similar running muuucccchhh faster. noise3D was just a good example to get the gist of how to use the RE.

Well, one thing that needs to be noted, is that the shadows ARE enabled by default, which creates quite an fps hit. As soon as I turn them off, I get 56~60fps on my system, with occasional dips down to 30ish.

As a matter of fact, I think I'm going to re-upload it, with the shadows turned off so it doesn't work as "funkily" for people when they open it up. If you want shadows, they'll work though :) For anyone who has already dl-ed it, just know that the shadows are available and work ok, but gives a hit (and does in general).

No arguments as far as further possible honing of the code, and setup. I would be interested to see someone who has more of a head start on this kind of code than me refine it more. This is totally using Apple's own example CL code and a large part of the basic setup, and simply reigning it in to work with a video feed without taking a gigantic dump.

One thing that was quite disturbing to me, was that I absolutely had to have this setup like this, rendering to an object first, doing the crop, etc. If I plug a video feed straight into the image input for the OpenCL, all hell breaks loose, even with blur to smooth vertices and cropping based off of the video's image size via the image dimensions patch (a typical CI/crop setup). Total freeze/wack-out. I also mistakenly miskeyed a 0 on width (with something like a 400~500 pixels as a width), and had the same thing happen.

I actually had my machine stalling on re-boot. I had to let it sit for a few minutes without power for it to not stall on boot after trying that one. That's why it's still getting rendered to this sprite first on the front end. If anything, I'd like to get rid of that step, but I'm not in the mood for "oh, is my computer now broken/fried?" quite yet. I'll give it another day :)

I used to have problems with external providers delivering pixel h/w and that flaking out in certain scenarios in Leopard, so I suspect this is more of the same. I'm guessing a still image could avoid being rendered first. Again, I haven't totally replicated this (save for the two accidental times) because of the heinous nature of the freeze/crash.

Oh I have not played withthe CL code (I cant run it at all), I was talking about my Rutt Etra example sorry! haha, this looks good though :) Is it faster than my RE?

Super curious. Would like to see it, if my fucking machine could fucking run OpenCL. Fuckers. That OpenCLDisableGLSharing whatever makes some things load but not others :(

From a strictly utilitarian perspective, it's hard to say if it makes more sense to use something like this, or to use a plugin and be able to have someone who is in 10.5 (or even 10.4 with another plugin version) be able to run it, potentially.

I feel like the fps on this rivals either method, but it's more inconsistent. The normals and grid res is directly related to the image pixel count, so in that regard, I guess it's not shabby. It can look pretty ridiculously "wet" with the resolution it can get (I didn't bother to do any half or quarter vertex count presets). With something like the Rutt or K3D, many times I run it at a kind of half resolution... I haven't done any real profiling of any sort, so I feel like I'm comparing apples and oranges even though they look very similar in end result.

It's pretty rad looking in the actual visual quality of it, and that the shadows pretty much work (this was a big YES for me), but the crashes when experimenting with the setup were nauseating. Almost the worst ever that I've had (on Apple products... I've had some REALLY funny and spectacular fritz-outs on Windows and BeOS tower systems... though BeOS was pretty solid in general). I wanted to lop out the whole render to destination part, but it was a no-go on my system. There was a bit of flickering involved on the stall, and things were frozen and flickering, Console was dead, it seemed like the computer was starting to really chug and possibly heat up, so I felt like I should just power it down. It failed to reboot twice. Freaky.

Besides whatever incompatibility issues with OpenCL you're having, or in addition to, are you able to run QC in 64 bit mode? I notice that some OpenCL stuff seriously goes crazy when I try to run in 32 bit mode, and I have a compatible GPU setup. I've already documented some heinous crashes and graphics tears just from trying to edit code in the kernel when in 32 bit mode, but I do notice that it extends to certain compositions causing QC or the whole system to become laggy, and gives you that "hit Stop while you still have a chance" feeling.

NOTE! ALL! Please be careful when doing displacement with video in OpenCL. Always, always, always, crop, and have that cropping be dependent on something other than the size of the video feed itself. Maybe this is just a one (or two) time thing, not sure.

i think open cl requires images that are square. which is weird cause the fluid patch seems to work no matter what image is attached.

What makes you say that? This gives a rectangular image on the input, for example.

i thought i had read that some where. i guess im trying to figure open CL but a major hurdle for me is that the default standard apple open CL patch crashes my computer. im not sure if its my computer or not i need some one to test it, but its like im not asking anybody to crash their computer for me. but this code.

__kernel void test_rgbaFFFF(__rd image2d_t srcimg, float x, __wr image2d_t dstimg) { int2 pos = (int2)(get_global_id(0), get_global_id(1)); float4 color = read_imagef(srcimg, CLK_ADDRESS_CLAMP_TO_EDGE | CLK_FILTER_NEAREST, pos); write_imagef(dstimg, pos, color*x); }

is an example in the default open CL kernel patch. all it does is multiply or fade an image. for what ever reason when i interpolate x my screen glitches for a second then it comes back to normal but everything is frozen with no spinning ball of death so i have to restart my computer like the error your getting with the non cropped video feed. if i don't let my computer sit for second when i switch to the 512 chip after re boot my computer gets a kernel panic. the error has something to do with the memory inside my geeforce card. i have sent the kernel panic error to apple, but im on the moderated qc list, and rarely do my questions, or answers ever get posted to the list. i guess thats what i get for going off topic. so some one else needs to report this if my graphics card is not defective.

like i said all im doing is attaching a screen shot to the input and billboard to the output of the standard open CL patch default example code. this has happened a few times with fluid sims for me as well. i just starting reading up on my cuda sdk in regards to fluid sims. im excited about parallel computing and want to get deeper into open CL but i can't have my computer crashing when i try and run the example default patch.

so here is the default open Cl patch with billboard, like i said be careful if you try and interpolate x or well change x all together. it crashes my machine.

maybe take a look at it see if im doing something wrong. maybe i need to crop the image maybe the image needs to a certain resolution.

any help in deciphering if my machine is defective or not would be great. i told my self i don't like to buy 1st gen anything mac and well went and bought a mbp 1st gen aluminum so maybe i do have a defective card i don't know.

can you confirm if this works george.

I know you asked George [GT] to respond about this, dust, but with the following plugins installed :-

Quartz Composer Patches:
   AppleRemotePatch.plugin
   AudioTools.plugin
   DirectoryScannerBlocking.plugin
   FileTools.plugin
   FreeboardPatch.plugin
   GLTools.plugin
   ImageParticlePatch.plugin
   Kineme3D.plugin
   MIDITools.plugin
   ParticleTools.plugin
   QuartzBuilderProtocol.plugin
   SpeechRecognition.plugin
   StructureTools.plugin
   TexturePatch.plugin
   ValueHistorian.plugin
   YUVColorPatch.plugin
 
Quartz Composer Plug-ins:
   ACProcessorSuite.plugin
   ask.plugin
   MatrixToParams.plugin
   qcOSC.plugin
   QCPhidgetLED.plugin
   SingleMarkerDetector.plugin
   v002AnalogGlitch.plugin

I get no Console errors derived from 64 bit QC with Open CL and in addition, your small demonstration item works just fine with Interpolation or LFO to provide the essential number input to change the Internal Texture Backing .

Check your Console to see if you have any really problematic plugins and / or Image Units.

I've already put in a bug report on the OpenCL kernel... sorry not going to open it, because I don't feel like crashing. If you follow the list you will see a discussion about this, and a pic I posted of a big graphics tear on the actual editor panel.

Bug ID (I'm not going to write rdar, whateva) - 7233925.

You're likely opening QC in 32bit mode( am I correct?). Try opening in 64 bit mode, on a standard install.

This is definitely a known bug, and one that I'm pretty sure is being taken seriously.

This is going to sound totally crazy and anal, but I would never try to confirm/disprove any bug in a system with ANY 3rd party plugins installed. If nothing else, grab Graphics folder, pull it, restart QC, and then test.

I would definitely look at the question of whether QC is running in 32 or 64 bit, as this was my problem scenario.

As well, even though some of the example CL code qtz's seemingly run ok in 32 bit, I recommend checking them out in 64 instead.

@ cybero thanks bud. this is good news and bad news i guess. i must have a defective or defective graphics cards.i can only do so much extensive testing when the bug im testing crashes my computer.

@ george i have never switched qc to 32 bit mode and i run with the 64bit kernel enabled. usually i run with my graphics card on 512 but when this was happening yesterday i was actually in 256 mode. upon a switch after a crash i got the kernel panic error. i was also using two monitors at the time. now this has happened every time i have tried the default patch. i just did a test again and ran my viewer in debug mode and nothing went wrong so it seems what ever is causing this bug is inherent to either the pcie bus or my 256 card.

so this brings up 2 questions. one what is the advantage to running qc in 32 bit mode ? and two after doing some research and stuff with c++ and cuda in regards to open cl. do i have to explicitly tell the kernel to run on both cards or does QC handle that for you. im only asking because in obj c and c++ there is a bunch of requisite set up that needs to be done before you write the kernel. am i supposed to when using QC to include the set up at the top of my kernel as a sort of global scope ?

Hey dust (sorry to kinda hijack the thread for a moment) -- you mentioned KPs with dual monitors. Have you noticed an increase in kernel panics when both monitors are plugged in?

I only ask because every time my MacBook (Intel GPU, so completely different hardware) has kernel panicked (except for once, when I had inferior memory installed) has been when I had 2 screens, with QC running on both (kinda taxing the machine)

It would be interesting to find if this is an across-the-board kind of problem (i.e. something with the OpenGL.framework, rather than the lower-level GPU drivers).

(speaking of Leopard, not SL)

Is there a reason you're using the 64bit kernel? I really don't know if that'll cause more problems than it solves (just curious).

qc in 32bit mode will use QT natively (in 64bit mode, it uses a QT background process, and has to share context information between processes -- a bit dodgy, but at least possible in SL). It will also improve compatibility with some plugins that haven't been completely tested in 64bit mode.

QC sorta handles running kernels on cards (as in, it takes control and doesn't let you pick), but I'm not sure if it divides the work across different GPUs or not (that's a hot question that hasn't been addressed yet, as far as I know). Since the kernels are executed serially, spreading across GPUs probably won't help (unless you're running 2 compositions at the same time in the same process).

gtoledo3 wrote:
This is going to sound totally crazy and anal, but I would never try to confirm/disprove any bug in a system with ANY 3rd party plugins installed. If nothing else, grab Graphics folder, pull it, restart QC, and then test.

well, not really, crazy or anal, in fact sounds like a good , clean and methodical approach, anyhow those 3rd party plugins listed provoke no error on my kit GT :-)

Quote:
I would definitely look at the question of whether QC is running in 32 or 64 bit, as this was my problem scenario.

As well, even though some of the example CL code qtz's seemingly run ok in 32 bit, I recommend checking them out in 64 instead.

good points too :-)

well i don't really have any reason to run in 64 bit enabled kernel mode other than my firmware EFI - is 64bit and i have the minimum requirements to gain maybe a possible increase in computing power. but like you had said before 64bit apps still run in 32bit mode and i can't honestly tell the difference because things are just way faster in snow leopard to begin with. although for today i have set my boot.plist to arch=x86_64 so i won't have to wonder what mode my computer is in. i have also done the same with my gpu kernel settings plist. this saves me having to log out when ever i want to use the 512 chip unless im running on battery in which case i would rather be on the 256 chip. i can't really tell the difference between the 512 or 256, except for when some programs will only run in 512. i think the adobe beta 64 is supposed to run faster in 64 enabled mode. but i really don't know.. some kids where telling me having more cores doesn't make difference the other day and that didn't seem right to me ?

dust wrote:
some kids where telling me having more cores doesn't make difference the other day and that didn't seem right to me ?

Having more cores only makes a real difference if the software has been coded to exploit each cpu core individually &/or concurrently.

dust wrote:
but i really don't know.. some kids where telling me having more cores doesn't make difference the other day and that didn't seem right to me ?

This depends -- there are certainly cases where more cores don't help.

For example, if your app is only single threaded (or, only uses 4 threads, for example), it will only ever use 1 (or 4) cores -- having more (8, 16, whatever) will do nothing for you.

Also, memory bandwidth is already very limited -- a single core can fully saturate the memory bus, which effectively starves the other cores (they can't read from or write to memory). In practice, L1, L2, and L3 caches will ensure that most cores can stay busy to some degree, but that has its limits. This will vary depending on the front side bus speed, cache sizes, and programs/memory usage (more memory used = more data outside of the cache = more bus contention).

There's finally Amdahl's law -- some tasks can only get parallelized so much. Not every task can be divided into 8, or 16, or 512 smaller units. Most programs in real life have some limitation, but also benefit to some degree from multithreading as well -- the actual amounts vary by workload, of course.

i read all of apples open cl programming guide which honestly seems little help with open cl in the QC context There is one example im still trying to understand in parallel computing although this is related to the cores and gpu units, it says or uses a a teachers grade book as an example. the problem is the classic student example of averaging grades. the documentation says that although the class average can not be computed until the individual students grades are computed the process still can be run in parallel. i mean i can understand blocking out or initializing a sector of memory in a parallel context dynamically that waits for one process to dispatched from the other core and gpu units but how is this even possible to parallel two processes that are dependent upon the state change another process.

No worries Chris. The thread already went OT, long, long ago.

I'm still trying to figure out when exactly it is that OpenCL won't take a rectangular input (re:the orig OT post).

Nice demo, works absolutely great on my MBpro with GF8600M GT.

I've got some serious problems running OpenCL om my new iMac 21.5 with Radeon HD 4670 though. All of the OpenCL enabled patches run on CPU! The OpenCL Context Info patch doesn't even report the GFX card, just refers to CL_DEVICE_CPU being in use for OpenCL tasks. Anyone else having this problem with the new iMac?