OpenCL Boids (Composition by M.Oostrik)

Author: M.Oostrik
License: (unknown)
Date: 2010.12.18
Compatibility: 10.6
Categories:
Required plugins:
(none)

---UPDATE 2.2---

  • fixed crash on changing boid or tail count
  • updated boid system so it makes more sense (at least to me ;)
  • cleaned up code and patch knots
  • dramatic increase of initiation time
  • (re)introduced some parameters

---UPDATE 2.1---

  • textured tails

Contributions by George Toledo.

  • correct function for line to triangle strip conversion
  • memory fence implementation (barrier(CLK_LOCAL_MEM_FENCE)

The purpose of this project was to get a better insight in OpenCL, it worked! For now i will work on other stuff, but in the future there will be new versions.

---ORIGINAL POST (2.0) ---

Dust and I were working on boids some months ago for a generative artwork. I got distracted by other projects, but recently i had some time to spare, so i decided to rewrite the code for the purpose of sharing. Here it is...

Sources:

  • The current Boid system is based on this C++ code by Christopher Kline.
  • My research started with this page from Conrad Parker. -Inspired by this demo. The inputs are very understandable and easy to handle.

Contributions by George Toledo.

  • GLpointstructure is replaced by a mesh renderer
  • Boids in trackball for superior visuals

PreviewAttachmentSize
boids1.jpg
boids1.jpg458.15 KB
boids2.jpg
boids2.jpg306.4 KB
boids3.jpg
boids3.jpg423.14 KB
BoidsK 2.2.qtz76.02 KB

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

gtoledo3's picture
Re: OpenCL Boids (Composition by M.Oostrik)

Sweet; only looked at it 5 seconds so far - note: one can get a tremendous amount more points if you render with the mesh creator/mesh renderer. The GL Tools is a bog.

edit- Huh, when I hook up a point sprite renderer, I don't get any result! Weird. Maybe I'm having a senile moment...

Nice stuff though.

M.Oostrik's picture
Re: OpenCL Boids (Composition by M.Oostrik)

Thanx!

"render with the mesh creator/mesh renderer"

I remember seeing Dust doing that all the time. Never got into it though, is this simple to do?

Cheers

gtoledo3's picture
Re: OpenCL Boids (Composition by M.Oostrik)

Yeah....

...but I see that your code makes W=0, which makes one not be able to "see" the verts. I was trying to mock this up for you, and only realized this a minute or two ago.

When I change W=1 in the initial coord javascript, it makes things run really slow and I'm not sure why. That seems like the easy fix, but it sure doesn't make things speedy at all.

I was looking at just changing it in your CL code... changing it somewhere along the kernel, or making stuff work on a float 3, and then popping in the needed w=1 value at the end, making a float4, but I'm not ultra familiar with the code.

I made a color calc, making all particles white, but realized that w still needs to equal 1 (and hopefully, not by orig javascript value, because like I said, wow it makes things slow).

Maybe making the w value 1 in the initial javascript makes some additional maths happen that don't technically need to.

I also see a for loop... it's possible it could work faster if it was "unrolled", but maybe not.

M.Oostrik's picture
Re: OpenCL Boids (Composition by M.Oostrik)

When w = 1 a lot of calculations will probably not work correctly, had that problem before. I understand why but can't explain shortly...

A simple workaround would be an extra CL patch between the 'pos' output and the mesh:

__kernel void main(__global const float4 *src, __global float4 *dst) { int tid = get_global_id(0); float4 s = src[tid]; s[3] = 1.f; dst[tid] = s; }

PreviewAttachmentSize
wto1.qtz1004 bytes

M.Oostrik's picture
Re: OpenCL Boids (Composition by M.Oostrik)

Got the mesh working, much faster indeed! thanx

gtoledo3's picture
Re: OpenCL Boids (Composition by M.Oostrik)

I ended up doing this;

__kernel void vecWeight(__global float4 *inputSrc, float4 inputPos, __global float4 *outputDst)
{
   int     tid = get_global_id(0);
   float4    v;
 
   v = inputSrc[tid];
 
    {
      v.xyzw = v.xyzw + (inputPos);
    } 
 
   outputDst[tid] = v;
}

This allows one to weight W, or translate x/y/z. (I figured I may as well give myself "handles" to every vector... I guess that could be handled by the render patch though)

I decided the extra kernel route, b/c it seems like changing your main kernel to output a 1 screws up the feedback loop/equation, because 1 convolutes the boid equation, the way it is setup. That's avoidable, but a bigger pain to mod.

PreviewAttachmentSize
BoidsK w vector weight.qtz51.37 KB

gtoledo3's picture
Re: OpenCL Boids (Composition by M.Oostrik)

Great, no problem! Nice composition.

I like the visual quality of what's going on quite a bit.

dust's picture
Re: OpenCL Boids (Composition by M.Oostrik)

nice when I get chance to download this I will, traveling at the moment. I don't remember what I did to get the mesh creator working. I think I used a model for initial vertex data then added input for mouse as center of flock.

goto10's picture
Re: OpenCL Boids (Composition by M.Oostrik)

For me this is the one reason to finally upgrade to 10.6. Thanks so much for sharing this.

gtoledo3's picture
Re: OpenCL Boids (Composition by M.Oostrik)

I've been having fun with this tweak on it.

I've added an iterator motion blur setup, and some memory fences to the kernel. The memory fences seem to solve a slow/quick performance issue I was having. There are some that I added past the point of it solving my problem, that are probably unneeded, but since they didn't hurt execution or slow things down (in QC), I kept them in.

All of the caveats about not changing particle count in runtime from the original stand. No warranties...

PreviewAttachmentSize
boids.qtz67.79 KB

photonal's picture
Re: OpenCL Boids (Composition by M.Oostrik)

wow that is a stunning comp!!

offonoll's picture
Re: OpenCL Boids (Composition by M.Oostrik)

Beautiful!!!! Nice work George!!

cybero's picture
Re: OpenCL Boids (Composition by M.Oostrik)

Neat & useful catch on the memory traps. I wonder how responsive the Weight/Translate inputs could be - :-). Works brilliantly.

