PixelS using OpenCL

M.Oostrik's picture

Hi All

Looking around at the forum I still see people mentioning / using my old PixelS plugin.

For those who still use it I made a openCL version with (almost) the same functionality. Pretty basic CL code, but I guess not everybody is into it. Almost as in I replaced the "RGB Average" function with "Luminance" for a better result.

If there's anyone who for some reason still prefers the old Plugin with this "luminance" functionality, let me know and i will start searching for the source code for the original plugin. It should be somewhere around.

Cheers! Matthias

PreviewAttachmentSize
PixelS CL.qtz26.92 KB

toneburst's picture
Re: PixelS using OpenCL

It might be worth updating it, if only for those who don't have machines that can run OpenCL. Also, OCL in Quartz Composer is notoriously flakey and crash-prone, so an alternative method of getting an array of pixel values is always going to be useful, at least until OpenCL is more reliable.

a|x

gtoledo3's picture
Re: PixelS using OpenCL

Humbly disagree on the "notoriously flakey and crash-prone," and I've said the same thing. Seriously.

I was under the same impression until I realized that pretty much every crash I ever get is because of user error, mostly from not dealing with work-size correctly, or trying to manipulate it in runtime (a no go, and understandably so). You're entitled to your opinion of course!

Editing the kernel used to have some problems when in 32 bit mode, selecting all, and hitting delete. This seems fixed.

I've been using OpenCL for "ImagePixelS" type function, and have been way more happy with it.

toneburst's picture
Re: PixelS using OpenCL

It's still fairly flakey for me, in various ways. Anyway, if you can do something in a patch that crashes you entire computer, irrespective of if it's user error or not, that counts as flakey, in my book.

a|x

gtoledo3's picture
Re: PixelS using OpenCL

I don't disagree with the premise that it is a major drag to have your computer go down.

I feel like it's the idea that we need to be safe-guarded from various things that has hobbled QC a bit. Geometry shaders come to mind - we could theoretically misuse them by placing a renderer inside the environment that doesn't apply to the code, and then corrupt state. So, no geometry shaders.

I don't want the fact that something can be misused, and screw things up, to keep me from being able to access said features.

The way I view it, if I setup something that is supposed to be executing in parallel, and make one of the structures the wrong size, etc., it's on me. Do I wish it wouldn't freeze my computer, and do I think it could be handled more eloquently? Sure. The performance differences between OpenCL and other methods are non-trivial though. So, I would rather just suck it up, use it within the realms that do work, and benefit.

I don't personally find any scenarios where something works kinda some of the time, and then not others. That would constitute full on flaky to me. Every "problem" I've run into with OpenCL has been totally predictable

I was just figuring out something last night where I was taking in a 640x480 and creating 8 vectors for each pixel, sorting, rendering, and getting 60fps. I can't think of the last time I did that with anything else in QC, with such performance. For me, it's been well worth the countless hours staring at the OpenCL quick sheet, and working through tutorials.

Have I been aggravated when I've made my monitor turn into a dance party by hitting backspace accidentally while a kernel is executing, and making my GPU barf? Sure.

I'm not sure that one could expect to edit a line in a plugin on the fly, while stuff is executing (if this was possible) without stuff crapping out, so I'm not sure about the OpenCL kernel either. What's supposed to happen when you're running, and it can't execute? Is the viewer just supposed to shut off, or give you a warning or something? My feeling is that one can just make sure to not have the Viewer on.

(For record, I think that it likely could work to have some detection for when the CL kernel is made incomplete/wrong during runtime, and shut stuff down. Not saying it wouldn't be nice or desirable.)

M.Oostrik's picture
Re: PixelS using OpenCL

Guess you're right. Om my MacPro without a OpenCl capable video card, the PixelS CL is not reliable with arbitrary image dimensions (although much faster). On my Hackintosh (10.6.2) with a GTS 250 it is stable so far.

Still i try to use as little openCL as possible for my installations. Experience tells me an OpenCL composition will crash at one point in time, ranging from a minute till a couple of hours.

I'll start looking for the source, hope i can find it

franz's picture
Re: PixelS using OpenCL

Thanks for the post. However, mousing over the output structure port raises an exception. I assume it is an openCL bug ....

gtoledo3's picture
Re: PixelS using OpenCL

That was definitely an editor bug with one of the builds. I remember that one... I think I asked about it on list. It doesn't happen to me with the most current OS X release (not to say it won't happen on your system).

