qc fps suffers unrecoverable deficit

strontiumDog's picture

hello again i have a qtz with a fair amount going on over a 2.5 min period timeline. 60fps at the start reduces to >30 as more objects are placed and animated. after a certain time (~10s) each object is disabled (enabled checkbox unchecked). about half way through when there's the most going on, fps drops to ~20fps (which i'm working on making >25) but then as the timeline moves towards the end, the number of objects enabled decreases, but the frame rate doesn't recover above 30, even though by this point there's as much going on on screen as there was at the beginning when i had 60fps.

a) is it the case that when you place an object in the system (from didn't exist to enabled) and then uncheck it's enabled check box, it stays in memory on my (NVIDIA GeForce 8800 GT) gfx card, which then struggles with all the objects placed in the system?

b) when an object has its enabled check box unchecked, and i want it removed completely from memory/processing, how can i do this most effectively?

c) i've not read of a qc frame limit in certain circumstances - just double checking with someone with greater depth of qc knowledge that there isn't one.

ta s

cwright's picture
post composition

Perhaps something isn't getting as disabled as you'd like, or perhaps it's an artifact with the driver. Without a composition to experiment on, all anyone can do is wave their hands and make random guesses.

strontiumDog's picture
too many objects

the composition i've got is too big to expect you to spend your time going through it which is why i didn't post it. just fishing for anyone's knowledge about what qc does with an instantiated object which is then disabled. i'm hoping someone will say qc keeps track of it, but if you really wanna lose it, then do this etc. as i'm struggling to believe that although i've got a lot of patches that 512Mb video memory/GeForce8800 isn't enough to keep the frame rate from dropping.

cwright's picture
hard to track

without the compo, it's hard to tell what's actually slowing it down. It might not even be object related.

depending on the kinds of objects in use, it might be keeping a little bit in vram, but none of the meshes in standard QC are particularly complex (sprite, cube, sphere, and teapot are all very small and simple, with teapot being the most complex, and sprite being the simplest).

If the object's in ram, but not getting used, it shouldn't affect performance much. the NV 8800 may have some texture/context quirks that you might be experiencing, but it's difficult to tell (usually those are much more severe, like 4-8fps).

If you're using kineme3d objects, they'll stick around in vram until the patch is disabled. With particle tools, I'm not as sure, but I don't think it'll keep much around.

[We're also wrapping up PerformanceInspector, which makes it trivially easy to find out which patches are taking up lots of time - that helps us isolate performance problems much more quickly than rummaging through the composition manually -- if you wanted to send it our way, we could run it through that and see if anything obvious pops up.]

strontiumDog's picture

ok, this is the qtz. it's very good of you to look at it. it's turned out to be quite labyrynthine, but then it's my first. thanks man s

cwright's picture

You'll want to save as flattened (hold down option when selecting "Save As"), since you're using a virtual patch (mq_polysurface) -- I just see the floor/ceiling grid, and nothing else :/

(though it's a very nice grid, I must admit :)

strontiumDog's picture
nice gridz

ah, try this instead.

cwright's picture

I don't have the midi2color plugin, so I don't see anything still (It looks like a developer example -- I could build it I guess, but not right now).

Anyway, the iterators are all active all the time, so I'm not sure if things are really getting turned off or not (most of them aren't doing much, perhaps because of the missing plugin or something).

Nothing too interesting shows up -- lots of time spent drawing lines, but without other stuff rendering, I'm not sure I trust the numbers to reveal anything useful :/ (I'm getting 150-300 fps on my macbook, all the way through)

strontiumDog's picture

you don't actually need the midi2color plugin - i'd disconnected it but hadn't removed it.

all 13 iterators basically operate the same way, in that i use a queue to get instances of each object placed in it's own 'time space' such that i can get certain params working which differ between iterations - also then after it's own private elapsed time, the enabled checkbox on that iteration gets turned off - i thought to save memory/processing.

iterations are added every time a midi instruction turns up - i've got the IAC interface rigged from logic to send what it's using to generate sounds to QC to generate sync'd video events. i guess you'd need about 10 channels of midi coming in to up the iterations to see instances of each object.

i start off with ~60fps on a nearly max spec'd 8cpu mac pro so i'm surprised you're getting 150fps. if you aren't generating any iterations in any of the sub patches though, that's probably why. i've modified the setup replacing the midi ins with interpolator/integrators - retry the above link. i get about 7.9fps and a mess on the screen, but you should see something happen. i'd be interested to know what fps you get from it.