M.Oostrik's picture
Re: OpenCL Boids (Composition by M.Oostrik)

"The memory fences seem to solve a slow/quick performance issue I was having."

Wat does this barrier(CLK_LOCAL_MEM_FENCE) do exactly? Has smoother performance indeed!

cybero's picture
Re: OpenCL Boids (Composition by M.Oostrik)

It's a code command that ensures all work-items inside a workgroup stop at that declared memory barrier before running any more of the kernel. For that reason , it should not be used within a crucial function chain that would cause a lack of processing of the rest of the kernel. Typically it is used to ensure that a particular calculation / result of a sub routine is correct before handing it on.

Basically unless a prior set of instructions has been processed, all else stops. thus nil resources called upon .

gtoledo3's picture
Re: OpenCL Boids (Composition by M.Oostrik)

My intent in using it was to make sure that all of the array/threads are already executed and available to work on before the next step starts executing. With all of the conditional statements, and the feedback loop, I thought it would be worth looking into.

gtoledo3's picture
Re: OpenCL Boids (Composition by M.Oostrik)

"...it should not be used within a crucial function chain that would cause a lack of processing of the rest of the kernel. "

I'm not questioning that, but where is that info from? I would like to see more info. I'd like to understand more about the aspect of when one should not use it, or what "crucial function chain" means.

I've thought of it as making sure something is finished, and in doing so, synching events, like cuda synch.

cybero's picture
Re: OpenCL Boids (Composition by M.Oostrik)

Where I got my information from

Synchronization and Explicit Memory Fence Built-in Functions [6.11.9, 6.11.10] 
The flags argument specifies the memory address space and can be set to a combination of CLK_LOCAL_MEM_FENCE and CLK_GLOBAL_MEM_FENCE.
void barrier ( cl_mem_fence_flags flags)
void mem_fence ( cl_mem_fence_flags flags)
void read_mem_fence ( cl_mem_fence_flags flags)
void write_mem_fence ( cl_mem_fence_flags flags)
All work-items in a work-group must execute this before any can continue
Orders loads and stores of a work- item executing a kernel
Orders memory loads 
Orders memory stores

@ http://www.khronos.org/files/opencl-quick-reference-card.pdf

&

@ http://www.macresearch.org/files/opencl/Episode_6.pdf

&

http://www.cmsoft.com.br/index.php?option=com_content&view=category&layo...

definitely worth looking into :-)

a good example of when not to use is to be found at the cmsoft link

kernel void example(global float * x)
{
   int i = get_global_id(0);
   if (i==0)  barrier(CLK_LOCAL_MEM_FENCE);
   else x[i] = i;
}

which would deadlock as work item 0 will not proceed until all others reach the barrier - which they won't ever do.

Basically synchronizes local memory IO and the work-item execution, the mac research slides are a good visual on that.

M.Oostrik's picture
Re: OpenCL Boids (Composition by M.Oostrik)

I am working on a similar trail as George, but using OpenCL (again ;)

It is using an OpenCL patch that stores the former values to create the tail and a line strip mesh render. A javascript gives the lines between the boids an alpha value of 0.

I'm not totally happy with the mesh render, because a the Vertices the color overlaps.

Is there a way to smooth this out?

Is this a good approach in general?

btw I got rid of the bounding box and created a bounding radius. chancing the tail length has the same problem as chancing the number of boids. So try not to do it while running the comp

PreviewAttachmentSize
BoidsWithTails.qtz36.3 KB
Screen shot 2010-12-21 at 19.32.54 .png
Screen shot 2010-12-21 at 19.32.54 .png177.08 KB

gtoledo3's picture
Re: OpenCL Boids (Composition by M.Oostrik)

Oh, ok. I've read all of those materials.

I was getting tripped up on semantics, and reading something slightly different into it from word choice. Cool, thanks.

