[Dave Haynie]

[Stephen Crye] “The more I read your posts the more I’ve come to suspect you make your living in IT, not in Video – am I right?
“

As tempted as I am these days to do video fulltime, I do make money at it.. but hardware/software development pays the majority of the bills, indeed. Ages ago, I helped design some of the very first home computers (Amiga 2000, 3000, 4000) that worked well with video. Then I spent another decade or so on digital TV/IPTV related projects. Then it was robotics…. I’m on Wikipedia for some unknown reason if you want TMI 🙂

It never hurts to know how the system works… in fact, in an odd way, that’s why I’m a Vegas user. Ages ago, there was a raging debate on the PC-DAW mailing list, and it was most of the list against Peter Haller.. who was at the time employed at The Sonic Foundry. And Peter was correct. I put up a post that completely explained why he was correct. The list shut up… and a couple of weeks later, I had gratis copies of Vegas 1 and Acid 1. A total surprise, too… I was simply helping out Peter because he was right, and also, he had made my life easier writing a couple drivers for Windows NT for some of my music hardware — I more or less jumped at the chance to do repay the favor.

But I digress.

[Stephen Crye] “I have what seems to be a four-core system – at least, utilities like Process Explorer show four cores and four graphs for CPU utilization. Does it do any good to spawn more threads than there are cores to handle them without task-switching?”

It depends on the situation. For regular Vegas, probably not. Not that it necessarily hurts, other than on memory. In a typical multitasking OS, each thread is either running, on the “ready” queue or the “wait” queue. When a particular thread is waiting for some hardware event, such as the completion of an I/O task, communications with the GPU, etc. it’s waiting. When the even that task is waiting on happens, it goes into the ready queue.

Without worrying about priority, all of the tasks on your PC get “round-robin” scheduled on the available CPUs — each gets a slice, more cores means you have more getting scheduled at the very same time. There’s very little extra overhead for this, other than the memory needed. Most of the system tasks will use a tiny bit of CPU … your performance monitor probably shows 1-2% after a clean boot, with no applications up. Maybe less.

So Vegas can get all the rest, when it’s the only program. If it’s written efficiently (which I think it is), there’s a separate process or thread that’s worrying about disc I/O, so each rendering thread is kept pretty busy — that’s why Vegas can hit a 95%-ish processor utilization when all goes well.

As a result, I don’t think extra rendering threads necessarily hurt you, but they probably don’t help much. The reason they would help: if there was some inherent delay that wasn’t hidden by pipelining (breaking up each major part of a process into a series of processing stages, some of which can then run at the same time — all modern CPUs handle instruction decoding and execution in a similar way), that would open a window of free CPU time, which you might close by adding threads.

On the other hand, we see free CPU time when the GPU is helping out. My guess is that there’s a GPU queue that become the bottleneck here, and adding additional threads doesn’t really improve performance. That’s what you want — the fastest device in the system should be the bottleneck, that’s how you ensure you can’t drive the system any faster. I’ve done a bunch of benchmarks on Vegas + GPU, but I didn’t think about this one until writing about it here recently.

Maybe I’ll give it a shot…

-Dave

[Dave Haynie]

That pretty much makes sense. For any use of a coprocessor of any kind, there’s a certain overhead. Vegas is running along, and it hits the point of making a decision: use the CPU, or send to the GPU?

When you select the CPU, it’s “right there”.. the code is written in native CPU code, it executes directly, the CPU’s doing the execution, so other than dealing with multithreading (at some stage in a rendering pipeline, there’s likely to be a task that has to wait for all N threads to be done before it goes on… this is real multitasking, so the “wait” doesn’t actually take any measureable overhead).

For the GPU, it’s much more involved. That same problem is now described in a set of CPU code and corresponding OpenCL instructions. The OpenCL stuff is all high level, and it’s essentially compiled for the GPU being used. It’s even possible that the flow for any given stage is less optimal for the CPU part of the work than it might have been otherwise — the presumption is that you have GPU and CPU at the same technology node. Which means, for the stuff the GPU can do, it’s way, way faster.

So the OpenCL code and data is sent off to the GPU. The CPU is now waiting (again, virtually no overhead) for the GPU to complete. If there’s additional CPU work to do after the GPU task is launched, the CPU can do it… but it’s likely that, at least for any given task, it’s one at a time. So your main rendering threads wind up waiting on the GPU at some point… with perhaps little or no CPU work to do. Not all the time, but sometimes.

I pretty much expected this, and I see it. My GPU and CPU are about the same tech node (AMD Radeon HD6970 GPU and AMD 1090T CPU), and I definitely see my CPU use percentage drop from 90-100% down to 50-70%, give or take, on a typical GPU render.

