2D fluid Simulation

itsthejayj's picture

In QC 4 (snow leo) 2D fluid simulation this patch escapes my understanding. Any one got anything working with it? I'm guessing that the ripple effect in Apples hyperwall at WWDC was using it?

cwright's picture
Re: 2D fluid Simulation

fluid sim is navier-stokes fluid solving stuff. It uses images (there's a demo of it somewhere, not sure where now that everything is messed up on the website, and the dev examples aren't included on the disc anymore).

I think the appwall used a simpler, custom CL kernel -- basically 1 element per app, with some simple rippling based on rss input.

itsthejayj's picture
Re: 2D fluid Simulation

really, i must have missed that dev example, shall have a closer dig around. unless did you see them on the wwdc 09 videos? as i contemplating whether to spend so much money on them

cwright's picture
Re: 2D fluid Simulation

I saw it in the QC state of the union video -- there's lots of great stuff in them, but unless you're a hardcore developer, they're probably a bit too expensive to justfiy :/

If I find the sample composition somewhere, I'll fling a link up here.

vade's picture
Re: 2D fluid Simulation

Here ya go.

PreviewAttachmentSize
2D Fluid Simulation.qtz42.9 KB

SteveElbows's picture
Re: 2D fluid Simulation

That file is the 2D Fluid Simulation macro that comes with Snow Leopard and shows up in the library anyway, not a demo of how to use it!

gtoledo3's picture
Re: 2D fluid Simulation

...and for the record, I commented somewhere else that I had this going, but I see I was confusing it with another patch, The Snow.qtz.

This qtz has to be being used as part of something else to make this come off (a patch that's being loaded into app or another qtz).

The OpenCL kernels make sense, and I can understand what they're doing... I'm scratching my head at the fact that fact that the only published image output is the Density, and furthermore, why I don't see it as a published image output when I look at patch params, even though it's published. I thought we would see published image outputs like this in QC3, but maybe I'm wrong on that. I see it in the Inspector, but not in the Parameter view.

dust's picture
Re: 2D fluid Simulation

So this thing takes 3 images it only outputs density if you are using occlusion. I'm not sure if this is a restoration patch or simulator but usually the navier is used for articficial restoration which means it will fill in where a image is damaged that is what it seems like it is doing to me but I have only messed with for a second. Just hook up 3 images and hit reset if you want to see density output also the comp has a velocity image I believe that is being fed into a render in image patch. What is strange is that the only thing inside the render in image is a clear but it still has image output you might want to put a image inside of that or a billboard ? But it will spit out density with 3 I Images attached. Haven't got any what I would call fluid simulations out of it but when I do I will post it. I'm going to try with video and feed some optical flow for density I I age. The occlusion would be the image that you would want to fill in or bounce off.

rinboku's picture
Re: 2D fluid Simulation

For example

PreviewAttachmentSize
2dflow.qtz1.14 MB

gtoledo3's picture
Re: 2D fluid Simulation

Aha, exactly! The velocity and pressure outputs were leading me off track. It's very similar to Vade/Benson's thing. Thanks rinboku!

SteveElbows's picture
Re: 2D fluid Simulation

I think the render in image patch within the macro is hooked up to pressure, not velocity. The occlusion input is optional.

Anyway I dont really know what Im doing but I managed to get some fluid out of it, sample attached ( click & move mouse to add more fluid)

Yay!

PreviewAttachmentSize
fluidtestmouse.qtz49.66 KB

gtoledo3's picture
Re: 2D fluid Simulation

I wonder why I can't take a video input, mask to alpha, put it over black clear (0,0,0,1), in a render in image and then use that for occlusion? Edit - never mind

dust's picture
Re: 2D fluid Simulation

yeah my bad it was pressure that was hooked up weird. so cool i guess im still waiting to see this working. the only reason i thought this was a restoration patch was because i get 1fps. i dropped the density down to 10x10 pixels and got it up to 3ps so i guess it is moving. i will have to try this on a quad core in the lab when it has snow leopard.

leegrosbauer's picture
Re: 2D fluid Simulation

I'm getting zero imagery from these examples. Both Steve's and Rinboku's compositions merely produce a solid grey Viewer. The Viewer FPS shows 88.88 but I can't see anything but grey. Tried both 64 and 32 bit and got no change in either mode. Any suggestions?

SteveElbows's picture
Re: 2D fluid Simulation

Does your computer have a graphics card that supports OpenCL? If not then this stuff wont work due to the bug where Quartz Composer wont fall back to using CPU if your GPU isnt OpenCL compliant. Although to be honest, as the framerates for this fluid example can get a bit low even on the GPU, Im not sure how useable it will be on the CPU, I guess we will ahve to wait till Apple fix the bug to find out.

Still if I dont use occlusion then I get around 30fps on a Macbook Pro with a 8600M GT, so I have quite high hopes for when I am able to get the expensive GTX card for my Mac Pro (its not available in the UK at the moment and its driving me crazy as the ATI cards I have for the Mac Pro dont do OpenCL).

leegrosbauer's picture
Re: 2D fluid Simulation

Ah. The awkward non available CPU option bug. Yeah, I'm on an ATI card. Thanks.

Eighteen month old top of the line iMac. Big bucks. pfffft. Apple won't be able to pull this 'legacy equals one year or less' crap much longer, imho. People could get sort of ... weird? I don't drop twenty-three hundred bucks lightly, eh? Just sayin'.

dust's picture
Re: 2D fluid Simulation

well if you drop the amount of iterations down you can get a really good frame rate. this is from my mbp nvidia 9600m its pushing over 5000fps this din't happen however till i pushed reset. i bumped the quality back up to 1 from .5 and i get around 3000fps either open CL and snow leopard kick some serious ass, or its a dodgy fps i would like to think it isn't dodgy because this mouse 2d fluid sim patch crashed qc both times i tried but when steve said he gets 30 fps on an older model than mine i thought i would change some settings and do a reset.

PreviewAttachmentSize
Screen shot 2009-09-03 at 2.38.54 PM.png
Screen shot 2009-09-03 at 2.38.54 PM.png393.94 KB

SteveElbows's picture
Re: 2D fluid Simulation

Here is an itunes visualizer I fudged together

PreviewAttachmentSize
SmokeEar.qtz548.85 KB

SteveElbows's picture
Re: 2D fluid Simulation

Here is another version of the itunes visualizer.

Some keys:

  • and - control smoke/fluid speed (try hammering + for a while) e to cycle through some effects s and d adjust sensitivity to music a bit h toggle displacemap mode r resets a lot of the fluid parameters

Considering Im just stumbling around, fed something fairly rubbish into the 2D Fluid patch, and have just used some stock effects, I think its turned out quite well, at least it has its moments. It would be nice if I could run it at a higher res.

Im not sure where the GLSL displacement map came from, I think it was someone on here, will try to work it out soon so can give credit.

PreviewAttachmentSize
SmokeEar3.qtz557.83 KB

rinboku's picture
Re: 2D fluid Simulation

another sample movie

2D Fluid Simulation Patch Test from RINBOKU on Vimeo.

dust's picture
Re: 2D fluid Simulation

you might have got the displacement map from my file don't know if you did you would want to credit JeGX for making a vertex placement tutorial. im having a hard time visualizing this one. it crashes when i open it. maybe if i throw it into the compositions folder itunes might have a better go at ?

itsthejayj's picture
Re: 2D fluid Simulation

Beautiful Rinboku, and thanks guys for solving the mystery of 2d fluid patch, it seem i too have will have to upgrade to a new computer with support for open CL. Strange though because i thought the snow dev exampled used open CL too and that works on my machine!

dust's picture
Re: 2D fluid Simulation

i think the problem is qc. open cl works system wide on the cpu. i got to get into it and figure out how to use both my video cards + the cpu.

SteveElbows's picture
Re: 2D fluid Simulation

What graphics hardware do you have in your machine?

itsthejayj's picture
Re: 2D fluid Simulation

leegrosbauer wrote:
Ah. The awkward non available CPU option bug. Yeah, I'm on an ATI card. Thanks.

sadly an ATI Radeon X1600 where i believe my problem lies -*bugs aside, the list of cheeky reason to feel the guilt of purchasing a new mac grows ;)