Now that I see the example of what is meant by how not to use, it becomes obvious what is meant. I wasn't thinking in terms of "oh, set something up where the condition could never be met and that's when not to use it". At least it's obvious :)

Dude! I hate (overstatement) how powepoint slides have somehow taken the place of whitepapers when it comes to OpenCL. I've seen so many diagrams of boxes fitting into more boxes...blarrrgh.... with ultra trivial examples.

Sometimes I get sort of irritated at the syntax/whoever made this stuff up. Converting image data back and forth should be easier.... I want to be able to do arbitrary amounts of conversions back and forth within the kernel, and I don't see real technical reasons for that not being possible.

I'm drifting OT, but I also wish I could find more info about setting up kernels to take advantage of event functions. It's something I guess I'm just going to have to tear into by trial and error.

M.Oostrik's picture
Re: OpenCL Boids (Composition by M.Oostrik)

That's why i like QC so, trail and error, and then see it work!

the quick reference card is my CL bible!

gtoledo3's picture
Re: OpenCL Boids (Composition by M.Oostrik)

I've looked at this like 20 seconds... looking slick. But, I don't have that overlap look that you're saying is problematic (I think). Do you have Multisampling enabled in QC Editor private options (I do, so maybe this is eliminating that look for me...).

I don't know if those lines will respond to the Fog without normals (they may... QC mesh has surprised me before.)

M.Oostrik's picture
Re: OpenCL Boids (Composition by M.Oostrik)

holding the option key while selecting "Preferences"

problem solved!

M.Oostrik's picture
Re: OpenCL Boids (Composition by M.Oostrik)

"Do you have Multisampling enabled in QC Editor private options"

First time I hear of this one. How would i do that?

The fog renders well for me. I think i have to dive deeper into this mesh thing before i continue though.

gtoledo3's picture
Re: OpenCL Boids (Composition by M.Oostrik)

