Vegas does not work with hardware acceleration. Period.
Vegas codecs are VFW, not Direct Show or anything since then, including GPU utilization.

Any further announcements on this subject will have to come from Sony.
A search of these forums will yield you hundreds of discussions on this very topic.

It's just too bad that Vegas doesn't...the rendering speed will knock the socks, and pants off any dual-quad core i7 processor that exists today. Sony is way behind on this....

I found Power Director 8..a end-user video editing program (very limted) that uses CUDA...rendering is insanely fast...

If Vegas annouces support for CUDA (and I'm sure the other big players are working on it), it wil defy the competion with blistering speed.

Maybe in Vegas 10!

Or maybe an updated CUDA friendly codec in the 9.0 b/c/d/e release.

One can only hope.

Once again, the VFW wrapper does not support hardware acceleration in any form to my knowledge. That's what Vegas uses.

A codec that uses hardware acceleration uses a different wrapper, called DirectShow. It would not be recognized in Vegas.

http://www.sonic.com/products/Consumer/CinePlayer/Technology/acceleration.aspx#efforts

I suspect a major re-engineering of the core code would be necessary before codecs in Vegas could offer native support for hardware acceleration in any form. Am I wrong about this?

Musicvid, you are right - Vegas does use VFV as it's method when creating AVI containers (through its AVI API Plugin) - however; this would only be applicable when one is actually creating AVI files - which is not always the case, in fact I create AVI's next to never. It would be nice to see Sony switch to something like Directshow for avi creation - which they should do as DirectX services are being removed from Windows over time (i.e no more DirectSound in Vista).

Other file formats such as AVCHD (.m2ts etc) or MP4 files use something completely different than VFV (plugins from Sony access these codecs and muxers) - so one could think that Sony has the ability to update these formats with Cuda support - after all these are just APIs.

Chris

NVIDIA CUDA-enabled Video Transcoding Applications Roundup:

http://www.pcper.com/article.php?aid=719

That's a good read. There's no need use Vegas to do the transcoding when for a small sum of money one can buy a standalone program that is CUDA enabled to do the hard work.

Even IF Vegas were to be CUDA enabled there's always a limit to how many streams can fit into a hardware device. Also every time you playout the vision the same zillion calculations have to be performed. Transcoding all media once to a CPU friendly codec makes considerable sense.

Bob.

While I agree that there are a few decent apps that transcode via GPU on the cheap - it doesn't address that Vegas doesn't take advantage of GPU rendering.

A 30sec clip can take 20mins to render on my QX9650 CPU, 4GB system, but would probably take under 10min on the GPU. Sure the savings is small, but what about a 2hr movie masterpiece?

I love Vegas Pro, and would hate to see it lose out to Cyberlink Director, Adobe Premier / After Effects all because it decides not to harness the power of the GPU.

Professionals and pro-sumers out there, would you rather render on 8 cores (dual Quad-cores) or 200+ cores (ie Nvidia GT260 GPU)? Where time is money, and money could be used to create more content - it's a no-brainer that a faster rendering solution should be worked on. And if it's re-coding the architecture to involve CUDA, they'll be in a better market position for it.

Has it ever occurred to anyone that the issue may be with Microsoft? If VFW used GPU co-processing, then the "problem" would be gone. Changing Vegas to another video platform would essentially be a complete rewrite of the code, and the price of the product would have to be a higher to recover the cost of the (re)engineering.

Of course, then you will be locked into specific hardware and upgrades to one may require upgrades to the other. And if your GPU manufacturer goes belly up,?

Be careful what you wish for.

The wedding video business is moving toward Same Day Edits to be shown at the reception. This requires editing, render and playback within a short timeframe. Good organization helps, but AVCHD appears to be a good format from a quality standpoint and presents many difficulties in Vegas.

Ralph

You know, back when i did a few weddings, i accomplished playback at the reception using nothing more than a VHS camcorder, a VCR with insert editing, and a television. No software, no computer (well, other than the embedded functions within the camcorder, i suppose), no keyboard or mouse.

Ah, how far we've come.

If you really need same-day edits then you need to build a system that can do the job. You might also need to pick a camera format that works for you, rather than picking a format that doesn't work and then trying to get the NLE supplier to catch up. In other words, know your requirements and then build your system, not vice-versa.

Steve is hitting the nail on the head about this. It doesn't make a lot of sense for SCS to try to build GPU acceleration into Vegas -- if you assume that one of Vegas' main design requirements is that it make use of off-the-shelf Windows features. If Microsoft builds GPU coprocessing into Windows as a standard service available to all applications then you can assume that Vegas will then start using the GPU for coprocessing.

In the mean time, Vegas is quite capable of using codecs and filters that use the GPU without Vegas having to be directly involved.

So what happens when you crash a process on a GPU?

Rob Mack

While a VfW infrastructure might reduce the options somewhat with regards to hooking into all 3rd party offerings. I fail to see how plug-ins and render codecs are precluded from CUDA hooks once the AV data from the final output or track contribution has entered the 3rd party program environment.

VfW is about the termination and hand-off infrastructure. It doesn't say you can't do what you like within your own code.

I hear a lot about developers moving away from VfW and hitting walls and instability issues. Indeed, often the comment is that it is better to invent something better than anything offered on a plate from Microsoft with regard to AV processing and realtime all of the time.

We've seen OpenGL being hooked into 3rd party offerings. That fact only adds to the likelihood we'll see CUDA solutions. Perhaps some of the better ones won't have 'legacy' support for a while or will need frameserving in place to work (TMPGEnc/PegasysInc springs to mind).

Just thought I'd try to calm some of these hot spirited replies. I find Vegas to be quite usable and the fact we have any floating-point support at all tells me that neither directshow nor Vfw are holding Vegas development up.

I'm not saying things aren't perfect for developers to hook-in. Just that I don't subscribe to the belief that CUDA is off-limits where the developer has good reason to implement such acceleration (which gives rise to more QA work to ensure that folks without CUDA hardware can continue to work sloooowly).

Interested in this aspect, & with little real info available, I read the Cuda threads, even though they don't directly effect my current HD 4870. .. that can always change. ;-)

FWIW & AFAIK, the Avid codecs are DS -- won't open in V/Dub etc. Vegas will handle those, as well as several VFW codecs, so I personally think it's bi rather than hetero or the opposite. ;-)