SteveElbows's picture
Re: 2D fluid Simulation

Ah well then I dont know why the snow example works for you, it doesnt work on my mac pro.

Even when the fix the CPU fallback bug, a lot of operations wont be much fun on the CPU, so yeah new hardware does seem rather tempting. I shall just be happy when I can actually harness this mac pro I got just over a year ago, no realtime apps made full use of its CPU cores and now openCL promises to unlock its power, but Im temporarily trapped by the QC CPU OpenCL bug and the nopenCL of my waste-of-money ATI 3870 card, and the lack of GTX285 Mac edition availability in the UK.

nopenCL is the sad label I will give to hardware that just lost its place in the future.

leegrosbauer's picture
Re: 2D fluid Simulation

Seems like there ought to be some way we could call attention to this ATI card issue with Apple. I'm sure there aren't merely only two or three of us, who spent thousands of dollars on top of the line Macs less than two years ago, who are now in the position of apparently having little more than end-of-life Apple hardware to show for our expenditures.

Does anyone have any good suggestions about how we might get some satisfaction regarding this issue? Its very disturbing, as well as being nonproductive, to simply be absolutely outraged .. as I currently am. Any ideas?

rinboku's picture
Re: 2D fluid Simulation

My Mac is a normal MacBook 13inch last year version. I set Boot Camp between 10.5 Leopard and 10.6 Snow Leopard.

dust's picture
Re: 2D fluid Simulation

maybe getting a matrox system lee will be an answer. or buy another card for your computer to use internally. that will be a lot cheaper than buying a new computer. im hoping they do some firmware chipset updates that will get my server running openCL. i bought it last year and its card is to old as well.

psonice's picture
Re: 2D fluid Simulation

Matrox is extremely unlikely to get openCL support. Buying another card: yeah, but if you bought a high-end (and totally openCL capable!) card just a year ago, why do you need to buy another?

I bought an imac 2 years ago, with an ati 2600. I believe this is also capable, and there must be many hundreds of thousands out there. It's not upgradable, so I'd need to throw out a perfectly good computer and buy a new one. Meanwhile the same-generation nvidia 8600 is supported.