cheers for your help today. s

gtoledo3's picture
I dunno, but I do note that

I dunno, but I do note that sample and hold is a p.i.t.a for consistent frame rates in general... and here it is inside of an iterator. I could be wrong, but I would bet that is some of the problem. Nicely done composition.

cwright's picture

With the modified version, I start off at the same framerate (~200ish), then quickly drop more an more, eventually hitting ~2 or less.

Profiling, I find that Iterators take up a significant amount of time, KinemeGL structure patches take up a lot of time, javascript takes up a lot of time.

  • Iterator 8 takes up 18.6% by itself (excluding subpatches)
  • Iterator 20 takes up 17.4% by itself (excluding subpatches)
  • Iterator 7 takes up 16.5% by itself (excluding subpatches)
  • Iterator 10 takes up 10.37% by itself (excluding subpatches)
  • Iterator 9 takes up 11.32% by itself (excluding subpatches)
  • Iterator 6 takes up 6.5% by itself (excluding subpatches)

This wasn't over the whole thing, but over a few second window once stuff started to draw (when it was really slow)...

I guess you'll want to try disabling the iterators as well, when possible?

(The structure patches for GLTools are horrifically slow because of how slow structures are in QC -- we'll probably optimize them a bit more in the next version, but there's only so much that can be done. If you can produce the data another way, that might speed things up as well).

High-Level Profile.png
High-Level Profile.png131.69 KB

strontiumDog's picture
incremental exercises

Cheers, though I admit s&h in iterators is not ideal. I'm in a learning phase. I get the impression apple need to do some work on the system cos iterators aren't efficient enough but you can imagine from my perspective it's nice to yet something in place at all with so little documentation.

strontiumDog's picture

thanks for the readout. It's highlighted a couple of places to start looking although the performance you got was because I replaced rythmic midi pulses with interpolators chucking out numbers at integrators and I expect I probably overdid it trying to rig it so you didn't have to spend time getting your midi keyboard out and start tinkling the ivories... Is there a way of knowing which iteratirs have which numbers? I've only got 13iterators and yet one is called iterator_20.

cwright's picture

if you mouse-over the patch name, it'll show you its identifier (Iterator_X) that might require an extended preference or something though (option-preferences).

Alternatively, you can rename the patches, and it'll show them by the name you give them.

You're right, it's not really representative of what's taking time since it's just got everything running at once.

But from what's there, it shouldn't be related to video (none of the patches used store stuff on the video card...)

have you considered running it in debug mode? it highlights running patches, so maybe it'll indicate what's happening.

strontiumDog's picture
midi/VH addition

thanks for the pointers -i couldn't find anything that let's me change the tooltip to anything other than the general helpfile. nonetheless i ran the debugger and profiler and there's nothing obviously showing why about halfway through the timeline my frame rate halves. or why that with a 8800 with the 512mb vid mem i'm getting a starting frame rate that's a fraction of the 150 you reported.

but i'm wondering about the value historian: if i was to hook up all the patches and record the 2.5 min sequence with midi values coming in I would have a recording of all the values as they are meant to be played, not how they would render (let's say i had an underpowered box for what I'm asking it to do), right?

so then if i played the value historian back through the sequence with quartz crystal recording, i'm going to get a recording of how the midi signals originally caused the sequence to happen, which surely will render in the same way with the slightly slowed down second half of my sequence? i know i can change frame rate with crystal, but surely if my box is overrun, surely, it's overrun with VH/crystal or midi either way?

it looks really nice at 60fps, so after 3 months of dev, to get stuck on getting a .mov of it (even if i have to run the mov through final cut to add the music which triggered the gfx) is a bit disappointing - especially as i'm sure there's a spanner which is weighing it down. i want to get on with some more tunes but i'm one of those people who can't leave something without finishing it. hence the number of kineme posts.

cheers again for your help guys.

cwright's picture

If you recorded raw data (with intensive rendering stuff disabled so the framerate was good for the whole recording), you'd have a capture that you could replay through QuartzCrystal to get proper output, regardless of how the composition's actually slowing down -- QuartzCrystal is an offline renderer, and doesn't care how long each frame takes to render. It always moves time ahead in 1/framerate increments (actually, 1/(framerate*motionblur) increments, but I digress). Even if the composition slowed down to the point where it took days to render a single frame, QuartzCrystal would happily wait to give you proper output (so the movie would look correct at your specified framerate).