GPU encoding accel is iffy. For comparisons & examples, rendering a very short picvid mjpg avi to DVD mpg2 in Vegas 9 32 (in 7 64), GPUZ shows a very slight GPU involvement of 1 - 2 %. Doing similar in XP Pro SP3 32, I'm normally using AviSynth DS stuff, & I show more usage, sometimes 10 - 12. Using AsVideoConv.exe, or the ATI CCC utility, I get about 12 or so for wmv, but GPUZ didn't even raise a spike a moment ago when I encoded the test avi to mpg2 using AsVideoConv.exe.

At any rate, whether it's Vegas 9, Windows, or whatever Windows support files/processes that's using the GPU, something surely is. I don't know what it's accelerating, whether it's some DX code or off-loading some encoding processing, but, everything I've read & experienced using the 2 encoding utilities for ATI cards, it would seem to be the encoding that's given a boost. Whether it is or not, as long as something's getting sped up, fine with me! ;?P
----
"I found Power Director 8..a end-user video editing program (very limted) that uses CUDA...rendering is insanely fast.."

Cyberlink encoding, however fast, also fails any quality tests pretty badly. They have been working on GPU acceleration for playback for years, & doing a fair amount of OEM work in that respect, but they've to my knowledge never put out any code that's good at encoding. Tempering that statement, they have done code for ATI using their Theater chips for hardware mpg2 encoding, so the know how may be there -- just not readily available in any products.
-----
"Other file formats such as AVCHD (.m2ts etc) or MP4 files use something completely different than VFV ... so one could think that Sony has the ability to update these formats with Cuda support "

MS has been trying to get rid of VFW for over a decade, but it's easier to code than DS, & less trouble prone, given that Direct Show normally requires several files working together in concert, & they all have to be compatible. Currently my understanding is there is no cost involved using Cuda itself, but that could change. There are potential licensing issues from whomever controls whatever format was going to be converted. Having said that, it's certainly possible for any coder or groups of coders or Sony to enable GPU acceleration for encoding &/or decoding most any video format.
---------
"AVCHD appears to be a good format from a quality standpoint and presents many difficulties in Vegas."

