LFO performance hit w/ NVidia 9400?

Gummibando's picture

Hi there,

I see a pretty serious performance hit when using LFOs in high resolutions (e.g. 1920) on a Nvidia 9400 based machine (Mac Mini). The GPU is more or less saturated (I'm using atMonitor). I always thought calculating a sine is nothing too complicated nowadays :) Is this a limitation of the integrated graphics chip? What is your experience on machines with dedicated GPUs?

Take care Oli

cwright's picture
Re: LFO performance hit w/ NVidia 9400?

The LFO patch never touches the GPU -- it's more likely that the LFO is driving something that has to get redrawn every frame because of the LFO (for example, using the LFO to rotate a 1 million vertex mesh will, of course, require a ridiculous amount of work).

Gummibando's picture
Re: LFO performance hit w/ NVidia 9400?

Damn, I knew it (NOT, obviously :)

Thanks for the reply. And you're right. I can see the effect when opening one of the QC-supplied background compositions. Performance is ok in small windowed viewer but saturates the GPU in fullscreen. Anything I can do about this? Probably not, as even pre-rendering the animation and using a MovieLoader obviously has the same problem.

Thanks in advance Oli

Gummibando's picture
Re: LFO performance hit w/ NVidia 9400?

Is there any way to lower the LFOs temporal resolution?

Take care, Oli

cwright's picture
Re: LFO performance hit w/ NVidia 9400?

Gummibando wrote:
Anything I can do about this?

get a faster GPU? At the end of the day, there's a finite amount of computation that can take place on a given GPU. If you're saturating that, there are only 2 possible solutions: 1) do less work (i.e. optimize the composition somehow, or write a custom patch that does less work, or something), or get hardware capable of performing more computations per unit time.

cwright's picture
Re: LFO performance hit w/ NVidia 9400?

Gummibando wrote:
Is there any way to lower the LFOs temporal resolution?

You can use JS to halt it some. This won't necessarily reduce the amount of rendering work that needs to be done, but it's worth a shot.

Here's an example comp.

PreviewAttachmentSize
steppedLFO.qtz4.22 KB

psonice's picture
Re: LFO performance hit w/ NVidia 9400?

If you're saturating the GPU, it's generally wise to focus your efforts on making the GPU work less rather than just making it run slowly. Unless you absolutely need maximum quality, and don't care at all if it runs badly of course, and there are cases like that :)

A few groundrules that come to mind:

  1. Use the lowest resolution you can. Sometimes you need full HD res, but most times you can render much lower and stretch it to fill the screen. If you want to do that, use a render-in-image patch, put everything in there, and mess around with the width/height to see how it looks + how fast it runs.

  2. Don't use the "high quality" patches unless you need to. E.g. gaussian blur is good, but really slow. Try using the hidden "cheap blur" patch, or vades v002 blur patch for blurs, they're much faster.

  3. Watch out for "growing" textures. Example: You draw something at 640x480, then use a blur. The blur patch causes it to expand, so it's now 800x600. Then you process it again, and it grows to 1280x960, and the GPU is now doing 4x more work than it should. Check if that's happening during your chain, and correct it with crop patches wherever it happens.

Btw, nvidia doesn't have a particularly good reputation for CI performance, so if you're using CI filters at all it might be worth trying the same effect using GLSL instead. That's a bit more advanced, but worth bearing in mind if you do use CI.

Gummibando's picture
Re: LFO performance hit w/ NVidia 9400?

Thanks for all the comments and help. The 9400-based Mac Mini is just the perfect hardware for my project. So for now it seems I have to live with the limitations.

Oli

Gummibando's picture
Re: LFO performance hit w/ NVidia 9400?

Hi all again,

I was able to fix the performance problem by using the private CICircle and CIRectangle patches to generate the needed shapes instead of using pre-built image resources. Which will be totally ok as you can see in a few weeks (hint, hint).

Best Oli

cybero's picture
Re: LFO performance hit w/ NVidia 9400?

just a quick refresher question, is it the case that running a private patch dependent composition on another Mac were no private patches are enabled will adversely affect the rendering of the private patch dependent composition?

dimitri's picture
Re: LFO performance hit w/ NVidia 9400?

It doesn't seem like on my side, I have a composition that includes a CICircleGenerator and it works without revealing the private patches. KinemeCore is installed, though.

dust's picture
Re: LFO performance hit w/ NVidia 9400?

i know private patches work even if they are not enabled. i was running into things like hit test on the net that worked perfectly last year on my system without having the private stuff enabled. actually i got kcore now but i suppose reading quartz composer wikipedia is a help. that how i figured out how to enable privates a machine that doesn't have core. "option prefs" i guess george told me there is a command line trick but options prefs gives you a whole bunch of options that i haven't a clue what they all do.

Gummibando's picture
Re: LFO performance hit w/ NVidia 9400?

Private patches work like regular ones once they have been placed in a composition. This specific composition is used inside a Cocoa application and the host machine it's running on doesn't even have the developer tools installed.

And, as my hint obviously was not specific enough - these patches will be no longer private in a few weeks (or even days). Ask yourself what could be the event/case that will lead to this change :)

Best Oli

cybero's picture
Re: LFO performance hit w/ NVidia 9400?

Thanks for the clarification, Gummibando,

Quote:

these patches will be no longer private in a few weeks (or even days)

Snow Leopard, of course :-)

gtoledo3's picture
Re: LFO performance hit w/ NVidia 9400?

Mmm, that's kind of off task (but not really that big a deal... I just fear the Apple police), but it's also not true in any event. In any QC I've seen (and that's all of them), you still have to unhide private patches.

edit... I also HOPE that SL doesn't come out in a few weeks since I can currently send it into a sputtering whimper without much ado.

gtoledo3's picture
Re: LFO performance hit w/ NVidia 9400?

It is a good idea to be very detail oriented about editing the option prefs, so that you can change them back as needed and not get a mess going :) ...

I never realized about option prefs until Leopard, but you are right, that is absolutely the best way to go about it. The first time I unhid, it was with commandline, after looking at fdiv.net. The second go round was by editing the plist, where I first realized all of the other options...

Smokris's FDIV, and another website that I can't remember were really instrumental in conveying the command line info to the masses...

Normally, I enable extensive tooltips, private patches, private patch settings, privateIBPalette, and ShowPrivateProtocols. On the reg, I also typically always make sure to have "on open, do nothing" and "show only editor"... to me, those are two things set in stone :)

Private patches totally work if you don't have them unhid in the QC editor... many of the Apple apps hinge upon them, so they have to work. You will still be able to see them on the editor if you open up a qtz that used them, and you don't have them enabled on your system.

My big patch mysteries are "whatever happened to cellular automata", and "what the heck it this CISmallGaussianBlur that does nothing and is an erroneous patch list entry". I kind of love the idea of a different gaussian blur, if only it was actually there :)

cybero's picture
Re: LFO performance hit w/ NVidia 9400?

If it weren't for the Apple Police I'd really like to see "sputtering whimper" video of those testing exploits. Still an NDA is an NDA, eh? :-)

gtoledo3's picture
Re: LFO performance hit w/ NVidia 9400?

I actually wish I could post some of the "non sputtering" stuff, because a kernel panic is kind of a static shot :)

I'm really excited about some of the SL stuff. I'm also the type that is kind of "if it's not broken, don't fix it", so I wish that certain issues would have been addressed in lieu of gilding the lilly.

What's even better is when the whole system (in Leopard as well) just... freezes. I mean, I feel like OS X and I are on an informal enough of a basis that we don't need to deal with trivialities like kernel panic/restart screens... and it often rewards me.