I think it's more likely an ATI driver issue, and perhaps we'll see support for more cards in future (ATI is actively pushing OpenCL so there's hope at least.

Best way to push it is probably to contact ATI, and write to apple's feature requests address.

leegrosbauer's picture
Re: 2D fluid Simulation

Yeah, I believe I have the same box as you, psonice. Man oh man.

You think drivers might fix it, eh? That would be a tremendous relief! Here's hoping that we soon see some positive published indications that it's in the process of occurring. It would be well worth being patient for, if true.

psonice's picture
Re: 2D fluid Simulation

My understanding is that for OpenCL to be supported, the driver needs to support it for the card - then the OS can send an OpenCL kernel, and the driver will compile it for that card. So yeah, in theory at least a driver update could enable support. The question is whether apple will bother, and if AMD will spend the time needed.

For an idea of what cards COULD support it (from ATI/AMD), check the Stream SDK supported cards: http://developer.amd.com/gpu/ATIStreamSDK/pages/ATIStreamSystemRequireme...

Really, everything on that list should also support OpenCL. One worrying thing though: The ATI 2xxx range is supported, but not the mobile variants. The iMacs have a mobile GPU I believe, and it's not listed :( Then again, the desktop 2600 driver works fine under windows, so perhaps it's more of an OEM support issue than an actual hardware/driver issue.

I guess we can ask on one of the apple mailing lists, but knowing what apple are like good luck getting an answer ;) At least we should get CPU based openCL at some point - it seems that is fully supported, including in QC, but was broken at some point before the release of xcode 3.2. Hopefully it'll be fixed in the next update (iPhone SDK 3.1 is still in beta, so there will be a new iphone SDK update sometime soon. There's supposedly new ipod touches in the next week too, so perhaps a new iphone OS + final SDK will arrive at the same time :)

SteveElbows's picture
Re: 2D fluid Simulation

According to stuff I read elsewhere on the net (cant remember where), there are some bugs with the OpenCL implementation in the drivers of the few ATI cards that support OpenCL at this stage. So there will be driver updates to address that at some stage, but I wont bank on them supporting more cards. Its like a timewarp for me, ATI card drivers annoyed me over a decade ago on Windows, and now I have new reasons to dislike them.

As for how the QC OpenCL bugs get fixed, I will be interested to see if it happens as part of xcode or as an update to the OS. There could be bugs in the QC editor, but I guess the main bugs are in the underlying framework built into the OS, as people without xcode & QC installed still cant run my OpenCL itunes visualizer.

I would hope that as Apple tout OpenCL loudly, they will be keen to fix those bugs ASAP with 10.6.1 but I would not be shocked if it takes longer.

toneburst's picture
Re: 2D fluid Simulation

I must admit, lack of ATI X1600 OpenCL support (and little realistic prospect of it ever happening) was one of the reasons I decided to buy a new laptop recently.

a|x

psonice's picture
Re: 2D fluid Simulation

You're almost lucky there (comparatively, it's still a real bummer!) - we ati 2600 owners are left in a tougher position. The hardware certainly would support openCL, and there's support for it on other OSes, so the chance of it magically appearing in a future update is much higher. It's newer and more powerful hardware too. But then... it might never happen, and there's no way of knowing, so do we sit it out or do we give in and upgrade?!

Then again, what are the chances of getting opencl support on my old powerbook with a radeon 9700? (And getting SL ported to PPC in the process!) :D Guess it's time for an upgrade anyway.

leegrosbauer's picture
Re: 2D fluid Simulation

psonice wrote:
... so do we sit it out or do we give in and upgrade ?! ...

If I might attempt to be somewhat humorously morose; if I were to upgrade due to an inappropriate and premature Apple hardware obsolescence, my wife would tell me to take my @%#&! Mac and hit the @%#&! road. Seriously. If I instead were to choose to sit it out and if no remedy was ultimately forthcoming, it seems likely that these wonderful discussions here at Kineme, as well as the usage of Quartz Composer itself, would then be of substantially diminished interest to me.

It's a mild exaggeration of course, but the notion of perhaps having to choose between Kineme/Quartz Composer and a happy home is quite unsettling. I'm having a rather tough time adhering to polite language to express my frustration.

psonice's picture
Re: 2D fluid Simulation

For me, if I can't test openCL support properly it means I'll drop any plans to use it in my current application. Which is a huge pity, it would benefit it a lot.

If there's a lot of people in the same place as me, that means a lot of apps not getting openCL support. Think of the number of developers with an imac or a mac pro with one of these cards.. it must be a lot.

I really need a new laptop though, so perhaps my wife will let me buy one ;)

leegrosbauer's picture
Re: 2D fluid Simulation

My wife wants a laptop for the kitchen, as we currently have none. Any guesses about the likelyhood of her conceding to the purchase of an Apple branded laptop at this juncture? As for me simply purchasing a laptop for myself? Well, the spousal approval circumstances aren't much different nor are they much improved.

gtoledo3's picture
Re: 2D fluid Simulation

Well, as the dust has settled.... one part of me basically views it like running in another OS to achieve a handful of new "Apple" patches... that I'm still feeling out, with many other things changed in ways that make the actual user experience a bit unpleasant.

It's not as if things that could be done with QC in Leopard have really been completely tapped out either, and in my opinion, you can do more in Leopard QC because of the sheer amount of compatible 3rd party plugins.

At the end of the day... I'll probably use SL when I want those shadows, but it's a fundamentally broken patch at this point, sooooo. The fact that it doesn't work on iterated objects is kind of a total deal breaker...it's almost useless unless I want to use QC as a front end for Google 3D Warehouse, or fuss around with making DAE's, or constructing meshes manually. The OpenCL stuff is cool, but as we can see, the GPU is not a panacea. I like some of it, but it's not giving me any kind of great performance, or actual function that I feel like I didn't have in Leopard with 3rd party stuff.

I've been constructing some 3D meshes, and that's interesting, but... I could do that with javascript and Kineme stuff.

SL just feels laggy to me, in general. Spaces, Expose, Finder, all feel slower. I see where technology has been exposed for Developers to make their apps run more efficiently in various scenarios, but it doesn't really carry over to the SL user experience.

