- This topic has 28 replies, 4 voices, and was last updated 8 years, 9 months ago by
.
-
Posts
-
I was profiling an app I’m putting together that uses Syphon, and tracked down a pretty crazy amount of CPU usage to the Syphon Server for QC plugin.
With the Syphon Server enabled (but nothing listening), CPU usage shoots from around 30% to 130%+. I haven’t tested with something listening to the server, but either way, it’s not great. Having that kind of unbound CPU usage will tend to make yield that kind of crappy visual “lag” every 5~6 seconds or so, even though FPS is still generally OK.
I’m using the OpenGL Scene capture option, and most of the time, Syphon is grabbing what amounts to some layers of GLSL grids and shaders. Does the OpenGL Scene Capture do some kind of ReadPixels or anything that would expected to be slow and CPU intensive like I’m seeing?
I guess this amounts to “I’m expecting to see Syphon run on GPU, and it’s looking like it’s falling back on CPU”.
Also, are you initiating you GL context on one GPU, and displaying on a second GPU? (i.e., running a second application that is on a second GPU, listening to the server?).
You can additionally use GL profiler and enable break on SW Fallback, to see if any GL calls happening are not being run in full vertex and fragment acceleration (each can be individually done on the GPU while the other is accelerated).
@ bangnoise – I’m able to reproduce it in QC, where it’s actually much worse (around 40% CPU jumps to 170% with Syphon). I hadn’t profiled in QC, because it’s usually pretty worthless to do in-Editor profiling. That said, it’s a largish composition, so I’m trying to figure out exactly what it is that triggers this. I know that removing Syphon from the equation removes the problem, but I’m not running into the same thing with some simple tests. The premise of the composition is largely multiple composition loaders, loading other qtz’s that are mainly glsl shaders with stuff happening in the frag shader. I’ll see if I can contrive a simpler composition or home in on what it is that triggers this in combo with Syphon.
@ Vade- no, I’m just running on a single GPU, and that’s a good point about GL Profiler. I hadn’t run it on this particular project since adding Syphon.
If you can come up with the simplest possible reduction in a .qtz and share that with us, it will save us all a lot of guess-work. Do that.
Sure. I was throwing out a general description to get feedback on if there where already any known issues.
I’ll look at editing non-essential parts out of the main qtz if that works, or send along the qtz in question if it winds up being some weird mix of circumstances that result in that.
Lol…BUT, the data is factual and quantifiable. I see what you mean either way, not splitting hairs, just trying to make it easier for you to find the bug.
Just Run GL profiler, break on software fallback. That takes 30 seconds and run it on the comp exhibiting the behavior. Also, check statistics, and see what GL calls are taking the most time.
Is this a fully custom app, or a Quartz Builder app? – Ah, happens in QC. Just.. send us the QC comp if you can’t simplify it… ?
Well, I was just doing that but to my chagrin, when I run GL profiler on QuartzComposer.app running the qtz in question (at least on one of my 10.6 partitions, usual “go-to” install, but not entirely “clean”), and Syphon is on the Editor, QC crashes. So, that’s obviously awesome help in pegging this down.
On that note, I’m going to do a little more due diligence and make sure I’m up to date, and give it a run on another 10.6 partition and 10.7 as well. My main question was “has this come up/is it expected with OpenGL Scene grab?”… guess it isn’t, which is good!
…and yeah, my app runtime (not QuartzBuilder-only use that for quick convenience builds or a/b-ing) manages to make the result much less noticeable than in QC editor.
I’m going to go ahead and send along the patch, because even though there’s a decent amount of patches, a bunch of it is stuff for contouring some control from external sources, and it’s pretty well metadata tagged, and one macro level… maybe I’ll just chop some of that stuff out first.
For what its worth, I’ve never had issues with GL Profiler and Syphon in any App (it just works), and nor have we gotten any reports about high CPU usage due to Syphon at all, under any circumstances. This is either an edge case, or something in really wonky.
After spending a few moments looking at that comp, I am going to go out on a limb just frankly say, that is totally not how QC is intended to be used. My brain hurts that anyone would even make a comp like that, and then complain about odd behavior.
Sorry to sound like an ass, but, I just cannot express in words just how much that explains to me.
In other words, uh, yea, can you simplify that?
Mmmm, what’s essentially four comp loaders, loading some compositions that are shaders with grids. Yeah. Okey dokey.
My brain hurts that you think that’s a reasonable reply to another human being. I’m not here going “oh, Syphon sucks because it causes a 100% cpu spike that can be pegged down to IT running”. If it floats your boat to be patronizing, I’m glad to have given you your opportunity for the day.
Dude, if QC editor on a modern machine can’t even draw the comp correctly (the QC editor, when viewing and trying to *look* at the comp, is all but non-responsive). I don’t even know how you could make that comp. Unless something is so fucked in me opening it, or the comp is corrupted…
Ok, so. I got the comp up. If I don’t move around the editor (that uses 100+% CPU just navigating the comp), and run the viewer (once I had the plugins in place), I got the following CPU with Syphon off and on:
Basically, 25% CPU. I suspect you have a module that triggers specific behavior or something out of whack with an old plugin version. FWIW, I saw no OpenGL errors of software fallback.
Let me know if you can narrow this down.
Thanks for giving that a run, and the feedback. It’s good CPU consumption is modest either way on your machine.
After the really fun slamming, I kinda want to go on a jag about how little time it takes for a plist like this to load, the fact that keeping stuff “un-macro’d” makes for faster performance ultimately as opposed to “nesting” stuff in macros, that most of the noodle-adge here that’s involved is with multiplexing that’s extremely lightweight on cpu, that this is faster in performance than loading separate qtz pieces and stringing them together to achieve similar function, that the finished product renders visualizers in HD at a faster FPS (usually around 60fps for majority of my comps) than popular products I’ve used, and that today someone was checking it out and it had less latency than the sound system…. oh, I just did. 🙂
…but hey, I just do this for fun.
George, I haven’t opened your composition because the accompanying e-mail indicates it is not a reduction.
If you can produce a qtz…
1. which always reproduces the CPU-usage issue for you
2. with no external plugin, file or build requirements
3. which is clearly legible at a glance
4. which we can play in the QC Editor… I’ll take a look at it.
I’ll be rushing to do that considering the super professional genius guy public response and calm non-knee jerk reaction that my privately emailed dl-link was met with.
…and of course I must have made the composition in some mystical way that can’t run in the Editor. Sure, that makes sense.
..and of course it’s realistic for a project to have no external dependencies and legitimate bugs don’t count if they are brought on by code not working correctly with them. So you can rule out any bugs caused by a swarth of patches that… load files from external locales or should play nice together. Yep.
Thanks for the offer, but it’s sounding more likely that I’ll be able to pin down the bug. If it’s a Syphon bug, I’ll submit it to github, if it’s caused by a patch combo with a stock or third party patch, or hardware configuration, I’ll post back here.
- You must be logged in to reply to this topic.