-Dave

[Dave Haynie]

That pretty much makes sense. For any use of a coprocessor of any kind, there’s a certain overhead. Vegas is running along, and it hits the point of making a decision: use the CPU, or send to the GPU?

When you select the CPU, it’s “right there”.. the code is written in native CPU code, it executes directly, the CPU’s doing the execution, so other than dealing with multithreading (at some stage in a rendering pipeline, there’s likely to be a task that has to wait for all N threads to be done before it goes on… this is real multitasking, so the “wait” doesn’t actually take any measureable overhead).

For the GPU, it’s much more involved. That same problem is now described in a set of CPU code and corresponding OpenCL instructions. The OpenCL stuff is all high level, and it’s essentially compiled for the GPU being used. It’s even possible that the flow for any given stage is less optimal for the CPU part of the work than it might have been otherwise — the presumption is that you have GPU and CPU at the same technology node. Which means, for the stuff the GPU can do, it’s way, way faster.

So the OpenCL code and data is sent off to the GPU. The CPU is now waiting (again, virtually no overhead) for the GPU to complete. If there’s additional CPU work to do after the GPU task is launched, the CPU can do it… but it’s likely that, at least for any given task, it’s one at a time. So your main rendering threads wind up waiting on the GPU at some point… with perhaps little or no CPU work to do. Not all the time, but sometimes.

I pretty much expected this, and I see it. My GPU and CPU are about the same tech node (AMD Radeon HD6970 GPU and AMD 1090T CPU), and I definitely see my CPU use percentage drop from 90-100% down to 50-70%, give or take, on a typical GPU render.

The clear observation here is that, if your GPU can’t solve the problem considerably faster than your CPU, it’s not worth using. At least, not if Vegas is the only thing using significant CPU time on your PC.

It’s possible in time, they can improve the pipelining of this. Assuming there’s enough CPU work to do when the GPU is fully engaged, deepening the rendering pipeline can let the CPU jump ahead to the next block of work while also waiting on the GPU to finish what its been given. This is not likely to be the first generation result of Sony’s current rendering pipeline. Though I should take a look at running extra threads — I have six cores, so I enable six threads. Would 9-16 allow a better use of the available resources, knowing that there will be CPU cores sitting there doing nothing? Something to investigate.

-Dave

[Dave Haynie]

[Robert Reister] “Yes, I set the project properties to widescreen, the preview panel is widescreen, and yet the video plays squished (as a normal 720×480). “

If you’re seeing the video playing full height, but horizontally “squished”, it sounds as if the camera isn’t correctly tagging the file as 16:9. This is metadata — the visual difference between 16:9 and 4:3 is obvious. But the data is identical; the only difference is how it’s interpreted by your player or editor. The squish tells you that the video is tagged at 4:3, but as it’s horizontally squished and vertically full height, it’s clearly 16:9.

If this is the case, set up a standard DVD 16:9 template. Drop the video onto the timeline. Go to the video clip, right click to get the context menu. Go to Switches, de-select the “Maintain Aspect Ratio” option. Alternately, don’t do any of that. Right click on a clip, select “Properties”. When you get the pop-up, go to the “Media” tab, and look for the Pixel Aspect Ratio setting. It ought to read 0.9091 (NTSC DV), which means it is, indeed, being tagged as 4:3. Change this to 1.2121 (NTSC DV Widescreen). Click “OK”. See if the video looks better.

If you see the video with black bars all around, or top and bottom with a horizontal stretch, you have a “fake” 16:9 video. Some DV camcorders could actually make a good pass at “real” 16:9 video. I had an old Sony camcorder that actually used the extra pixels on the side of the sensor, otherwise used for digital image stabilization, to shoot a larger image for 16:9. Others simply crop a 16:9 windows out of the 4:3 image. When they do that, some will record a true 16:9 image, others will simply letterbox in 4:3. When you see black bars all around, you’re in a letterboxed 4:3 video clip. You can crop this, using the Event Pan/Crop tool, but it’s going to be low quality.

-Dave

[Dave Haynie]

Maybe it’s entirely unrelated.

Did you take out the new graphics card and drop the old one in? Did you get back to that standard of performance?

In any tech situation, it’s useful, every now and then, to revert back to “what worked”. I’ve done this in Vegas projects that got weird, I’ve done this in electronic circuits (via FPGA) and software that got weird, etc. It’s not always possible to go back to yesterday’s thing and step though the changes, one by one. But you can at least get a sanity check.