Great! I was thinking "man, if this isn't MSA, we've got a weirdo GPU/mystery bug". It's good that it's MSA, for sure...but it means that's what it's going to look like if we pop the mesh renderer in RII :( However, maybe we could texture it or something (haven't thought about it too much).

The variable length thing on the tail is the reason I used the method I did, which doesn't draw strips technically, but can get that look if point size and the motion blur are adjusted.

On that "readjust particle amount on the fly"... globals are going to be held by the kernel across runs (initializations of the kernel). So, even if you turn the renderer off (the renderer patch,not meaning QC Viewer), change size, and reinitialize, the kernel still has this mass of info that it's held onto.

Right now, one feeds it a different worksize than it had last frame, and it has nothing valid to act on anymore. The data needs to be flushed, and the kernel needs to basically restart (I'm thinking).

I'm pretty darn sure there is a way to do something like, reduce work size to 0, have that flush the old crap (right now, the kernel still holds onto the old worksize when you give it 0), and then start up again while everything is in run, with a new work size, without crashing the computer.... or have a memory function flush out the old data everytime another value changes.

There aren't any real examples of this (that I've found/realized I've found), as the "vary structure count on the fly" seems to actually be something that isn't a totally big deal for tons of uses (apparently), the same way it is important for us.

I've been wondering if by invoking a new "event" everytime worksize changes, if this can be achieved more eloquently. It's something that has been rattling around the back of my mind for awhile now, as to the most technically correct way to go about it.

gtoledo3's picture
Re: OpenCL Boids (Composition by M.Oostrik)

I was looking...

Right now, the splitter for tail length is a number splitter - that can make the whole comp crash, even when stopping/starting, because tail length must be an index. So, tail length = 4.1 = crash.

I see that you want to cap off the indices starting at 3 though... it's probably easiest to add an extra splitter set to index between the published splitter and port, like in the attachment. This way, it doesn't matter if someone sets tail length to a non-integer, no crash, because the extra splitter is converting your values to integer. (all caveats about not changing during run still apply, of course)

also... I had this (the other attachment) already around before your last post with the tails. This added in some mouse influence by manipulating vertices in the feedback loop after the main kernel, but before the return. I started popping it into your new one, and it works fine... I think the box bounds kind of show the effect in an interesting way though.

toneburst's picture
Re: OpenCL Boids (Composition by M.Oostrik)

There are other ways of rounding a float to an int, too. There's the Round patch, that gives rounded, floored (rounded-down) or ceilinged (rounded-up) outputs, and there's also the ever-useful Mathematical Expression patch, where you can use

floor(input) or ceil(input)

a|x

gtoledo3's picture
Re: OpenCL Boids (Composition by M.Oostrik)

For sure... I always feel sort of bad mucking in people's compositions! So, if I do, I try to do it as unobtrusively and with the least introduction of extra ports to evaluate as possible.

So, if I place a insert splitter in between, I have one port in/one out, and the conversion happens. This can be the case with the math patch as well, but I'm guessing (I may be mistaken) that QC's built in conversion is probably quickest, evaluation-wise (however microscopic of a difference that may be). For the round patch, there are more ports to evaluate (again, totally microscopic).

What would probably be best is to have taken the published input and change to index, but that would remove the nifty slider. There is another insert splitter inside of the main boid macro that could have been replaced with an index splitter... I would probably do that, but I think it's m.oostrik's call. I was also thinking that a floor value might be appropriate. I feel 50/50 about it. (I feel like such a dork getting so detail oriented about such minutia.) I might make a little panel that showed all of the current values in the Viewer.

It might be fun to do an onscreen GUI, because then one could just keep people from manipulating stuff that shouldn't be manipulated in runtime (work size stuff).

One thing I found that was kinda weird... I took that setup I posted with the iterated mesh/queue/trail thing, and put it all in a textured vertex shader; worked fine (though, it's kind of stupid, since I could just use OpenCL for noise, and probably keep it all faster).

Then, I thought, let me check out this line patch that m.oostrik posted last night...I can't get it to render in the same GLSL! I'm miffed. It evaluates, but all is blank (tooltips show mesh). Maybe it's an issue with line renderer mode... GL points usually work w/ GLSL fine, so maybe that's what I'm running into.

Then, one throws it in the Lighting patch and is reminded at the shadow algo's un-userfriendliness sometimes. I wish it would ignore alpha color. Instead, if you flip on shadows, one sees shadows cast on all of the parts of the lines that should be invisible.

This is really a fun composition, and I've been having fun manipulating the feedback loop with "black hole" kernels, and some other weird stuff - that round right before it goes back into boids is ripe for play (where I put that little transform/weight in one of my uploads). I've been having a lot of fun getting these long light streaks...

PreviewAttachmentSize
b1.png
b1.png319.31 KB
b3.png
b3.png414.54 KB

M.Oostrik's picture
Re: OpenCL Boids (Composition by M.Oostrik)

something went wrong with this post...

M.Oostrik's picture
Re: OpenCL Boids (Composition by M.Oostrik)

Textures it is

couldn't get nice textures for the line strip so i did another openCL conversion. This time into triangle strips.

still haven't found a solution for the worksize problem. (kinda hoping it's a bug that will disappear in future versions of QC / OpenCL)

I'm thinking of making a similar texture as this classic by Rui Madeira http://www.vimeo.com/1189857 any suggestions?

also i have a problem with creating the strips, the triangles keep flipping around on me. See the attached Mesh Test Comp. Is there a simple solution for this?

PreviewAttachmentSize
Fertile Boids.png
Fertile Boids.png930.12 KB
BoidsWithTriangleTails.qtz50.07 KB
Mesh Problem.png
Mesh Problem.png50.98 KB
Mesh Test.qtz32.04 KB

gtoledo3's picture
Re: OpenCL Boids (Composition by M.Oostrik)

OpenCL doesn't have support for dynamic array size. So, I don't think this is really a QC problem.

I think we are supposed to be doing something to stop the kernel, then, we are supposed to do something to re-initialize at a different work size, but flush the old info.

What seems like it should work to me, is this:

-Stop renderer.

-Make work size 0.

-Start Renderer.

-This flushes out old info from kernel.

-Make work size whatever, no crash.

However, making work size 0 keeps all of the old info in the kernel. I'm not sure if that's correct or not (it may be that global values are supposed to store across runs even if work size reduces to 0, but I think I read something that says it's not supposed to. I'm unsure, and I guess I should check.)

dust's picture
Re: OpenCL Boids (Composition by M.Oostrik)

here modified boidz that follows the mouse... working on making the boids collide with models at the moment.

PreviewAttachmentSize
boids follow mouse.qtz83.61 KB

gtoledo3's picture
Re: OpenCL Boids (Composition by M.Oostrik)

Ok... I looked at the "mesh problem"...

In the context of the last qtz, with all of the boids moving around, it's actually really hard for me to see it going awry. It looks ok. In the context of the mesh problem/mesh test.qtz the problem is obvious to see, as far as the triangles not drawing correctly.

I haven't tested it extensively...

It looks like you needed to be getting the dot product instead of the cross product to get the triangles drawing correctly. Check the attachment. It looks like it's working ok to me.... after thinking about it, I'm pretty darn sure this is correct.

I would put "mesh fix?" with the file names, but the question marks might mess up dl's/file management (?).

gtoledo3's picture
Re: OpenCL Boids (Composition by M.Oostrik)

I hope it ends up being satisfactory to you (the mesh fix)... it been in the back of my mind for a couple days now, and I was pretty jazzed to look at it late last night and get it drawing right!

gtoledo3's picture
Re: OpenCL Boids (Composition by M.Oostrik)

That is interesting...

It looks like by adjusting flock centering by x/y and then doing

flockCentering = normalize(flockCentre-oldPos) * FlockForce;

It winds up really similar to the modification I do after the kernel in function ( I believe), and send back to the boid kernel through feedback, but somehow your upload breaks the bounds bounce effect... (I think/ I'm not sure why yet).

Instead of bouncing, the boids just keep looping around... so, if mouse is neg X, the boids drift there, and keep drifting, until they wrap around the side of the screen, and come back, regardless of the bounds being enabled or not.

It looks like it is adjusting the center, but the center of where the boids scene is... so it may be making the scene wrap(?). I'm unsure about that, but I'm eager to look at it more tomorrow when I'm fresh.

It might make sense to incorporate the queue structure/number in parallel for mouse influence, since it instantly populates a structure of X indices (no fill time that I know of), and is sort of ripe for preparing a struct of mouse coordinates to mix in with another structure. Kinda thinking about it...

dust's picture
Re: OpenCL Boids (Composition by M.Oostrik)

if you for instance;

put inside the loop oldpos.x = mouse x, flockcenter.x += oldpos.x etc....

then instead of following the mouse your mouse sort of drops boidz in its location.

i kind of like how the boidz will continue in the same direction on the opposite side once the border has been hit. this was unintentional although it was talked about before as addition.

I thought about doing a mouse queue instead of scalar input but I think to do it right your queue size would need to be the same as all bodies which might make things slow but could make painting bodies possible. it's worth a try.

gtoledo3's picture
Re: OpenCL Boids (Composition by M.Oostrik)

Ah, sure that makes sense. Right now, it sort of globally moves the mass, which sort of amazingly (to me), end up being really similar to that little vector weight thing I put after the kernel. Since the vector weight is after the main kernel, it automatically acts in line with the bounds dictated by the boids kernel. I just thought that was interesting (to me, but it's ultra obvious, if one thinks it out).

I really like that function you have going where the boids wrap around the space as well... but I think it needs to be figured out how to keep it and not break the bounds effect if desired (on my comp, the bounds no longer work at all after that introduction... well, that's what I thought at 3am last night when I was looking!).

... on the mouse queue thing - pllllllease note I'm not talking about the normal queue - won't work in a million years :) The queue structure in parallel (or queue number in parallel)... works, in parallel. It instantly populates with however many values it needs to, to fulfill the needed size of the kernel. It shouldn't be slow at all.

The aurora qtz works off of that principle ...pumping in a structure of single elements that decimate to a vec4 when they hit the mesh creator... really interesting conversion happening there that is worth noting. When you hit a mesh creator with a single lane structure, it turns indices 0~3 into a vec4 and so on. The CL queue in parallel stuff fills instantly (if it didn't everything would crash/not run at all).

dust's picture
artificial life dance

here is a simple al trail being controlled by the peak amplitude. i have the reset set to be triggered at a certain amplitude which helps drive the animation otherwise the boids will just end up chasing them selfs in a circle type of motion a min or so in. the audio is an early un mixed track i'm making.

PreviewAttachmentSize
alifetrail.qtz64.88 KB

cybero's picture
Re: artificial life dance

That's a nice use of conditionals on the peak level. I think I'll make use of this in my final xmas light's mix. got lots of possibilities.

I find that if I automatically allow global dimensions to be reset then the trail length value can be varied without resulting in a flickering OpenCL / GPU crash.

I'm also finding it necessary to retweak how the conditionals work, but that's just to allow for more frequent resets and switching of the index.

dust's picture
Re: artificial life dance

yeah the conditionals would need to be re tweaked on a track by track basis. the amplitude is just modulating the parameters. i didn't add any new parameters to this one. i have tried the mouse follow, i have used the spectrum to create the boids, i think next i'm going to output the centre flock position to use with a gl look patch.

M.Oostrik's picture
Re: OpenCL Boids (Composition by M.Oostrik)

Wow, never thought it could be such a simple solution! Would have taken a long time to figure that one out myself. Thanx

M.Oostrik's picture
UPDATE OpenCL Boids 2 (Composition by M.Oostrik)

Updated the comp!

the boids have tails with textures.

have fun!

dust's picture
Re: UPDATE OpenCL Boids 2 (Composition by M.Oostrik)

looking really nice ties. was just thinking about this project while doing some n-body simulations for a school project that look similar to the boids particles.

cybero's picture
Re: UPDATE OpenCL Boids 2 (Composition by M.Oostrik)

Really beautiful rendering results.

The kernels are going to reward some serious study.

I do find that changing values on the fly or pressing the reset control can result in one of those terminal graphic flicker crashes. I even got some weird debug information [inconsistently BTW]

22:06:51.295 ["Render in Image" @ "(null)"] > Cannot create node of class "KinemeColorYUVPatch" and identifier "(null)"
22:06:51.307 ["Render in Image" @ "(null)"] > Cannot create connection from ["outputV" @ "KinemeColorYUVPatch_1"] to ["BayerIntensity" @ "Patch_3"]

I really don't see where that came from, like what Kineme YUV patch or Bayer Intensity CI within your composition?

Whatever, one thing I was wondering about was if it really would make a difference to the texture macro and the composition overall to have the Native Pixel format as anything other than (null)?

I have found that feeding other images of same size via multiplexer gives some nice results.

I also get fewer crashes with that, although that is with a copy of your comp that I've disengaged the reset button from.

M.Oostrik's picture
Re: UPDATE OpenCL Boids 2 (Composition by M.Oostrik)

YUV patch and Bayer thing have nothing to do with the comp (lol). But be careful indeed with changing the first two values (Count en Tail Segments) They change the Global Work Size of the OpenCL patches and for some reason QC can't handle that (see discussion above)

I have found no difference using a multiplexer or different pixel formats. What are the nice results you speak of?

Fixed the reset button (I think)

cybero's picture
Re: UPDATE OpenCL Boids 2 (Composition by M.Oostrik)

Just the colouration of the rendered Mesh, and how that can change the look and feel of those boids:-) is the primary utility value of a varying texture multiplexer.

Regards the odd debug information, I'm left puzzled indeed, possibly something left from an uncleared crash on my machine?

Regards the Reset - debugs clean as a whistle in the resulting debug tracker & works like a charm regards recommencing the processing of data.

What a really good example of development, this would , from start to finish, version after version, make for an excellent example for an online tutorial evidencing the potential pitfalls of OpenCL development and how to successfully overcome many of them.

Brilliant :-).

cybero's picture
Re: OpenCL Boids (Composition by M.Oostrik)

I'm really liking the way that one can also get the structures from the Positions and Velocities too.

idlefon's picture
Re: UPDATE OpenCL Boids 2 (Composition by M.Oostrik)

Thanks a lot!! This is a great composition and a marvelous OpenCL learning source!

gtoledo3's picture
Re: UPDATE OpenCL Boids 2 (Composition by M.Oostrik)

That always could have been from finder, quicklookd, or something, if it was console info. If quicklookd couldn't spawn a thumbnail or something, one will get those warnings. There's not too many qtz's bumping around in public that use YUV. Hough lines...

M.Oostrik's picture
UPDATE: OpenCL Boids 2.2

fixed the crashes on boid and tail count, by resetting the feedback structures.

For more changes read the top topic.

cheers!

marcofilipevieira's picture
Re: artificial life dance

Hi dust, when I tried to open your composition I had an error message: 20:23:23.119 [""tails"" @ "Tails"] > Execution failed at time 0.000

What's wrong? =/

marcofilipevieira's picture
Re: OpenCL Boids (Composition by M.Oostrik)

I can't open the OpenCL Boids. I don't know why. :( I get this error: 20:32:50.955 ["TriangleStrip Colors (CL)" @ "TriangeStripTails"] > Execution failed at time 100.789

Can someone help me? I would like to see this composition, it looks really good.

cybero's picture
Re: OpenCL Boids (Composition by M.Oostrik)

Are you running 10.6.x or 10.7.x, if the latter , then the code of the kernels in the posted composition needs a rewrite to work in Lion.

If you are running the composition BoidsK 2.2_0.qtz then this has a fault in its kernel code in Lion. You could try M.Oostrik's BoidsWithTriangleTails_0.qtz which is posted a little further down the same page from the original composition that worked just fine in Snow, the reason for that being that the OpenCL kernel compiler did not act as strictly as that installed in Lion.

There are other variants too on this page, by dust and gtoledo that also work in Lion.

cybero's picture
Re: artificial life dance

My guess is that you haven't provided the one thing that composition really needs, which is a valid path to an audio file hosted locally upon your local disk drives. Try fixing that, assuming you have Kineme Audio Tools installed then all should work - beautifully.

Fond memories indeed of those compositions. Great bit of work from dust, building on what M.Oostrik's and gtoledo were doing and applying it to audio interaction / visualization.

marcofilipevieira's picture
Re: artificial life dance

Hey, I had already done that. I put a new music file there, and I've inserted an input splitter for the path and connected to the audio file input. And wen I run the alifetrail composition still got the same error. =/ I've checked if the path is correct, and it is. I'm running on 10.7.3 machine. There is how I've got the composition.

PreviewAttachmentSize
alifetrail (1).qtz64.85 KB

cybero's picture
Re: artificial life dance

It just works - truly, here on 10.7.3.

Is yours a DVD install, factory install that has been updated or a Developer install? Mine is the latter. Build 11D50.

PreviewAttachmentSize
alifetrail (1).png
alifetrail (1).png1.04 MB

marcofilipevieira's picture
Re: artificial life dance

Mine is a factory install, and I've done around 2 upgrades. Mine is Build 11D50b. But I discovered now why I was getting that error. There were a composition a while ago that I had to open with a 32bit mode. And then I left always in 32bits. I've tested with 64bits and works! :D But I don't remember how I did to change that. I think it was in the preferences panel. But I went there and I don't see anything about that. =/

marcofilipevieira's picture
Re: OpenCL Boids (Composition by M.Oostrik)

When I try to open your composition (BoidsK 2.2_0) I got this warning on the boids OpenCL Kernel patch: :7:6 warning: no previous prototype for function 'in_view'.

The problem is related to this line of code: // check if point is in view of current velocity bool in_view (float4 OtherPos, float4 SelfPos, float4 SelfVel, float Angle) { return (fast_distance(normalize(OtherPos - SelfPos), normalize(SelfVel)) < Angle); }

cybero's picture
Re: artificial life dance

There are various ways to get QC in either or [64 or 32] bit mode.

Preferred option - duplicate the QC application, rename one to 32 bit, go to Get Info Panel and flag the Open in 32 bit mode box and run.

Other option, keep on going back and forth to Get Info Panel and have a real personal tail spin when you realise that you can't run a single QC in a friendly to both 32 bit dependent and 64 bit dependent compositions mode concurrently.

Ergo,

Have dual versions, one 64 bit by default on Lion, the other 32 bit by creation and preferencing as detailed above, then you can run them concurrently even, sweet.

Final tip, take that QC application icon and recolour. I make my 32 bit look a little tinted, but your preference on iconisation might run otherwise. Just helps to distinguish them on the Dock bar.

marcofilipevieira's picture
Re: artificial life dance

Thanks cybero! This forum is awesome! Everyone is so helpful and nice. This is the best forum that I've ever been. A big thank you for kineme people! :D

M.Oostrik's picture
Re: OpenCL Boids (Composition by M.Oostrik)

Hi there

Quote:
When I try to open your composition (BoidsK 2.2_0) I got this warning on the boids OpenCL Kernel patch: :7:6 warning: no previous prototype for function 'in_view'.

I didn't figure out yet how to make an 'external' function like that work in Lion. (any suggestions anyone?)

But i should be able to integrate it in the main kernel. I'll try to update the comp next week.

Recently i stopped working with openCL in QC, because every time i use 1 or multiple CL kernels i get an instant memory leak of 1/2 mb a second. (on multiple machines, both SL and Lion) Are more of you out there experiencing this problem?

These days i use openframeworks for my CL projects. I managed to create a very fine (and fast) optical flow / fluid simulation. And I probably will port the Boids as well. If any of you guys are interested i will post them on my blog once i feel they are finished.

Cheers M

M.Oostrik's picture
Re: OpenCL Boids (Composition by M.Oostrik)

By the way, does openCL work on Ati cards these (Lion) days?

cybero's picture
Re: OpenCL Boids (Composition by M.Oostrik)

That is down to the OpenCL compiler being far more rigorous [correct in fact] in Lion than the somewhat looser level of interpretation that the OpenCL environment allowed for in Snow.

Needs a rewrite.

Do look at those other OpenCL kernels upon this thread, wherein that issue has effectively been addressed already.

cybero's picture
Re: OpenCL Boids (Composition by M.Oostrik)

Open Frameworks OpenCL, snazzy :-)

cybero's picture
Re: OpenCL Boids (Composition by M.Oostrik)

FYI M.Oostrik - http://support.apple.com/kb/HT4728 - in fact the real caveat now is that

Quote:
GeForce 8600M GT Note: OpenCL compatible, but does not meet system requirements for Final Cut Pro X, Motion 5 and Compressor.
Sad but true. The good news is that, IMETD on trying out stuff at my local Apple Reseller dealership, the ATi cards truly rock.

M.Oostrik's picture
Re: OpenCL Boids (Composition by M.Oostrik)

I have a geforce 480 ;) (maybe that is the problem)

gtoledo3's picture
Re: OpenCL Boids (Composition by M.Oostrik)

The editor app shouldn't be used for leak testing.

gtoledo3's picture
Re: OpenCL Boids (Composition by M.Oostrik)

More explanation...

Besides possible legit issues/bugs, you're giving ofx a chance you aren't giving QC.

When you run a composition in the QC editor, it's also (legitimately) caching tons of values/arrays/lists, etc., and paths and textures of the Editor. It also has to be prepared to compile and jit the cl code on the fly, whereas ofx does not, afaik. The editor app has some leaks with Undo function, moving patches around, some allocations look like leaks (?), and a couple of other things pop up, depending on OS version...I've never seen one quite so large (and continuously ballooning) as what you're describing though, not denying it, sorta mentioning another aspect of performance here :-)

I've found through my own usage/questions/"journey" that the QuartzComposer (editor).app is really for editing. Though people use the raw editor app for performance scenario sometimes, and I have as well, it gets to be apples & oranges if you're comparing QC speed w/ speed of ofx or whatever, when running the editor app instead of running the qtz execution graph in the context of your own app that doesn't expose live compilation to the end user.

You can also load a cl program/chain of cl programs using your own custom plugin, and host within QC (somewhat like someone would put together the functions in ofx, but wrap it as a plugin instead).

cybero's picture
Re: OpenCL Boids (Composition by M.Oostrik)

Wouldn't that be an add in card? I wonder what your Mac Pro's built in card is. That card gives great CUDA and OpenGL 4.0 I am given to understand. If you haven't got a compatible card built in or added in then your OpenCL will be going to the CPU[s] IWHT.

dust's picture
Re: artificial life dance

here try this version. for some reason with my build or card or lion ??? mesh renders inside rii patches do not render how ever they do on an older nvidia card which is odd. try this patch. you do need an open cl enabled graphics card to render these boids. try this one without rii and feedback.

PreviewAttachmentSize
alifetrail (2) copy.qtz50.74 KB

marcofilipevieira's picture
Re: artificial life dance

Thank you a lot. That one works perfectly. :)

gtoledo3's picture
Re: artificial life dance

The RII patch did change between 10.6 and 10.7 (and 10.5 and 10.6). There's some stuff that makes it change evaluation mode and optimize some stuff... I bet it thinks it doesn't need to evaluate or something dumb like that, if there's nothing being driven by lfo/interpolate/patch time, etc :-) Maybe not.

jersmi's picture
Re: OpenCL Boids (Composition by M.Oostrik)

gtoledo3 wrote:
when running the editor app instead of running the qtz execution graph in the context of your own app that doesn't expose live compilation to the end user.
off topic maybe-- does this mean it's better to run qtz's in an app like VDMX, for example?

M.Oostrik's picture
Re: OpenCL Boids (Composition by M.Oostrik)

Quote:
Wouldn't that be an add in card? I wonder what your Mac Pro's built in card is.

yes it is. It's in my PC A dual boot setup with Windows and OSX. For working Quartz and CL I use the Nvidia Quadro drivers for mac. It runs pretty smootly!

M.Oostrik's picture
Re: OpenCL Boids (Composition by M.Oostrik)

Thanx for the tips and explanations. Is makes my troubles more clear to me :)

I wish the app would not have these problems though

As for my recent switch to OF: It has multiple reasons. One being performance (arguably linked to my own limited programming skills)

It doesn't mean i'm done with QC though. Since 2005 I spend a lot of time working with QC and I will spend a lot more in the future :)

