[Dave Haynie]

[John Rofrano] “OK, I got my Quadro 4000 back from PNY and did the same tests last night and it does not look good for NVIDIA’s CUDA with Vegas Pro. The Quadro 4000 is in my fairly new Intel Core i7-3930K Sandy Bridge-E 3.2GHz (6-core/12-threads) so the CPU times are better than my 2008 Mac Pro 2 x 2.8 GHz Quad Core Xeon E5462 (8-cores/8-threads) but the GPU renders were actually slower on the NVIDIA Quadro 4000 than the ATI Radeon HD 5870! “

Not even slightly a shock to me… I’ve been largely against the “professional” cards for more purposes. Ok, the way the story is told, you have GeForce, totally optimized for gaming, and you have Quadro, which is totally optimized for 3D visualizations: scientific computing, mechanical CAD, etc. On the surface, you get a professional warranty, lots of RAM (which you need for that whole 3D thing), much faster 64-bit OpenGL primitives, and often just one slot used.

But dig in a little, and you’ll usually find that the pro cards are under powered. The Quadro 4000, for example, is based on the same architecture as the GTX4xx series, and it includes only 256 CUDA cores. The GTX580 is based on a newer version of the Fermi architecture with a wider and faster memory bus, 512 CUDA cores, and sure, only 1.5GB RAM vs. 2GB RAM… not important for video.

Then you dig a little deeper and find out some darker secrets. Now sure, part of what you’re paying for with a Quadro or FirePro (AMD pro card) is much better OpenGL support. There’s not much point in spending time on making OpenGL perfect when your main users are gamers. So in part, the professional series fund this effort at nVidia and AMD. And so, while OpenGL does get back-ported to consumer drivers, it’s not a priority. Plus, you don’t have pro driver upgrade cycles based on tweaks for the latest game release. So there is a valid reason to select the pro series.

Though it always struck me that it was weird, since the pro cards are pretty much always using slightly older versions of the same architecture as the standard cards, why they performed better on some 64-bit OpenGL primitives. Maybe the GPU designers took the consumer chips, added some special magic, and simply built a faster card?

Well, no. What actually happens is that the consumer cards have a few of the 64-bit OpenGL primitives intentionally crippled. This became apparent when the GeForce 4xx series came out, and actually performed much worse on some selected CAD visualizations than the GeForce 2xx cards. Further analysis showed that this kind of slowdown was OpenGL specific… performance on similar things in Direct X favored the 4xx, which is what you’d expect. Some folks coded work-arounds and found that using OpenCL or multiple OpenGL operations, the GeForce cards were performing as expected. I don’t think 64-bit OpenGL gets used for video all that often, if ever, but that’s another functional issue for the GeForce cards, even if it’s technically only “a simple matter of software”.

And it doesn’t stop — and I really didn’t mean to just pick on nVidia, but they seem to be asking for it. We’ve more or less documented here that OpenCL performance is kind of bad on nVidia Kepler cards like the GTX6xx series. In fact, GTX5xx will beat GTX6xx on most any Vegas benchmark that’s using OpenCL. Not sure about CUDA. Checking on this a little more, it seems to be pretty suspect. The whole OpenCL/CUDA things, General Purpose GPU use (GPGPU) was kind of a hack early on. But with nVidia and AMD both released new architectures with GPGPU given marquee billing. That’s Kepler, if you’re nVidia. And yet, they GTX6xx series dropped in GPGPU performance.

So a bunch of people are asking out there in internet land: is it just a bad version of OpenCL on the Kepler cards? Maybe they haven’t fully optimized their OpenCL compiler for Kepler? Or is this another instance of intentional crippling?

Also, check this out: https://www.tomshardware.com/reviews/geforce-gtx-titan-opencl-cuda-workstation,3474.html

That’s a pretty good comparison of GPUs, including the ubergaming GeForce Titan and some of the AMDs, run on “pro” apps using OpenCL and CUDA/OpenGL. The nVidia cards start off strong… then there’s a very obvious flip, about the time they go from 3D video to 3D mechanical CAD. That pretty much demonstrates a problem right in the place you’d expect 64-bit OpenCL to be used. Things go where expected for gaming and CUDA, pretty much (no AMD cards in CUDA, not surprisingly). Once you get to OpenCL, the AMD7970 pretty much wins… the AMD HD7xxx series, dubbed the GCN architecture, is their answer to GPU designed for GPGPU computing, as Kepler is. It’s weird… in a few of the benchmarks, the Titan and even GTX680 do pretty well. But then check out the OpenCL image processing… my three year old, $300 HD6970 does seem to be wiping the floor with the current-year $1600 Titan.