I do miss multisampling in the QC viewer when I use Leopard now, but that's about it. I'm in Leopard right now actually :/

SteveElbows's picture
Re: 2D fluid Simulation

OpenCL aside, its strange how varied the user experiences of Snow Leopard that are being reported are. Its made my 2+ year old Macbook Pro fly along, finder is well fast compared to leopard, etc.

And I remain extremely happy about OpenCL in Quartz Composer - I know some things are broken right now but I have already been wowed, and the thing that really makes me happy is the future. Provided the whole OpenCL initiative doesnt fall on its ass, I can look forward to actually being able to harness future hardware. I can scale things up far more than before, eg add an extra graphics card, actually get use of 8 cpu cores, and maybe when I buy expensive graphics cards in future I will notice a more immediate difference, something that has sometimes been lacking in my previous 10 years of throwing money at GPU's. Sometimes I would get lucky and the bottlenecks I was trying to overcome were actually solved by getting a better GPU, but all too often Ive been stuck with CPU bottlenecks of intensive tasks in code that I have no ability to modify. So I am almost wetting myself that the parallel computing revolution comes to the one development tool I can actually use (QC). And this stuff is accessible, I stand a fair chance of actually being able to hack around with mesh deformers and particle systems and suchlike in OpenCL, where I would not even get as far as looking at source code for 3rd party plugins, even when its available.

As with the legions of people I see on more general mac forums, going on about how they arent getting instant gratification from things like OpenCL, I say give it time, and moderate expectations in the short-term. It will take developers to unlock the potential, and at least with qc we have the possibility that this stuff is accessible to nearly-developers like me who would otherwise have to wait quite some time to see openCL put to good use.

cwright's picture
Re: 2D fluid Simulation

Please don't think I'm poo-pooing your thoughts. But there's a bit more hype than I'm comfortable with.

For me (on my 2007 MacBook, my 2008 MacBookPro, and an ancient 2006 Macbook pro), Things overall are a bit snappier (once SL's settled, and has spotlight-indexed everything, etc). Nothing show-stoppingly amazing, but I'm certainly not complaining on that front. Without actual measurements, I can't rightfully say whether it's actually faster, or if it's placebo.

SteveElbows wrote:
Provided the whole OpenCL initiative doesnt fall on its ass, I can look forward to actually being able to harness future hardware. I can scale things up far more than before, eg add an extra graphics card, actually get use of 8 cpu cores, and maybe when I buy expensive graphics cards in future I will notice a more immediate difference, something that has sometimes been lacking in my previous 10 years of throwing money at GPU's.

The only reason to run CL on the CPU is because you need it as a fall back, or you haven't written hand-tuned SSE assembly w/ pthreads before. CL provides absolutely nothing new in terms of exposing multiple CPU cores that isn't already possible with very few lines of code.

Grand Central Dispatch, similarly, does absolutely nothing that isn't already possible. However, in this case, I will say that it cleans things up dramatically -- as in, hundreds or thousands of lines of code that software developers no longer need to write. Any forward-thinking developer has probably solved this problem to some extent already. Perhaps not as completely as GCD, nor as simply (because closures didn't exist in C/C++/ObjC), but functionally it's already "solved."

QC exposes CL a bit (though I'm skeptical of its efficiency, simply because CL's a complex beast, and only so much can be done automatically). Take the appwall, for example -- people are ranting and raving about it (OMG OpenCL OMG), but really, what was actually, physically taking place? a thousand sprites were textured, scaled, and colored. per machine. When was the last time a thousand textured, lit, polygons per frame impressed anyone? The Nintendo64 could do 100,000 per second, so it fits the bill (it's actually a bit above our requirements). Hello 1996 ;) 13 years later, and a visual programming language has just reached the point where it can do that? Sorry, but call me unimpressed.

SteveElbows wrote:
Sometimes I would get lucky and the bottlenecks I was trying to overcome were actually solved by getting a better GPU, but all too often Ive been stuck with CPU bottlenecks of intensive tasks in code that I have no ability to modify. So I am almost wetting myself that the parallel computing revolution comes to the one development tool I can actually use (QC). And this stuff is accessible, I stand a fair chance of actually being able to hack around with mesh deformers and particle systems and suchlike in OpenCL, where I would not even get as far as looking at source code for 3rd party plugins, even when its available.

QC's mostly out of the parallel processing circle -- multithreaded? nope (except for special cases). Multi-GPU? nope. I totally appreciate the anticipation, and the excitement you're referring to, but I feel like we're still a half-generation or more away from actually-accessible parallel processing capabilities.

CL's approach to mesh deformers is absolutely brilliant -- I was planning a similar approach using GLSL vertex shaders + Transform Feedback for Kineme3D (which would do effectively the same thing, but without requiring newer hardware), but then I went to WWDC'08, and saw CL, and threw my hands up. If things keep struggling though, perhaps I'll fire that idea back up again...

SteveElbows wrote:
As with the legions of people I see on more general mac forums, going on about how they arent getting instant gratification from things like OpenCL, I say give it time, and moderate expectations in the short-term. It will take developers to unlock the potential, and at least with qc we have the possibility that this stuff is accessible to nearly-developers like me who would otherwise have to wait quite some time to see openCL put to good use.

I agree that it'll take a long time for the implications of CL to actually have an impact. That said, I'd expect something to at least work, everywhere. A similar situation happened with PlayStation 2 development -- no one has seen/dealt with a Vertex Processor before, and he PS2 had 2 of them! So PS2 titles actually continued to get more and more impressive as the platform matured, and as developers gained experience with the hardware. But in CL it's a bit hobbled -- there are situations where it flat-out doesn't work (namely in QC), and that stifles developers and development in general. It's similar to OpenGL extensions that aren't available everywhere -- because they're unreliable they're often avoided, and they don't reach as large of an audience as the plain-vanilla functionality. I can only hope that they really step up their game on CL support if they seriously want people to do amazing things with it.

SteveElbows's picture
Re: 2D fluid Simulation

Cheers for your thoughts :)