gtoledo3's picture
Re: PixelS using OpenCL

Does that mean that it's not stable when you start feeding it different images, one after another? (re: the comment about arbitrary dimensions)

"Experience tells me an OpenCL composition will crash at one point in time, ranging from a minute till a couple of hours."

If that happens, you should consider posting the compositions, filing bugs, and/or reporting to the community in general.

I've had compositions that use OpenCL running for days. I'm really not trying to be contrary, I'm just finding the statements floating around have no actual substantiation/code attached. If there were specifics, we could solve these problems, or maybe get bug fixes if there are legitimate bugs.

What is it that you do that leads up to, or causes this to crash? Do you just have it running, and then it crashes? Do you manipulate some parameter, and then it crashes?

Why are you specifying the compute device on the kernel?

Also, for reference, all of my comments re: stability/lack of stability, are in regards to the nVidia 9600 or 9400, in the context of QC running at 64bit, Mac OS X 10.6.5 (10H574). I wouldn't be surprised to see a lack of consistent results depending on GPU or OS version at all... (or editor mods/plugins/etc.)

M.Oostrik's picture
Re: PixelS using OpenCL

Quote:
Does that mean that it's not stable when you start feeding it different images, one after another? (re: the comment about arbitrary dimensions).

No, on my MacPro (2007, X1900, 10.6.5) Some dimensions, especially those with odd numbers will result in the output image have some kind of strange offset that result in an diagonal image. This problem occurs with a lot of openCL patches on this Mac.

Quote:
"Experience tells me an OpenCL composition will crash at one point in time, ranging from a minute till a couple of hours." If that happens, you should consider posting the compositions, filing bugs, and/or reporting to the community in general.

My statement was more from experience that fact, but you're right. If only i could find the time... sigh...

Quote:
I've had compositions that use OpenCL running for days.
I have to admit, me too...

M.Oostrik's picture
Re: PixelS using OpenCL: PixelS2

Oke here it is:

Zip contains:

  • PixelS2 plugin
  • Source Code (Xcode)
  • Example Comp with Plugin and OpenCL

I added the Xcode Project for those of you who want to check if it is possible to improve the code, please let me know if so. I'd like to learn from you guys. Also feel free to use the code for other purposes if you like. If I remember correctly the code was originally based on Apple's optical flow plugin example.

Also I will add the new plugin to my site

PreviewAttachmentSize
IPS2.zip67.21 KB

franz's picture
Re: PixelS using OpenCL: PixelS2

you're using a CFNumber to get the RGB values. Isn't it faster to just use a float or a double ?

In my plugins, I use, for instance:

float r = baseAddress[4* x+y * floatsPerRow];

M.Oostrik's picture
Re: PixelS using OpenCL: PixelS2

Yea, thought that one looked kinda ugly

But if the "mono'' float is added to the monoArray it gives a "Incompatible type" error...

I'm a novice if it come to Xcode and Objective-C. This solution worked, but if there's a better way lemmeknow!

dust's picture
Re: PixelS using OpenCL: PixelS2

i will have to agree with george here. i think 9 times out of 10 when CL crashes for me it is user error. that is to not say Cl wasn't flakey for me. at first i couldn't run the example kernel without crashing in 10.6.0... 10.6.2 completely disabled all things qc for me but with this new system i notice far less crashes.

now that i define my global workgroups and output sizes and do not let qc automatically make these choices for me i hardly ever crash. i can even edit my code on the fly in execution without fear of going down. if i make a wrong statement i just get a debug error but no crash if every thing is set up right. however i'm still scared to change the viewer size if i'm using render dimension to define my sizes on the fly. i think if using a variable resolution not tied to your screen size is ok though.

so i must i am much happier now that i have figured this out as sometimes it was very painful to stop execution change code start again stop, start, crash, restart, crash, stop start. this process was very off putting, but now i'm glad my determination and exploration into open CL has brought me to these conclusions as i feel better that it was mostly me making mistakes rather than my system being f'up.

dust's picture
Re: PixelS using OpenCL

i have to agree with george about user error but tb also has point where your whole system shouldn't crash whether user or kernel bug error.

i have not tried this yet in a qc kernel but maybe its possible to to query a cl object with clGetMemObjectInfo then make use of that data and do a clFlush or clFinish to clear the buffer if your running out of gpu memory. i should experiment as i think this might keep your system from crashing completely.