strontiumDog's picture
assemble multiple value historian files

very impressive that quartz crystal by the sound of it. exciting.

all that remains then it seems is for me to disable the intensive rendering stuff you mentioned.

thing is, this intensive rendering stuff is part of the scene and i need it in there. if its disabled then surely it doesn't get recorded?

i also presume you meant disable parts of the qtz so the rest runs ok and you're not referring to some renderer setting which allows more intensive stuff to be disabled in some way whilst still allowing the VH to record the values as if they were rendering.

trouble is, even if it is possible to VH-record half the components to a file, then record the other half separately (thus getting decent frame rate each time), then to merge the files, because the frame rates are likely to be different for each file, the components are likely to be triggered at slightly different times making the sound/video slightly out of sync?

i admit i don't know how VH works so please do correct me. does VH not pay any attention to time?

cwright's picture
copy historians

If you copy 2 different historians into the same comp, they'll likely have different timestamps, but they'll each manage that themselves, providing the closets output for each frame time independently. Merging the files is a bad idea, but there's nothing wrong with just having 2 historians (or 50, for that matter).

If any of the outputs of the historian are used, then all the inputs to it will get recorded (regardless of whether or not they're used -- only one is necessary to make QC execute the historian).

[for example, I could have a historian with 10 inputs, and attach a bunch of midi controllers to each one. If just output 1 is used for something, all 10 will get recorded, and can get used later, even if they're not visible/used while recording.]

You can remove complex filters, or replace complex geometry with simple stuff etc. to get a better framerate recording.

strontiumDog's picture
sample rate

thanks for the help. experiments are going well, just that the sample rate of the historian is lower than i need it really - seen this in the discussion but couldn't see an answer. i've tried upping the integrated values but to no avail.

maybe i should connect this post to the VH beta discussion...

can i confirm the latest was 6/1?

cwright's picture

The latest beta release is here: http://kineme.net/ValueHistorianPatch20090114beta -- the recording sample rate isn't really a factor (after the first beta or two -- you might be in that category?).

it can only record as fast as the composition runs -- hence the advice about cutting as much out as possible (to get a high framerate -> high recording rate). There's not really a good way to record stuff at higher frequencies than qc's frame rate (without writing specialized plugins for every possible input source, which is largely a waste of our time).

You might want to disable as much as possible (notes above cover this more), and also modify the extended QC preferences (hole Option when opening the Preferences menu) to disable VBL syncing -- this will allow you to get > 60fps if the composition is nimble enough (nearly empty composition will typically render at about 1000 fps -- a few hundred fps isn't unrealistic for slightly interesting compositions). This might help you get closer to the recording rate that you're wanting.

strontiumDog's picture

thanks for the update - which i've installed. i know i've got the update as i can now name inputs in the VH. so, i found the VBL syncing and turned that off (finally seeing >60fps!) and restarted qc. then,

  1. i disconnected all but one of the outputs from the historian - the one to the lightest patch on the GPU.
  2. i cut the remaining patches out of the qtz (I'm finding that leaving them in albeit disconnected means when the comp runs, 1 iteration of each one is immediately output - do you know why this might be?
  3. set to record, check reset check box, uncheck reset check box (is this the way to reset?)
  4. run on the viewer, run on logic pro, and wait for the midi data to run through.
  5. stop the comp, set to playback, paste back in patches, and reconnect VH outputs to the right patches (some individual outputs are going to multiple patches - I presume this is ok)

  6. press play on the viewer and find that some of the timing is out. of course as described above it slows down again on play, but running this into crystal shows the timing is still out. like there was something which overloaded the historian during the run (even though it would have been running at nearly 500fps).

Each time I repeat the above steps, the timing is out in a slightly different way (not the same patch affected, sometimes several patches).

I read that timing is now not an issue - but it seems to be for me. I have to run logic on the kernel at the same time but that's the only thing other than qc running. there doesn't appear to be anything in performance inspector obvious either. strange.

do let me know if anything i'm doing is out. i could try creating a midi record and use a lighter app back through the IAC driver to QC, but it would be a great pain. each time i get to the end of this project, the end appears to moves away.. thank ia s

ps. how do i un-increasingly-thin this post?

cwright's picture
add new comment?

Adding new comments (to the topic, not a reply) will widen things again -- like this comment. It breaks threading, but it works better sometimes.

As for VH stuff -- can you record some of the data at the high framerate, and then save the VH patch into a composition by itself, and send it to me? I'd like to inspect the data inside, to see how it's recording/accessing the data.

If you've got rapidly changing data, it might not sync up nicely with QC's framerate (in signal processing parlance, this is called "aliasing"). Perhaps that's what you're experiencing (in which case, I don't know if there's a good way to handle it).

What happens if you re-enable VBL syncing, and just record at the typical 60 fps, or even slightly lower (50-40)?

strontiumDog's picture
merci pour la link studieren

hmm, every time i either paste the VH into another qtz and hover over the sample output, it's 0. it's late here, so this is the qtz minus most of the consumers. vh is in fog->lighting->3D Trans. should be 12000 odd samples. is that a lot? cheers for looking.

cwright's picture

It'll be zero because QC won't execute the patch to update the outputs -- the data's still there. If you plug it into a clear patch or whatever, it should show up as expected.

strontiumDog's picture

for the sake of brevity and saving you some time then here is the VH on it's own. i've noticed I can't edit my previous post now to remove the linked file. Is this some other functionality I'm missing?

valuesVH.qtz71.35 KB

gtoledo3's picture
The outputs do need to be

The outputs do need to be connected to something (anything that has a value input... clears are good, as Chris mentioned)....every one of the outputs, to record correctly. You can't record to the VH, if the output isn't hooked up to a consumer patch. I haven't messed with it in a week or two, so I may be off base, but maybe if you did an original "recording" with everything hooked up and are now trying to record with just an output or two hooked up to a consumer... maybe you are just overwriting the values of the inputs that you have hooked to something, hence resulting in the weirdness, and wrong playbacks in different spots each time you play back your most recent recording. Just throwing that out there, not sure if it applies.

cwright's picture

I believe you're mistaken -- disconnected outputs don't matter at all (VH doesn't do anything with them, other than forwarding input values/replay values), it's disconnected inputs that cause some problem (possibly exceptions in the last beta, or just nulls in my personal build).

As long as 1 output is in use by a consumer somewhere, VH will correctly record all inputs.

In fact, I just made a composition to prove this.

Mouse X/Y to 2-input VH. connect only output 1 to the X axis of a 1/10 diameter sphere. Record, and move the mouse on both axes. Then, attach the unconnected output to the Y axis of the sphere, put VH in playback mode, and watch the sphere go in both directions. win.

gtoledo3's picture
My bad, you are right (of

My bad, you are right (of course), I'm totally remembering the final beta (I think it would crash on replay?). Heheh, I love how you ended with "win"... for some reason it is evocative of chess. "I want a QC Battle Chess plugin, wahhhh". It is funny, but that word choice of yours is bringing to mind how fun a Kineme3D battle chess qtz would be.

strontiumDog's picture
further woe

there isn't much about disableVBLsyncing in this forum, and although i've checked it in the extended prefs, i'm still getting unreliable frame rates.

i've had and am now expecting about 500fps every time i start this qtz (before anything major;y draining happens), and i've even managed after using perf inspector to save the qc (which got down to 3fps) and restart it without PI running and it remains at 3fps.

I've just restarted the qtz again and i'm getting 30fps. does performance inspector affect frame rate?

also, given the evidence, would you recommend trying this out on a different leopard box? it's sounding like a good idea.


cwright's picture
quartz +

Quartz ( the OS X window compositing system ) usually doesn't like rendering more than 60 fps -- with VBL disabled, the viewer will run at higher framerates, but only if it's on top of all other windows -- if it's below, Quartz has to kick in and (potentially) re-render shadows from other windows on top of the viewer window, which will drop it back to usually 60 or 30 fps. Bringing it back to the top will usually pop it back up to the really fast framerate.

PI does affect framerate, but usually not significantly (unless you're doing lots of replication-in-space/time or iterator stuff -- then it can get noticeably, but usually not severely so.)

I don't know if a new machine will help with this or not... shrugs

strontiumDog's picture
possible nvidia problems

chris(/alx/george/others) - multiple cigars for all your comments over the last few weeks on this.

restarting qc so the qtz is on top and it's still stuck at ~30fps. i've got to move on. this was a valid exercise though and i will return to it when i have access to a machine with an ATI gfx card so i can maybe bench mark my setup against another machine. i wonder if this has anything to do with it. i have the chip set and the problems so i definitely wanna try out some other things around chip sets and the like.

i'll keep reading and maybe something will show up. cheers for again your time. s