I know of no good reason that changing the GPU, yet leaving the GPU acceleration off in Vegas, would have ANY effect on Vegas. Ok, if you have OpenGL plug-ins, perhaps. But other than that, up until Vegas started adding GPU acceleration, your graphics card had virtually no effect on performance. None. If you get slow by the simple existance of two completely different graphics cards, both when shut off… I think something else changed, and that something else is your problem.

Do you have Vegas 10 installed? How does its performance compare? It’s not even going to know about any ATi card installed, and unless you’re rending to AVC from the Sony CODEC, it doesn’t know about your nVidia card, either. That’s another sanity check I would have run (I always keep an older version or two of Vegas around, particularly in the buggy modern times).

-Dave

[Dave Haynie]

I think you need a little sanity checking first. Your i7 system should be noticably faster than my AMD 1090T system. And as I think it’s been repeatedly pointed out, you don’t get much if any GPU acceleration just playing a single video track.

Let’s see here. I have Vegas 11 open now, I’m doing nothing but playing a single track, 1080/24p straight out of my HMC40, in Best/Full mode. It’s playing perfectly, GPU acceleration enabled. I see 25% use of the GPU, 30-40% CPU use. Turn off the GPU, restart Vegas, I’m still seeing perfectly full quality playback, but the CPU use is now bouncing between 40-60%. This is Vegas 11/595, the AMD HD6970 GPU, witg Driver 8.911.0.0 (10/25/2011… probably a bit out of date, but it works).

Now, if you’re playing video in an accelerated player on the desktop, the GPU makes a much more dramatic difference. That’s because these players work with Microsoft’s DXVA 2.0 video acceleration APIs, which are apparently only good for playback. I can easily play back 6+ full HD tracks without glitching using players, which it’s pretty obvious that the CPU alone won’t do two of them.

If Vegas isn’t preforming at least as well on an i7 system, something is seriously screwed up, regardless of the GPU. Make sure you have enough RAM (I have 16GB, but 8GB is plenty), I’m running 64-bit Windows 7, fully up-to-date with patches. 64-bit is a bonus for any kind of video work, and I’d claim mandatory for HD, and for a GPU card that’s got 2GB of RAM to map. Don’t put too much RAM in the Vegas preview buffer unless you’re actually using it — Vegas can get weird with more than like 1-2GB there.

I have basic SATA HDDs… a 1.5TB C: drive from Seagate, and a WD “Green” 3TB drive as my main working drive. SSDs are nice for really quick boot times, but they have nothing really to do with runtime performance, and they’re usually horrible at write performance. At best, an SSD on C: shouldn’t be an issue, and it’s never an issue anywhere else for simple playback.

I guess it’s pretty obvious, but anyway, you should run Windows task manager and a GPU monitoring tool like GPUShark, which will let you kow at least where your CPU cycles are going. If you have nothing else running on your system, GPU or no GPU, you’re plenty fast enough to play back full HD video in full quality mode, raw track, no plug-ins, just as a baseline. When this isn’t happening, something else is going on in your system. If the system’s loaded down, see where the CPU is going. Is your GPU getting used at all when you have it enabled, or not? Are all cores on your PC active when running Vegas, or do you see only one getting used (you DO have Vegas set to use them all, right?).

Anyway, you definitely need some sanity checking here. While what you see may be in a weird way related to the GPU, I don’t think that’s the primary problem, when you’re seeing the same slowdown with acceleration disabled in Vegas, and you have a very fast PC.

-Dave

[Dave Haynie]

Shawn-

That’s what I did, and I’d do it again in a heartbeat, so sure. The one caveat is “other software”. Some GPU-accelerated software out there is CUDA-only, not OpenCL. So it won’t get any help from the AMD GPUs, you need a nVidia. None of that is critical (though I do use Neat Video, and that’s one of those plug-ins that’s currently CUDA-only), but something to be aware of.

A few of the posts I did based on my benchmarking last fall when I had both cards:
https://forums.creativecow.net/readpost/24/938278
https://forums.creativecow.net/readpost/24/938615
https://forums.creativecow.net/readpost/24/939139
https://forums.creativecow.net/readpost/24/940373

Some of the Main Concept issues seem to have been fixed in the more recent Vegas 11 releases. I also ran into a few non-Vegas benchmarks that completely crashed or hung up on the nVidia at the time. I have to believe those were driver related, and are most likely fixed by now. The GPU stuff is dependent on drivers in a way that nothing we’re really used to in the A/V world has been, other than maybe audio latency. This is commonplace in the gaming world, but it will take some getting used to.

-Dave

[Dave Haynie]