So as an engineer, I look at those benchmark graphs. When the nVidias come out on top, it’s usually the case that the gap between cards isn’t that profound, and even when it is, there’s some logic to it. When you see the nVidias not just lose, but lose by significant margins, that suggests to me that “somethin’s broke”. That could be some kind of flaw in the OpenCL performance. But as with the OpenGL, they didn’t break everything, they just targeted a few operations in the consumer OpenCL, and made them run 1/10th normal speed or whatever. Could this be a similar thing here for OpenCL? And why … oh yeah. The Tesla series. nVidia gets over $5,000 for a Tesla K40, which uses the GK110B chip has 2880 CUDA cores @ 745MHz and 12GB memory. The $1600 Titan has a GK110 chip with 2880 CUDA cores @ 889MHz and 6GB memory. I do detect a familiar pattern here… how could the Titan NOT outperform the K40 on OpenCL benchmarks?

-Dave

[Dave Haynie]

[John Rofrano] “There is the Options | Preferences | Video | GPU Acceleration switch for the timeline. Vegas Pro uses CUDA for NVDIA cards and OpenCL for ATI cards so one switch toggles whatever you have. “

That’s actually a point of some confusion out there. Vegas itself is only OpenCL, not CUDA per se. nVidia these days says CUDA includes OpenGL, so they might technically be correct saying that a nVidia card is using CUDA under Vegas. But it’s only the OpenCL part of CUDA.

For some CODECs, like the often mentioned MainConcept AVC CODEC, you are selecting between CUDA and OpenCL acceleration, and that only on very specific chips. It should be possible, for example, to benchmark a nVidia card NOCPU, CUDA, and OpenCL. But MainConcept will just ignore the acceleration if your card’s chip is not specifically on its list of approved devices. So no OpenCL for nVidia in the CODECs. But only OpenCL for nVidia in Vegas proper.

-Dave

[Dave Haynie]

[Mike Kujbida] “A few folks on the Sony Vegas forum are really liking the new AMD R9 290 card. It’s not the cheapest (nor the most expensive) but the reviews so far have been very positive.
https://www.hyperactivemusic.com/vegaspro/vegaspro.html is a chart comparing the performance of this card to others from AMD and Nvidia. CPU specs are included making this a good chart.”

That’s a pretty interesting chart. It’s clear from the results than the R9 290 is not getting OpenCL support from Main Concept (as expected), but it’s outperforming my HD6970 on the part of the rendering pipeline internal to Vegas, where the GPU is going to help. This also proves my theory that the nVidia GTX580 might sometimes be faster than the HD6970…. I benchmarked against the GTX570 when I bought mine, both being in the lower $300 range back when Vegas 11 came out.

-Dave

[Dave Haynie]

[John Rofrano] “BTW, Have you run Sony’s “Red Car” test project? My 8-core 2008 Mac Pro + Radeon HD 5870 beat the render times of all the servers and cards in the test (even the Radeon HD 6870!!!). I’m quite happy with my recent eBay purchase. 😉
“

Not a surprise, that result. AMD changed around their naming a little between the 5xxx and 6xxx series. Under the 5xxx conventions, the 59xx are all dual-GPU cards. Vegas will only use one GPU at a time, so these don’t buy you anything. And even today, they’re pretty expensive.

When the 6xxx series came out, they released the HD 6970 as the fastest single-chip card, and the HD 6990 as the only dual-chip card. It’s also the case that nearly all of the 6xxx series is based on the same VLIW5 architecture used in the 5xxx series, but die shrunk (smaller, cooler chip) and in some cases cost reduced (slower clocks, narrower buses). The HD69xx series use a newer VLIW4 architecture (yeah, that’s correct… the number isn’t the edition, but how many operations happen per core in one cycle), it’s not directly based on the HD5xxx chips. Still, the HD6970 and the HD5870 are directly comparable, in each case the fastest single-chip GPU of their generation (well, from AMD anyway).

-Dave

[Dave Haynie]

[Paul McDermott] “The problem is when I sync my camera audio and the MP3 recorder audio, the sync works fine for about half a minute but then an echo appears.

As the recordings go on they become more and more out of sync.

The on camera audio and the Mp3 Recorder audio sound fine individually but seem to be playing back at fractionally different speeds.”

This was a problem even for expensive recording devices, early on.