I think the differences of opinion are due to a vast difference in our capabilities - I can muck around with other peoples code a little bit, but Im no developer really. OpenCL in QC exposes a few things that I can botch and hack away at on a level I am comfortable with, and thats half the reason Im a tad hype-filled over this technology.

As regards the possibilities for unlocking the potential of the hardware, I understand your points about GCD and OpenCL, and Ive long heard about how trivial it can be to harness all the cores, but the reality to date with many apps I use, and QC and its plugins in particular, is that they dont seem to harness my hardware. I dont expect perfection, and I know that QC itself imposes many constraints, but I would live to delve deeper into some of the detail as to why OpenCL excites me in this regard. Its quite possible I have got some facts wrong, and I would dearly love you to correct me if some of the following is wrong, although I already feel guilty for robbing you of the time it took to reply to my previous message.

Are you sure that OpenCL in QC cannot harness multiple GPU's and make use of other CPU cores? When I look at some of the supplied patches, it at least looks like they are trying to make it possible to probe the host machine for available devices and their spec, and then use that info to tell specific OpenCL patches within the composition to use specific devices? It may not work at this stage but the intent seemed to be there and I hope not to wait too long before it may become reality. Have I gone wrong in my thinking on this one?

I am very upset by the state of OpenCL in QC at this stage. The QC bugs are extremely annoying, failures on several levels, and Apples whole approach to secrecy really shows its flaws when it comes to something like QC which has a limited user base. A post-mortem for this stuff would be fascinating, but we arent privy to all the pertinent detail and I dont even feel I can openly discuss the few parts of the snowlep evolution I have some clue about, such is life behind the unibody aluminium curtain. The longer it goes unfixed, the more disturbed I will become.

Still in some way Ive grown used to Apple not exactly giving QC the status or attention that it gives most other aspects of its development tools & technologies, so I shall try not to see the QC-specific OpenCL failings as a lack of dedication to OpenCL on their part. Other issues with OpenCL at this stage are worrying but I suppose I should not be surprised that there may be some bugs in Apple's implementation or certain drivers. Posts on a few forums seem to suggest that some of the Apple example code is not running on the ATI GPUs that are supposed to support OpenCL. Bad start, and if we up trapped in the usual hell where things still end being coded device-specific to deal with known issues, the whole point of OpenCL starts to crumble? Too early to tell, hope its just teething problems. Lack of support for some hardware that should be OpenCL capable is upsetting too, but eventually it wont matter, just so long as there are no glaring omissions in OpenCL support for future GPUs of any substance.

Dont get me wrong, Im about as cynical as you can get when it comes to the IT industry, Im not used to being positive and singing praises of stuff like I did earlier, maybe I went ott. I just had 4 intense days of mucking with OpenCL stuff in QC and being very happy, completely contrasting with nearly everything I read on the internet (with the exception of some people getting excited about benchmarks). If it eventually turns out that Ive backed the wrong horse, never mind, and I certainly appreciate people telling it like it is. Im generally far more comfortable praising small developers such as yourselves, and in recent years its been you guys who delivered things that made me very happy indeed, not Apple. But as time is not a resource you have in abundance, Im hoping that OpenCL will help me to help myself, at least a little bit more.

cwright's picture
Re: 2D fluid Simulation

Sweet, Elbows -- sounds like we're mostly on the same page :)

SteveElbows wrote:
I think the differences of opinion are due to a vast difference in our capabilities.

That may be part of it -- I've spent way too long being close-to-the-metal to know what's really possible, so seeing stuff that's orders of magnitude slower saddens me I suppose.

SteveElbows wrote:
As regards the possibilities for unlocking the potential of the hardware, I understand your points about GCD and OpenCL, and Ive long heard about how trivial it can be to harness all the cores, but the reality to date with many apps I use, and QC and its plugins in particular, is that they dont seem to harness my hardware. I dont expect perfection, and I know that QC itself imposes many constraints, but I would live to delve deeper into some of the detail as to why OpenCL excites me in this regard. Its quite possible I have got some facts wrong, and I would dearly love you to correct me if some of the following is wrong, although I already feel guilty for robbing you of the time it took to reply to my previous message.

(minor nit: harnessing all cores isn't "trivial", it's quite difficult as a software developer. That's why apps aren't doing it -- it's hard. GCD solves some of the glaringly obvious parts, which by itself is a massive win in my book, and that alone excites me, but at the end of the day it will probably always be difficult to write scalable, robust, fast threaded code that operates on non-trivial shared data sets. GCD can't deal with that much at all, but most of the small wins don't need that level of control anyway.)

Don't worry about "robbing" me of time -- I pick and choose where I can reply (and try not to step on toes/make people feel bad, though the engineer in me is "blunt and abrasive", as I'm sometimes told :)