It basically, unequivocally, @#$@%&*!!! stinks. ;-)
It's a delivery format, with high processing overhead. It does however make smaller files, which are easier/cheaper to move around & store.
------
"It doesn't make a lot of sense for SCS to try to build GPU acceleration into Vegas... If Microsoft builds GPU coprocessing into Windows"

Far as I know to a slight extent it's there in 7, though 7's not a requirement Crunching numbers with the GPU was most popular with practical applications on Wall St., which I don't think is innovating all that much, or at least talking about it currently. :-( Don Graft implemented Cuda in one of his apps, has gotten good - great reviews for it, & from what I read it was a matter of learning how it works & doing it... people that are willing to do that are rare -- people that are willing, & encouraged by corp to do so is rarer still.

Far as making sense, as a pro app used by shops with a render farm, no, cause render farms aren't going to have more expensive graphics cards when CPUs are cheaper. On the workstation, it might make a big difference if it sped up editing previews/pre-renders. For home users any GPU accel could mean an awful lot, especially if they already have a good card, so the performance boost would be free. IF there's another DVDA version increase before the next version of Vegas, & if Adobe implements GPU offloading (I think they will), I'd expect Sony to give it a try.

On small projects,(really small), transcoding with Cuda really kicks butt, BUT on really big projects, 3D movement, etc , the benefit in speed become small. If Cuda -type acceleration be done on the "TL" before it hands off to the encoder, we could see massive improvements in 3D tracking,etc, speeds. So for now, having an NLE that can managed 8 to 12 cores, with 12gigs plus, fast disks, ................ are more of a benefit than just rendering/transcoding side. ;-)

"If Cuda -type acceleration be done on the "TL" before it hands off to the encoder, we could see massive improvements in 3D tracking,etc, speeds."

It might be possible. The advantage of accelerated DX code that everyone thinks of 1st, & relative ease of implementing GPU accel, might be why at this stage we've seen these few practical applications, like encoding. But that's just the tip of the iceberg.

GPUs & CPUs are very different -- it's not really: "hey I got this GPU sitting here, doing nothing, so why not?" The question is: "What can a GPU do better than a CPU?" In the case of Vegas (or any software), developers have to see what processes could be sped up if performed by the GPU, then figure out how to integrate that with hopefully multiple threads for multiple cores. And if there's more than one way to code the same functions, in the past they used whatever method was best optimized for/by the PC's CPU -- maybe another routine, suited for the GPUs number crunching abilities would be 10 times faster? Changing that stuff in the code base is no small task.

"So for now, having an NLE that can managed 8 to 12 cores, with 12gigs plus, fast disks, ................ are more of a benefit than just rendering/transcoding side. ;-)"

No question!
Especially since the GPU encoding end of things has focused on speed rather than absolute quality. And especially since this is still pretty new, & not part of the established methods coders use. It'll trickle down eventually -- off-loading code processing to the GPU was very specialized, & with folding @ home functioning for quite a long time, ATI's still getting the kinks out of their new GPU enabled transcoder.

Well, optimization of coding for multi hardware configurations is what "kills" most apps. Many people mis understand what threading about, its more a server, general app without advance complex instructions. Threading assumes that the instruction being executed leaves some internal AUs and other internal cpu hardware available, permitting sharing of internal resources and not dominating the L1 data cache. BUT Most "new" media instructions dominate the L1 data cache, leaving little for another thread to use without serious timing penalties. While the L1 instruction cache is available and idling ;-) getting data to start the next instruction for another thread takes a "beating" ; increasing more hardware to increase access, can increase instruction execution time. That is why certain design patterns exist in cpu product lines. Sun's new cpu offers 16 threads per core but very slow clock speeds,.......etc.. all the way to IBM Z10 "book" cores(very fast)..... and my favorite the "Cell".............. I like the q6600 to I7's but the L3 cache problems limit it with certain working environments.