When you record sampled audio, the expectation is that you’re going to record at 48kHz or 44.1kHz samples, or whatever. The reality is that there’s a little crystal in that device, usually a quartz oscillator (even worse when it’s not) that has an accuracy rating. Typical crystals found in PCs and MP3 players, perhaps 100ppm (parts per million). At the edges of that accuracy, you’re adding or dropping one 24p frame every 6.9 minutes, versus a perfect clock (I wrote about this awhile back here. And cheap consumer gear… sometimes they use ceramic resonators, which might have 1/5th the accuracy, 500ppm or worse.

Even companies you might not expect have had problems in this. Zoom (aka Samson) are pretty well regarded in the DSLR video world as the go-to gadget for “recorder on the flash shoe” devices (my H4n also has a 4-track “portastudio” mode, which makes it useful for recording song demos on vacation). But the first generation of these didn’t lock up for more than about 10 minutes… pretty terrible. But also not something every DSLR shooter noticed, since the early cameras only shot for ten minutes or so.

But if, like me, you used audio in other ways, you noticed this. In shooting events, I like lots of cameras, so I always have one audio recorder on for the whole time, and use that as the sync track for everything else. That used to be MiniDisc, I switched over to flash recorders after that first generation got it wrong. Of course, most of these manufacturers were thinking “audio”. They expected folks to use these instead of tape decks. They didn’t expect all the love from video people. So today’s hold sync pretty well. But when it’s broken, it’s broken.

Until you fix it, anyway. There are two techniques. Once you figure out the direction of the inaccuracy, you can time-stretch the recorder audio to match the camcorder audio. Most DAWs and I think Vegas comes with “time stretch without pitch changes” type plug-ins. The other is to slice up your recorder audio at short intervals, always at zero crossings of the audio. If you use a tool like PluralEyes to sync, that’s not all that much trouble.

That CAN also be done by hand. I did that on a few music projects, when I had multiple takes of a performance but without a common time base (metronome, drummer playing to a reference track, etc), and really needed both takes. Success at nearly hopeless tasks like this are what make me seem so laid back and zen these days …

-Dave

[Dave Haynie]

Oh.. that’s interesting. The name of the company he’s recommending, which I won’t say here for soon-to-be-obvious reasons, triggered The Cow’s “bad words filter”, and sent my first post to a moderator. That’s not actually that much of a shock. Read the details, if the post gets posted, but this guy is basically just trying to sell a program, he doesn’t know what he’s talking about in regard to Vegas.

-Dave

[Dave Haynie]

He’s basically claiming that Vegas doesn’t handle AVCHD video very well. Which is of course false, as long as you have a video-editing-worthy system.

Signs that he doesn’t know what he’s talking about include:

Actually, Vegas can render M2TS to AVI HD or WMV HD. However, the long rendering time will make you crazy when you have a large file. And sometimes choppy rendering from M2TS to AVI, MOV, or WMV will be very annoying.

Ok… AVI isn’t a format, it’s a container. There are only a few things, Cineform perhaps, that live in AVIs and would be a reasonable target for any intermediate format. I assume he’s got a weak PC and needs to find an intermediate CODEC. Worse yet, he’s mentioning WMV. No one with half a clue about video editing would chose WMV for editing… or much of anything else. So this pretty much suggests, all by itself, that the dude’s not worth listening to.

Not to mention, in a literal sea of Windows-based transcoding programs (including freebies like XMedia Recode) he’s recommending a Mac-based commercial transcoding program. Which is apparently also available for Windows. Checking this guy out, and the application, is seems that all he ever does on Experience Project is write about converting one format to another using Aunsoft. Given the particulars of the English in his article vs. their website, he might actually be Aunsoft.

So, the GH4 is going to give you H.264/AVC in your choice of wrappers and 4K versions. The wrapper probably doesn’t matter all that much, unless they’ve munged the specs on one of them… not likely, but I’ve seen cameras that did. Expect 4K video to run about 1/4 the speed of HD video on your PC. Do you need to use an intermediate format? Maybe. I’d like to be joining that experiment, but the GH4 is not in my cards yet, though I am drooling a bit at the quick rise of 4K.

-Dave

[Dave Haynie]

[Rich Kutnick] “GPU OFF: 4m20s to render. CPU: 25%, GPU 0%

GPU ON: 4m23s to render. CPU: 27%, GPU: 25%

Again, this is a virtual draw!! So what is this highly-touted graphics card that so many of you rave about doing for me? Apparently nothing!! Is there a problem with the card? I doubt it! Is there a problem with SVP 12? More than likely!! So is it just a crap shoot, PC to PC, that in some computers this card works great in while others it suffers in? At least nothing is being slowed down like it was with my Nvidia GTX 560.”

What that’s telling me is that neither the GPU nor the CPU are the bottleneck in your system. You SHOULD see nearly 100% CPU utilization when you’re rendering without the CPU… maybe a little less with the CPU. But you’re using one of your four CPU cores for that render. That’s a very, very strong suggesting that you have a single threaded plug-in or something that’s blocking any other efforts to run Vegas on all four cores of your system.

Keep in mind that specific plug-ins, hard drive speed (particularly seek speeds), etc. are also potential bottlenecks. When a system is correctly set up, they will not prove to be dominant enough to be bottlenecks in most cases. But they certainly can be. If some other thing is limiting your performance, it’s setting the render time. Nothing you do to your other hardware will have much effect.

So what would I recommend? Try the Red Car demo… that’s not going to use any thread-limited plug-ins; we know this project can run fast on a system with a fast GPU, and that it will run slow otherwise. Make sure you have Vegas set up to use at least 8 threads (four real cores, 8 virtual cores on the i7-3820… if you only see four, you have to enable multithreading in the BIOS). Make sure you’re not running low on RAM during the render… swapping to HDD would be another bottleneck that doesn’t change with your CPU or GPU. Also check that Vegas is the only thing running, you’re not devoting those other CPU cores to something evil (emulators, etc) that could actually take over the whole core. Your CPU use, before launching Vegas, should be low, like around 3% or less.

Try that stuff, report back with some CPU/GPU numbers. Maybe you’ll see some better stats, or maybe the collective Vegas wizards here will have a little more to go on. Your system should be fast.

-Dave

[Dave Haynie]

[Rich Kutnick] “It is VERY frustrating, to say the least, when one purchases two video cards (one from each major graphics card manufacturer) that surpass the minimum specs listed by Sony to work on SVP 12, yet observes that the GPUs in these cards are grossly underused.”

Where a video card actually helps you out is part of this problem. That why I’ve always posted benchmarks based on Sony’s “Red Car” project. For one, that’s a very good way of showing what a GPU can do. Is it typical? Only if that’s the kind of video you’re editing.

I honestly see a falling off the realtime in playback rarely if ever. But that’s dependent on lots of things. Add a bunch of plugins on even a few video tracks — Neat Video for one — and you can push your smooth video into the “going to stuggle no matter what I do” category. GPUs help for rendering, true, but it can be a mild improvement or something profound, depending on how much it helps the compositing and how well the CODEC uses the GPU.

I was actually kind of expecting the GPU to do less for me when I switched from the AMD 1090T to the i7-3930K… after all, I had a much faster CPU now, and the overhead for feeding the GPU has technically not changed. But that’s not what I saw… as mentioned, nearly a 6x speedup rendering the Red Car demo to Main Concept… both Main Concept and Vegas Options set to use OpenCL. So I’d be shocked if the GPU-related performance from the four-core i7 is any different than what I see.

-Dave

[Dave Haynie]

[Rich Kutnick] “I can buy a NEW ATI Radeon HD 5870 1GB CYPRESS XT GDDR5 DP HDMI STKD_DVI Video Graphics Card for $149 (shipped) on EBay with a 14-day money back guarantee. What do you think?”

Get it. The HD5870 benchmarks out just a little slower than the HD6970 on most of the things I’ve looked up, and occasionally comes out faster. It’s main disadvantage is that it’s more power hungry. Much of the point of the HD6xxx series was lower power, so they did die shrinks on chips that were basically the same as the HD5xxx series, except for the HD69xx, which used a new architecture. But the nomenclature changed a bit too. Prior to the HD69xx series, all of the HD59xx were dual-processor boards… you still pay $600+ these days for an HD5970.

What that means is that the HD6970 was the fastest single chip AMD from the 2009 generation, while the HD5870 was the fastest single chip AMD from the 2008 generation. It actually has a few more stream processing units (1600 at 850MHz) than the HD6970 (1536 at 880MHz).

I can’t promise you it’ll give you what you’re looking for. But I can pretty much bet that on the right kind of projects, the playback performance will be day and night, GPU vs. no GPU. I ran this same GPU on my older AMD 1090T PC, and it had at least as much improvement there as it did on my current i7-3930K system. That means the “red car demo” playing in realtime, rather than dropping to a couple of fps in sections. Obviously, it won’t help for things not OpenCL-accelerated.

-Dave