Sony Vegas (Movie Studio Platinum) 9— rendering across multiple CPU’s?

[John Bean]

Vegas, like every app, depends on Windows operations and resources. So when Vegas has to *wait* for some Windows operation, like a disk write or memory read, the Windows OS will switch to another process (thread) like some other app.

As well, Windows is not a real-time OS. So every process (application or thread) gets a time-limited access to the computer resources. In the average case, every process gets equal time.

So turn your Windows system to its absolute bare minimum. Turnoff any program or services you don’t need.

Turn off all the fancy Windows management stuff like restore points and file indexing too.

Then, when you run Vegas, you can assign it to have the highest priority over every other process running on your Windows system. With a higher priority, Vegas will get more time allocated to it to use the computer’s resources.

Lastly, I’m not sure how optimize the Movie Studio version of Vegas is for multiple CPUs, especially an older version like 9. So, you’ll have to check on that too. An application still needs to be designed with multiple CPUs taken into consideration in order to maximize multiple CPU usage.

[Shane Etter]

Thanks John, for the reply.
but i respectfully disagree that this is the cause.
I should have mentioned that on the side, i run this pc as my main DAW with latency in the microseconds, so im pretty sure its good and setup right. in Cakewalk Sonar X1, the developer confirmed you needed a tweak to allow Sonar to handle more than two processors at a time. Also Windows 7 needs some tweaks.

watching vegas– at least this version of Vegas MSP9b– render video it will go all the way up to exactly and precisely 50% and no further.
so either Vegas isnt threading across 8x CPU’s/two physical processors right, or when it calls to Win7 its not telling it to.

Any other thoughts?
Can anyone with more than 4x CPU’s confirm that Vegas will utilize at or near 100% of the available CPU?

[Stephen Mann]

Have you looked at the Task Manager to check the Processor Affinity?

Processor utilization is a very poor metric of efficiency. It’s only accurate if it’s near or at 100%, then your processor is the bottleneck in the program.

Steve Mann
MannMade Digital Video
http://www.mmdv.com

[John Bean]

Check the specs for your edition of Vegas.

An app needs to be designed to optimize multiple CPU usage.

If you system is already optimize for an application like Vegas, then really, there’s probably nothing else you can try except upgrade to a PRO version of Vegas. Download the latest trial and try it out.

[Dave Haynie]

[shane etter] “I should have mentioned that on the side, i run this pc as my main DAW with latency in the microseconds, so im pretty sure its good and setup right. in Cakewalk Sonar X1, the developer confirmed you needed a tweak to allow Sonar to handle more than two processors at a time. Also Windows 7 needs some tweaks. “

Windows does actually have what’s come to be known as “soft realtime” performance. It’s not the same as a full fledged RTOS, but even that’s not what most people think it is. An RTOS isn’t necessarily super fast… the point of an RTOS is to be super predictable. An RTOS formally specifies things like maximum task switch and maximum interrupt latencies, it does thread priority elevation to avoid deadlocks, etc. For purposes of running Vegas or Sonar or other media programs, Windows IS realtime. For the purposes of controlling a nuclear reactor or a spaceship, not to much.

[shane etter] “Can anyone with more than 4x CPU’s confirm that Vegas will utilize at or near 100% of the available CPU?:

To actually just answer the question: Yup. I run a six core AMD 1090T (3.2GHz) and 16GB RAM. I usually see over 90%, often close to 98%, when rendering CPU-only (more on that later). It’s going to depend on many things, and the more complex your project, the more potential for weirdness to creep in.

There are several possibilities here. One is the easy one, and the one you alluded to with Sonar (I’m also a Sonar user): settings. Look at Preferences/Video, and you’ll see a few tweakables there. The obvious one: number of rendering threads. If you wanted to ensure Vegas never went beyond 50% CPU utilization for rending on a quad core processor, set that to “2” and you’re there. This should normally match the number of cores (real or virtual might be a bit more of a science project, if you have an i7).

The next tweakable there that will have an effect on performance is the Dynamic RAM Preview setting. During editing, this is the chunk of RAM Vegas allocates to use for a RAM preview buffer. Experimental evidence from a bunch of us here suggests that this is used for buffering during rendering. A relatively small amount here will speed up rendering, as you would expect RAM buffering to do. Large values may starve your system of RAM that would better be used for other stages of rendering.

After the small bits of tuning possible, check the use of any plug-ins. A good, modern plug-in can be multithreaded; a not so good, not so modern plug-in may not be. Certainly, if you ever see performance drop to “essentially one core”, try disabling some plug-ins, particularly third party, and see if it just snaps back.