gtoledo3's picture
Re: OpenCL Boids (Composition by M.Oostrik)

After another talk, I've been using ofx for the past few days and found some pretty cool stuff.

I found a funny comment about speed of ofx by directtovideo (who is totally badass) : http://vimeo.com/23216699 .... scroll down 6 comments and find: " Interesting you mention openframeworks and cinder. openframeworks is really badly written, it's not usable for serious realtime graphics without a lot of modifications (like, dump all their drawing code and add a new opengl renderer). :) ive heard cinder is better.." In poking around with their openGL system, I'm kind of unimpressed, but then again, I'm don't think QC's is super awesome either. BTW, I'm not necessarily fully endorsing that comment about ofx, it just made me laugh.

My experience has been a bit of both, and I have no solid conclusions. When I run a julia fragment shader using a code example from the ADC as a basis (no qc involved), it runs solidly faster and smoother than two different ofx implementations I've checked out to run glsl (the stock example, and ofFX, which I actually think is promising and cool).

On the other hand, I've run some projects that are pretty darn snappy. There's some really great openCV work going on. In some cases it seems like some of the fps meters on ofx projects are wildly incorrect, and show crazy high fps when cam has a good amount of visible latency and choppiness. Mixed bag so far.

I was kind of expecting to see some stuff w/ core profile or more modern openGL, but have been surprised to see that gl stuff isn't exposed in some ways, or that some basic function isn't "wrapped" with ofx. It seems like the ofx scene is also lagging w/ adapting to post SL as well.