SteveElbows wrote:
Are you sure that OpenCL in QC cannot harness multiple GPU's and make use of other CPU cores? When I look at some of the supplied patches, it at least looks like they are trying to make it possible to probe the host machine for available devices and their spec, and then use that info to tell specific OpenCL patches within the composition to use specific devices? It may not work at this stage but the intent seemed to be there and I hope not to wait too long before it may become reality. Have I gone wrong in my thinking on this one?

I've honestly not poked at QC's CL patch enough to know all the ins and outs, but due to the way patches execute (as far as I've seen -- it may have changed deeper down to invalidate this) each CL patch will execute sequentially, so even if you have 4 kernels with each assigned to 4 different GPUs, they'll happen one after another (GPU1, GPU2, GPU3, then GPU4) -- if a kernel tries to straddle multiple GPUs, I don't think that's supported either (that's some tricky CL usage, and data-sharing becomes extraordinarily complex, even outside of QC's constraints -- I'm not sure if QC can even expose that kind of operation nicely).

SteveElbows wrote:
I am very upset by the state of OpenCL in QC at this stage. The QC bugs are extremely annoying, failures on several levels, and Apples whole approach to secrecy really shows its flaws when it comes to something like QC which has a limited user base. A post-mortem for this stuff would be fascinating, but we arent privy to all the pertinent detail and I dont even feel I can openly discuss the few parts of the snowlep evolution I have some clue about, such is life behind the unibody aluminium curtain. The longer it goes unfixed, the more disturbed I will become.

Agreed :)

SteveElbows wrote:
Still in some way Ive grown used to Apple not exactly giving QC the status or attention that it gives most other aspects of its development tools & technologies, so I shall try not to see the QC-specific OpenCL failings as a lack of dedication to OpenCL on their part. Other issues with OpenCL at this stage are worrying but I suppose I should not be surprised that there may be some bugs in Apple's implementation or certain drivers. Posts on a few forums seem to suggest that some of the Apple example code is not running on the ATI GPUs that are supposed to support OpenCL. Bad start, and if we up trapped in the usual hell where things still end being coded device-specific to deal with known issues, the whole point of OpenCL starts to crumble? Too early to tell, hope its just teething problems. Lack of support for some hardware that should be OpenCL capable is upsetting too, but eventually it wont matter, just so long as there are no glaring omissions in OpenCL support for future GPUs of any substance.

My CL woes come on 2 fronts: First, QC (the tool that undeniably brought shaders and CoreImage filters to the hands of non-programmers) doesn't support it correctly -- there's no fallback as there should be. That severely hinders the tool, as you've already noted.

Second, CL on Mac OS X in general is spotty -- ATI gpus can't deal with it at all, and those come in some recent machines. I'm hopeful that a future update will resolve this, but the audacity of launching Snow Leopard with it Not Working leaves me completely puzzled. CPU fallback is fine, but it just seems strange I guess (they knew this was happening before June 2008). I guess, since no software uses it, it doesn't harm anything, but if it doesn't work, no software ends up using it, and then there's no push for support, so support doesn't happen, so software that uses it doesn't happen, ad infinitum. I'm confident that the cycle will be broken at some point, but it sets a saddening trend to have it not Just Work from the get go.

SteveElbows wrote:
Dont get me wrong, Im about as cynical as you can get when it comes to the IT industry, Im not used to being positive and singing praises of stuff like I did earlier, maybe I went ott. I just had 4 intense days of mucking with OpenCL stuff in QC and being very happy, completely contrasting with nearly everything I read on the internet (with the exception of some people getting excited about benchmarks). If it eventually turns out that Ive backed the wrong horse, never mind, and I certainly appreciate people telling it like it is. Im generally far more comfortable praising small developers such as yourselves, and in recent years its been you guys who delivered things that made me very happy indeed, not Apple. But as time is not a resource you have in abundance, Im hoping that OpenCL will help me to help myself, at least a little bit more.

I'm really glad you've been able to have 4 intense days of QC4 without apparent issue. I can't say that I've been so lucky. I really feel (and I'm not even making this up) that every time I fire it up to do something, I come across some glitch, or some bug, or some crash that interrupts my work. I know the pain of unstable software, and how that completely kills productivity. Shadows, for example, are "wrong". GLSL is handled properly with grids now (posted a few issues with that to the mailing list already). Billboards + shadows = pants-on-head retarded. OpenCL support is very inconsistent. Templates are now broken. The patch creator isn't as information-dense (each patch cell is like 3x as big as it was previously), search is "broken" (it's "better", but it has quirks that aren't compatible with Leopard's search that we've all grown to be familiar with).

I completely agree that CL can open up tons of potential to lots of people (smokris and I have had some long-and-hard talks on the future of kineme in light of what OpenCL can do -- sometimes it's pretty grim ;). But for that to happen (which we want, as much as anyone), some polish is necessary that was strangely absent...

SteveElbows's picture
Re: 2D fluid Simulation

Groovy. Sorry for my very poor choice of word 'trivial' when considering multithreading etc. I dont know why I said it, I know it isnt easy, Im hoping OpenCL makes it easier for certain things, or if not easier then at least something that more developers will actually end up using.

Ive not been close to the metal but I have been frustrated for a decade that when I look at what a well-tuned game can deliver, or at least appear to deliver, there is a big gap between that and what realtime creative tools have tended to offer. Ive sort of come to terms with it to an extent, and things are better than they used to be, but I always want more. The App Wall did not exactly wow me either.

The lack of more widespread ATI support for OpenCL in sl at this stage is certainly depressing, although Im not sure you meant to suggest that no ATI GPUs work with it at all? There are a couple that do, though personally I fall foul of the 3870 not being supported so Im a tad bitter about it, though at least I can change the card in that mac pro unlike unlucky laptop owners.

Other QC problems you mention are bad, Ive just been lucky that they havent affected anything Ive been doing recently, Im trying to avoid all those areas till they may fix them. I lost interest in the shadows a while ago when I saw what the framerate hit was like. I havent had too much joy with the 3D sound patch either. Im happy with the performance increase in certain areas, but yeah the stuff that is wrong has taken the shine off the launch. How swiftly and effectively Apple address the problems will certainly influence whether I want to invest a lot more time into QC or consider trying to steer away from it, and the entire Apple universe in future. Mind you if they do a full OS X tablet at some point then I will probably learn to put up with a lot. In the just over 4 years that Ive had apple products, I so far conclude that the company make just as many mistakes as anyone else, but occasional moments of inspired excellence in product design help justify the pain and strain on brain and wallet.

SteveElbows's picture
Re: 2D fluid Simulation

Unless when you talked about lack of ATI support, you were referring to the bugs with some of the examples not working? I lack clarity on exactly what the issues are with the ATI GPUs that are supposed to do openCL in sl. Ive just seen reports on forums that some benchmarks work, others dont, and a report that ATI think its a driver issue that they will fix, but nothing that gives me a concrete sense of quite how broken openCL is on these ATI devices right now. Someone that tried my 2D fluid sim music visualizer with an ATI card in a mac pro reported getting over 500% CPU use, where I get less than 25% CPU use, but Ive no idea what the story behind it is, as I thought CPU fallback was broken in QC. Maybe something else non-OpenCL in my composition was having a bad time with ATI, or something very weird is happening, but as I lack a suitable ATI card and have no intention of buying one I cant speculate further.

Thanks for the info on how you think multiple OpenCL kernels in QC behaves, if thats the full story then it does indeed dampen my hopes quite a lot. My expectations were largely based on the description for the OpenCL Context patch, which mentions multiple GPUs and load-balancing. Not that I should place too much weight on that patches description as it mentions another patch that doesnt seem to exist ( OpenCL Device Info patch), although I suspect thats because the functionality of the missing patch is rolled into the Context patch.

leegrosbauer's picture
Re: 2D fluid Simulation

As of this posting, there is by now quite a bit of pertinent prior discussion which follows this post sequentially. I'm commenting within the context of having reviewed that prior discussion.

Upon reflection I'm suspecting that rinboku's example, of running both 10.5 and 10.6 operating systems on a partitioned hard drive, may well be the best solution that we have for retaining the stability and production benefits of the old while still participating in the exploration of the new.

I believe that I'm going to follow rinboku's lead.

cybero's picture
Re: 2D fluid Simulation

Quote:

Ah well then I dont know why the snow example works for you, it doesnt work on my mac pro.

I believe I was amongst the first to report to this forum about the failings of Snow.qtz.

However, now that I have been through a continuing rigorous process of removing items provoking caveats and documenting the same I can now happily report Snow.qtz is working AOK for about an hour and a half before QC 'decides' to make the viewer stop rendering and upon restart one gets the following information within QC

An exception was raised
-[QCArrayBufferObject endUpdateArray]: Inconsistent state
 
0x808f73b8: GFException
0x808f9715: GFThrowException
0x808cf8e3: -[QCArray endUpdateArray]
0x808d7f69: -[QCArrayBufferObject endUpdateArray]
0x808d0f3c: -[QCArrayMemObject endUpdateStream]
0x808cc3f9: -[QCOpenCL(OpenCL) _executeKernel:context:kernelExecutionInfo:]
0x808cb10b: -[QCOpenCL execute:time:arguments:]
0x8084f109: -[QCPatch(Private) _renderAtTime:arguments:]
0x8084f06f: -[QCRenderingManager addPatch:context:time:arguments:nextExecutionTime:]
0x8084d9b2: -[QCPatch(Private) __execute:arguments:]
0x8084d5fd: -[QCPatch(Private) _execute:arguments:]
0x8084e160: -[QCPatch(Private) _executeSubpatches:arguments:]
0x8084de64: -[QCPatch(Customization) nextExecutionTimeForSubpatches:time:arguments:]
0x8084dd64: -[QCPatch(Customization) nextExecutionTime:time:arguments:]
0x8084dcc0: -[QCPatch(Private) _nextExecutionTime:arguments:]
0x8084d905: -[QCPatch(Private) __execute:arguments:]
0x8084d5fd: -[QCPatch(Private) _execute:arguments:]
0x8084e32b: -[QCPort _execute:arguments:]
0x8084d42e: -[QCPatch(Private) _execute:arguments:]
0x8084e051: -[QCPatch(Private) _executeSubpatches:arguments:]
0x8084de64: -[QCPatch(Customization) nextExecutionTimeForSubpatches:time:arguments:]
0x8084dd64: -[QCPatch(Customization) nextExecutionTime:time:arguments:]
0x8084dcc0: -[QCPatch(Private) _nextExecutionTime:arguments:]
0x8084d95a: -[QCPatch(Private) __execute:arguments:]
0x8084d5fd: -[QCPatch(Private) _execute:arguments:]
0x8084b6cd: -[QCContext nextExecutionTimeForPatch:time:arguments:]
0x8084b504: -[QCGraphicsContext nextExecutionTimeForPatch:time:arguments:]
0x8084b2d3: -[QCOpenGLContext nextExecutionTimeForPatch:time:arguments:]
0x0000d5f2
0x8089306d: -[QCView render:arguments:]
0x80898457: _TimerCallback
0x87207a78: __CFRunLoopRun
0x8720603f: CFRunLoopRunSpecific
0x85ac0c4e: RunCurrentEventLoopInMode
0x85ac0a53: ReceiveNextEventCommon
0x85ac090c: BlockUntilNextEventMatchingListInMode
0x836a8570: _DPSNextEvent
0x836a7ed9: -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
0x8366db29: -[NSApplication run]
0x00001d2b

So three steps forward and one step back. Not so long ago it wouldn't work , then it worked for a few minutes, then a half hour, now an hour and a half.

SteveElbows's picture
Re: 2D fluid Simulation

And just to clarify my hopes about opencl multiple gpu use. Im not expecting them to efficiently share data with one another, but I was hoping I could use 2 gpus to do 2 different parts of a composition and have some gain. eg 2 different meshes, going to 2 different mesh filters, going to 2 different rendering patches.

cwright's picture
Re: 2D fluid Simulation

Yep, knew what you were wanting. I'm thinking it would "work", in that, it wouldn't explode or anything, but it wouldn't necessarily happen in parallel (I'd need to do some testing to know for certain though) -- A single GPU would need to render both meshes, so at some point you're transferring from GPU2 to GPU1 (expensive, unless it's a fancy-pants dual-gpu board?). I'm also not sure if it chains deformations (like CoreImage), or if it does them sequentially. If it's the former, it's possible it would deform in parallel (though still unlikely, as only one ever gets rendered at a time), if it's the latter, it's almost certainly doing them one at a time (so it's like using Core1 of the CPU to do some work, waiting till it's done, then having Core2 do some more work -- both cores are "working", but not simultaneously...)

Mind you, this is dark voodoo territory, and I really need to set up some tests (and buy a dual-gpu machine! ;) before I say for certain whether or not it even matters to split work in QC.

SteveElbows's picture
Re: 2D fluid Simulation

Does snow.qtz run at all for you when unmodified or have you got it working by editing the opencl code used in the composition?

cybero's picture
Re: 2D fluid Simulation

SteveElbows wrote:

Does snow.qtz run at all for you when unmodified or have you got it working by editing the opencl code used in the composition?

Unmodified, Steve.

rinboku's picture
Re: 2D fluid Simulation

At first I updated ordinary from 10.5 to 10.6. But it seemed some troubles had happened. So I decided using Boot Camp. Fortunately it is running well now.

SteveElbows's picture
Re: 2D fluid Simulation

Thanks for info. I think I was temporarily confusing you for someone else who reckoned they had snow.qtz working even though their gpu wasnt opencl-compatible.

gtoledo3's picture
Re: 2D fluid Simulation

I don't use bootcamp... I just set it up to have 3 partitions using Disk Utility, and I hold option down when I boot.

Chris turned me onto the idea of having a clean installation to compare against at all times (which just makes good sense for determining bugs). Right now I have two Leopard installs, and one Snow Leopard, though I may reverse that.

I will also throw out there, that it's really good practice to not just throw all of the old Leopard plugins into SL, and wait for something to happen. It's a bit better idea to introduce plugins one by one and observe each time. At least that's how I'm vetting things.

gtoledo3's picture
Re: 2D fluid Simulation

I'm sure I had Snow working on the Intel X3100 in something before the GM (assuming this is the one that says "Snow" and particles fall and kind of detect the word "snow").

I did notice these same problems with the exceptions, but wasn't too concerned about it because I was viewing it as way pre-release (erroneously). I haven't run it in a looong time. I didn't feel like it was a big deal, since it's so trivial to do particle collision in 3 planes with K3D and Particle Tools (or even with just Particle Tools)... It just didn't "hook" me.

leegrosbauer's picture
Re: 2D fluid Simulation

I'm having issues too, rinboku. Frequent freezes on start-up and markedly increased start-up and shut-down times, primarily.

My thanks to you both for your advisories. I'm backing up my home folder now prior to proceeding, as I had been advised elsewhere. I'll report back after I'm partitioned and installed. The triple partitions sound useful. I'll look into that before continuing. Thanks again, gentlemen. New territory for me.

SteveElbows's picture
Re: 2D fluid Simulation

Thanks for the info. Im half tempted to get two GT120 cards for the Mac Pro but I should probably wait till I get get a GTX285. Maybe I will get one GT120 now and then a 285 later, hmmm.

cybero's picture
Re: 2D fluid Simulation

Looking at the date of the post I am currently responding to over a month after it's first appearance I begin to understand just how busy I've been with other stuff lately.

Only just got around to enjoying my iTunes for a change.

Whatever •~

Just been running the Ear Fluid fluid simulation as an iTunes visualizer and am pretty well impressed to say the least, some really cool switching of rendering and colour effects. Love those mountainous audio clouds.

It's interesting to note just how little difference the sizing of the rendering window in QC or iTunes really makes to the fps.

Neat multiplexing of differing image inputs via composition patches.

SteveElbows's picture
Re: 2D fluid Simulation

Thanks :) I havent touched it for a while but there are a few different versions of SmokeEar/Earfluid knowcking around, I couldnt decide which settings to use for defaults and I kept mucking around with the fluid speed options, not sure if the version on my website known as EarFluid is actually better than the SmokeEar I posted here or not.

Also I think I figured out where I got the displacement map code from - psonice's ImagetoGenericRGB example composition. If you are reading this please let me know if its ok to use your code and what sort of credit youd like.

Cheers