Not sure whats up here. I run an AMD 1090T PC (6 core, 3.2GHz) which is a bit slower than the i7-2600K, so I’m likely to see more improvement with a GPU.

There’s some overhead to offloading a bit of work to the GPU, or pretty much any loosely-coupled multiprocessing situation like this. I’m surprised it’s necessarily slower than with the GPU acceleration disabled, but it’s understandable you might not get as much of an improvement.

When I upgraded to Vegas 11 last fall, I bought both the nVidia GeForce GTX570 and the AMD/ATi Radeon HD6970… I was looking for acceleration per dollar, nothing more. These are the exact cards.

https://www.amazon.com/EVGA-Superclocked-Lifetime-Warranty-012-P3-1573-AR/dp/B004SMUT70/ref=sr_1_20?ie=UTF8&qid=1335365957&sr=8-20
https://www.amazon.com/Sapphire-DL-DVI-I-SL-DVI-D-PCI-Express-100311-2SR/dp/B004PFVNIY/ref=sr_1_4?s=electronics&ie=UTF8&qid=1335366017&sr=1-4

I actually found that the GTX570 underperformed vs. the AMD on every benchmark I tried… not what I expected from Sony’s info. More to the point, the GTX570 didn’t really help improve things much on my system at all during editing. Not that the HD6970 always did, either — plain playback of a single video track still runs realtime at full quality, but the GPU isn’t helping a great deal here.

The main advantage of the GPU on playback seems to be accelerating various plug-ins and effects, complex projects. The published Vegas “benchmark” project, for example, ran extremely well in Vegas 11 with the HD6970, maybe a little bit better with the GTX570.

At the time, I was doing a bunch of very complex animations, and the HD6970 helped quite a bit more here, too.

For both GPUs, there’s overhead visible when using them. As GPU activity increases, CPU activity will decrease — that’s the CPU waiting on various work offloaded to the GPU to complete. In short, it makes sense, and it’s not a bad thing if you have other stuff going on during a render.

The end result isn’t day and night, but I’m pretty happy with the boost given by the HD6970 for $300… considerably less than it would cost to upgrade to a faster main PC. If I already had that faster main PC, I’m not sure I’d see enough of an improvement to justify the GPU. And it’s highly dependent on what you’re doing with it.

As for the slow-down, no explanation there… it shouldn’t run slower. That sounds like a potential problem with that version of the nVidia driver. Not having used the nVidia stuff in awhile, I can’t really comment… I’d check around the forums, here and on Sony’s site. You can’t be the first one to encounter this issues.

-Dave

[Dave Haynie]

Ditto… bought my HMC40 at B&H, most other gear as well. I should probably just arrange to have a few paychecks a year sent to them directly. They’re a 2.5hr trip from me if I really want to visit in person, but I’d buy from them even if I was out on the left coast.

-Dave

[Dave Haynie]

The DCR-PD170 has three 1/3″ sensors.. they are going to collect more light in the same situation than the 1/4″ sensors of the HMC80. And in fact, it might just be significant. Light gathering is based on pixel size. For a DV camera, the pixels could be about 6x the size — meaning, 6x the light gathering capability, all things being equal — versus an HD camera with the same sensor size.

That’s not to suggest things are always equal. The CMOS sensors in the HMC80, while smaller than those of the PD170, are lower noise at the same gain level. So you get a little of that back. If you downrez to DV, you’ll effectively average out much of the noise, so when comparing apples and apples, the PD170 will still be better in low light, but it shouldn’t be critical.

Incidently, the HMC80 doesn’t have “digital gain”, the gain you’re adding is analog, same as the gain on any camcorder. You’re tweaking the gain on the ADCs that take the analog signal from the pixels and convert it to the digital signal that’s ultimately recorded. It took several iterations to get CMOS sensors working well, but by the time the HMC80 came out (it has the same sensor array as my HMC40.. it’s actually the first good “cheap” shoulder mount camera Panasonic made; all the previous ones were generally lower in quality than a good consumer camera of the same era), CMOS sensors were quite a bit quieter than CCD. So adding a bit of gain is not in itself a problem.

The bottom line: how does you video look?

Now, also consider that among DV camcorders, the PD170, VX2100, and other cameras based on the same tech were probably the best low-light models ever made. Sony didn’t win on features, pretty much ever, but they were ahead of Canon, Panny, and JVC on low light back in that era. The HMC80 is definitely not in the same league. When I need low light video, I use my Canon 60D HDSLR, and just deal with the 10-12 minute recording window. HDSLRs are better at low light than pretty much any camcorder, though of course with many more issues, workflow-wise.

-Dave