What are you using as the basis for your OpenCL stuff? I've always really admired the stuff you put together in that regard, really clever.

gtoledo3's picture
Re: OpenCL Boids (Composition by M.Oostrik)

Also, check this out:

http://www.flickr.com/photos/obrasprofugas/6845290302/

I was just having some email back and forth with Patricio about working together on ofFX, filling out the selection of shaders, having seen the screenshots of this, some stuff with approach, etc., and I found out this is going to get pushed to github today. Looks exciting.

M.Oostrik's picture
Re: OpenCL Boids (Composition by M.Oostrik)

Quote:
I was kind of expecting to see some stuff w/ core profile or more modern openGL, but have been surprised to see that gl stuff isn't exposed in some ways, or that some basic function isn't "wrapped" with ofx. It seems like the ofx scene is also lagging w/ adapting to post SL as well.

yes and yes.

I don't use much of the OF drawing code. Actually I use OF more as sort of a tutorial for C++ and OpenGL (just learning as i go) And I do miss the fast and simple drawing patches of QC.

I'm still on SL for the most part anyways.

Quote:
What are you using as the basis for your OpenCL stuff?

Memos addon MSAOpenCL

Thanx for the compliment

gtoledo3's picture
Re: OpenCL Boids (Composition by M.Oostrik)

Got the ofx composer addon working this morning after it was put on github.

https://github.com/patriciogonzalezvivo/ofxComposer

PreviewAttachmentSize
ofxComposer_.jpg
ofxComposer_.jpg157.31 KB