Vegas 11 much faster on my computer with GPU off

[Steve Rhoden]

Good of you to share, I picked up on this in earlier times
when i was testing out version 11….But the thing is, i
personally cannot bother with the fidgeting here and tweaking
there on the matter, i just simply stay with Vegas 10…lol…
My workflow is at peace.

Steve Rhoden
(Cow Leader)
Film Editor & Compositor.
Filmex Creative Media.
1-876-832-4956

[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]

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

[Stephen Crye]

Wow Dave …

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?

What you said about cores makes me wonder about something, the mapping between threads and cores. I’ve always left my “threads” in Vegas at the max, 16, but perhaps this is not wise.

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?

Steve

Win7 Pro X64 on Dell T3400, MultiTB SATA, 8GB RAM, nVidia FX 570, Vegas 10e (and 11) x64 DVDA 5.2(build 133) Sony HDR-CX550V

[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

[Jeff Schroeder]

Dave,

So, I have a decent video card, a GTX 580 with 3GB. But, I have two 6-core Xeons, 12 real cores, hyper-threaded shows 24 cores. What exactly does the 16 core limit in Vegas mean to me? In resource monitor it is not unusual for Vegas to show 280+ working threads. I have my GPU rendering off because I did not notice any benefit.

I would really like to squeeze all I can out of this machine.

Jeff

2-Xeon X5680 @ 3.33 MSI Mobo 48GB DDR3 GTX 580 3072MB 16TB Attached Storage Win7 Vegas 11 x64

[Dave Haynie]

[Jeff Schroeder] “So, I have a decent video card, a GTX 580 with 3GB. But, I have two 6-core Xeons, 12 real cores, hyper-threaded shows 24 cores. What exactly does the 16 core limit in Vegas mean to me? In resource monitor it is not unusual for Vegas to show 280+ working threads.”

I don’t know of any 16 core limit. There’s a limit on the setting for rendering threads at 16 right now, which does seem fairly arbitrary. The setting there defines how many individual rendering pipelines Vegas will run during a render. It’s really up to the OS to schedule these on your hardware.

With all the CPU horsepower, I rather imagine your GPU isn’t helping. I’m not sure how smart Vegas is about GPU load, but it’s at least technically possible that the GPU becomes a bottleneck, if you have a sufficiently fast CPU system. You have 2x as many real cores and 4x as many effective cores (depending on the workload) as I do… very different situation.

-Dave

[Kristoffer Hansen]

On a GPU you often have 500+ cores, and using a pcie x16 bus, you wont have a bottleneck there.

The GPU is build for parallel processing, with a architecture that support the load, with a bandwith of +50GB/s

Add the fact that most new cards use DDR5 ram, rahter than DDR3 as you will find on motherboards

Summ it up, and you will see why GPU acceleration is the future 🙂

Very few software supports it well right now, but its a question of time, since the demand is growing

[Dave Haynie]

[Kristoffer Hansen] “On a GPU you often have 500+ cores, and using a pcie x16 bus, you wont have a bottleneck there.

The GPU is build for parallel processing, with a architecture that support the load, with a bandwith of +50GB/s
“

Well, there are processors and there are processors. I could technically give you a cube with the power of 10,000 Commodore 64s…. but you’d rather have a single high performance x86 today.

Each GPU computing element is very good at what it’s supposed to do. But the job of converting a particular problem, like video rendering, into that compute model, itself takes time (an OpenCL program is basically like a language, and it gets “just in time” compiled for your GPU when you run it).

The other big issue: the GPU can’t solve the whole problem. There’s a communications latency problem: the CPU has to set up a problem for the GPU to work on. Then the GPU gets this work, does it, then it has to tell the CPU, and get more work. This results in a bunch of waiting for each unit. If you had other work for the CPU, that might be ok. But if it’s just Vegas doing rendering, you have to think about what that extra 30-40% CPU wasted for overhead might actually do for you. With a fast enough CPU and just the Vegas process, the GPU absolutely can slow things down.

-Dave