Well tuned Vegas can very readily deliver 95%-99% CPU utilization on rendering, that’s usually what I’m seeing… with a few caveats related to where you bottlenecks live. The most obvious one is hard disc speed. As most people here probably know well, modern HDDs are fast… really fast. Any SATA drive worth still using should deliver read performance in excess of 50MB/s sustained, many can hit 100MB/s (you can pretty much ignore the SATA link speed, that’s a potential, but you probably only hit that on cash to PC transfers… HDD speed is a matter of mechanics). However, if you’ve been a DAW user for long, you may recall a time when PCs were pretty limited to the number of tracks they could support. Back then, it wasn’t HDD speed that really mattered, but seek time. Moving track to track is 1000’s of times slower than reading data along a track. So on DAWs, the number of audio tracks is usually limited by seeking, and you’re aware of this, as a serious DAW users, because you might routinely run dozens of audio tracks.

Video users don’t necessarily think in these terms, but the same physics still applies. Maybe you’re used to editing a single video track, rending it out, everything’s cool, you hit a 95% CPU use. Then you move to another project, and things hit a wall. I ran into that wall first back in 2006, on a wedding shoot that had not only two video tracks but very, very heavy use of 6-8Mpixel still photos (the happy couple had not one, not two, but three professional photographers covering it, in addition to my video). I was driving Vegas to its knees, rending was running at maybe 20%, etc. What I did was move the photo assets to a different HDD, render out to yet another HDD… and I was back in the saddle, getting full speed renderings (as one of my first full HD projects, it wasn’t pretty anyway… an hour’s AVC render back then took 28 hours on my PC and 24 on my laptop… the same dual core Core2 laptop I consider too slow for serious video work today). So use your DAW brain when thinking about what’s on disc.

And finally, there’s this great new thing in Vegas 11, if you ever move up from Vegas 9: GPU support. You will absolutely find that, at least on most systems, there’s an inverse relationship between CPU use and GPU use. As you get that GPU well used and well fed with data, the CPU has more idle time. So that’s simply waiting for a GPU job to finish. Like any loosely coupled multiprocessing scenario, at least some of the overhead is now spent in communications between the two, and there will be short gaps based on that protocol, too. It might turn out that some CPU/GPU combinations are an ideal match. But in most cases, you’ll see at least a small drop in CPU utilization, even if the GPU never runs much above 50% use (about where I see mine; I have a fairly speedy AMD Radeon 6970).

-Dave

[Shane Etter]

good lord dave— thank you for the time it took to type this out. all good information here.

so the highest i can put threads at is 4. is this normal?
i tried to move it to 8 because i have two quad core xeons (so eight logical cores altogether)

also, my buffer setting was at 128mb. i have 8gb of RAM altogether. should i make it more or less?

thanks for all this!

[Dave Haynie]

Hey.. I type fast.

Oh, if you have a dual CPU unit, you definitely want more threads — at least one thread per core is what I recommend.

I haven’t done a scientifically proper study on the effect of extra threads (eg, more threads than cores). If there’s sufficient stalling while threads wait for I/O, you might benefit from a couple of extras. The main point is, at least one thread per core. If you add too many, you might get into drive thrashing (too many seeks) and also memory issues, since each thread will need some real resources. Sounds like another interesting experiment (damn! I was planning to play with Win8 this weekend, and my new TC-Helicon vocal stomp-box, and I have two unfinished videos in the works, and … ok, maybe not too soon)…

[shane etter] “also, my buffer setting was at 128mb. i have 8gb of RAM altogether. should i make it more or less? “

That’s probably ok.. you have lots of cores, and don’t want to starve them. Rule of thumb is 2GB per core, so you’re ok, but not likely to have tons of extra memory. I have found performance increases going to more than zero, and I found no value on my system beyond 1GB (but I have only six cores and 16GB RAM). You could try a short rendering benchmark and see if you see any differences between 0, 128, 512, and 1024 (eg, 1GB). I’m also not certain how the amount of buffer memory relates to the number of cores… if Vegas is tapping this memory for rendering, which a bunch of us believe is true, it’s very likely that more CPUs want a little more memory.

Vegas has always been opaque on this. As mentioned, I “grew up” dealing with these issues in the audio world. Once Cakewalk added audio, they were very clear about the various buffer settings, so I knew exactly where memory was being used. And, particularly with the primitive PC HW of the 90s, you needed to know those things to tweak up a system. I have Vegas well tuned, but it’s more trial and error… just where I found (and others, working independently) that the RAM preview memory was actually a factor in rendering, too. Like I said, opaque.

-Dave