Hi Rob,

We were discussing a related issue over in another thread about the use of GPUs. This is a quote from the article you linked to:

RapiHD and thus BadaBOOM are both CUDA applications, meaning they are written in C and compiled to run on NVIDIA's GPUs. They won't work without a CUDA-enabled GPU (GeForce 8xxx, 9xxx or GTX 280/260) and they won't work on AMD/ATI hardware. and further, ...Elemental's software won't run without GPU acceleration...

These are the kinds of issues that ISVs like SCS have to face when trying to harness the power of GPUs - works on one platform, not on another. Imagine how pissed off I might be if I bought the latest and greatest ATI card, and found out that Vegas would not use the power of that card, but would if I had bought an NVIDIA card!? I guess the ball is in ATI/AMD's court to port CUDA to their platform.

I was quacking a bit about GPU coprocessing two NAB's ago when AMD seemed like they had something "exciting" to talk about (they didn't). ATI/AMD has had a similar coprocessing project called "Stream" for a while now, and I was kind of hoping at the time that they had something cool to announce.

I see very little chance that AMD'd port CUDA over to work with their GPUs-they have their own product, after all, and CUDA isn't theirs. The ball is partly in NVIDIA's and AMD's courts to provide stable platforms to code for, but it's also in the hands of software vendors to write for both. This is what Elemental seems to have in mind.

I think it's much more likely that you'd see a codec that uses CUDA or Stream than it is for Sony to try to write Vegas to use both. A codec is much more limited in scope than an entire NLE would be. One thing that is promising is that a year from now probably every NVIDIA GPU will support CUDA and if AMD follows suit then software developers might be able to assume that most users will have something that'll do GPU coprocessing.

CUDA and Stream are supposed to be general purpose. You could write code to process video or audio or even do bank calculations, all using a GPU to get the job done.

Rob

"These are the kinds of issues that ISVs like SCS have to face when trying to harness the power of GPUs - works on one platform, not on another. Imagine how pissed off I might be if I bought the latest and greatest ATI card, and found out that Vegas would not use the power of that card, but would if I had bought an NVIDIA card!? I guess the ball is in ATI/AMD's court to port CUDA to their platform."

Heres the thing.. WHO CARES??

I mean cosnider an avid system.. the cost and grunt behind it.. consider a Matrox system.. the cost and grunt behind it..

To harness this power, an editor KNOWS that one will work better than another, that a turnkey system is built specifically for a purpose... whether or not a measly 500 gfx card makes a difference, is a measly 500 bux which can be sold and bought on ebay FFS...

Dont get me wrong, but if people want profession systems to work in a professional manner, than THIS kind of turnkey compatibility per se, is what were going to have to deal with as end users.. NOT as consumers, but as professionals...

Theyre 2 very different beasts and frankly, not many ppl understand WTF that really means...

Id gladly pay 4k for a kick ass vegas system that uses GPU and every other bloody trick under the sun... what one may work with one machine or another is not my concern so long as THAT turnkey system, built for THAT purpose works the way it says it will....

I mean why do u think ppl paid 25k+ for a Digisuite system? It wasnt the be all and end all of PC hardware, but it did the bloody job..
Look at Axio... same thing..
Cmon... get over this bullsh1te compatibility train
Lets get a REAL vegas system happening. If Canopus/GrassValley can do it with Edius, i dont see why Sony.. of all companies.. cant do it with this..

Actually Sony has, called XPRI, very expense but had a lot of hardware at the time. Today, a couple of cells and a couple of 8 cores with 128G memory with a special graphics cards setup, solid state system drives, and 16 Tera storage array could easily be top dog, if XPRI media management system could be intragrated with a souped up 64bit Vegas. PLUS, a pre-load standard production audio library would be a plus.........


Edited to correct spelling of XPRI, ----- too much caffeine, too little sleep and too many warring kids ;-)

It is/was XPRI and if I remember correctly it is/was a purely SD system. (or maybe purely 8-bit? There was some ceiling to it.)

DJ, your point about the appeal of turnkey systems is well taken, but the promise doesn't always pay off in reality. Take your Axio example - we have three and wouldn't recommend an Axio/Adobe combination to our worst enemy right now. In fact we had originally envisioned using them for a feature length doc but had to abandon that idea in favor of a final cut system with no real hardware acceleration at all. The conclusion was that the real time abilities of the Axio cards didn't even come close to real time when you factored in rebuild, crash, and reboot times.

At this point I'd be afraid of a lawsuit if I tried to talk someone into an Axio. Or Vegas, for that matter.

The appealing thing about Stream or CUDA is that they are supposed to turn the GPU into a general purpose processor. There are other APIs for GPUs but these focus on 3D rendering for games. Hypothetically, a general purpose API could give you faster codec, accelerated gaussian blurs, accelerated audio processing, etc.

Vegas, as it is currently designed and marketed, is hardware agnostic. If they stick to that principle then there will never be hardware acceleration for Vegas, but it seems to me that if there was a general OS level interface to the GPU then Vegas and everyone else could use it without explicitly coding for one piece of hardware. Obviously, with ATI and NVIDIA working on their own competing projects, that's not going to happen soon.

I've got to say, after listening to some fine folks at Adobe talk about PPro, it's fairly obvious that the consumer segment is really, really important. I don't think the turnkey market is big enough to support development at some of these companies, at least not without leveraging the work done for the consumer product.

Rob Mack

Actually Sony has, called XPI, very expense but had a lot of hardware at the time.
You can't buy XPRI anymore (as a high-end turnkey system). I believe some version of Xpri is in Sonaps, which is designed for shared storage / collaborative editing for news organizations. It has a hefty price tag (six/seven figures).

XPRI also didn't come from Sony Creative Software / formerly Sonic Foundry. So it's a bit of a different beast. It did support HDCAM capture over SDTI, which allows for native HDCAM editing. It did support HD-SDI too.

2- OpenGL shaders do work on both ATI and Nvidia cards... so there is some common ground there. (Though I believe you still run into issues because the cards do math differently.)

Hardware dependent is great for a post house or other fixed location operation. I personally have to stay mobile and move from hardware to hardware on a regular basis. Field producers have that problem. Schools have that problem. Both are a large market. Until that kind of compatibility can come along, I will cherish the hardware agnostic approach.

I agree, the hardware agnostic approach is much better for individuals and small shops.

On the other hand, I work in such a small shop and we've always gone for hardware-driven systems. This FCP system is the closest we've come to hardware agnostic - all it has in it is a Kona card (and of course it's a MAC, so it's hardly hardware agnostic, but there's not much that's special about it.)

The goal of something like CUDA or Stream ought to be to maintain that agnosticism. Glenn makes a good point about OpenGL being *fairly* generic across GPUs, but OpenGL is also quite specialized for very specific types of graphics workk, I think. The goal of CUDA or Stream is to be very generalized, which is why I keep pointing out that you could use it for audio or even financial calculations.

I think one thing that'd work very nicely for Vegas (and everyone else) is codec packages designed to run on the graphics processor. These could be installed as third party apps and available within the edit application, just like we do now. It wouldn't really require a change to the edit application at all.

Rob Mack

"General" in the GPU sense is relative to what GPUs have traditionally done (graphics). The GPU hardware isn't really suitable for everything, whereas a CPU is reasonably good at everything you throw at it.

Very true, and in fact they touch on this a bit in the article. Never-the-less, the idea of CUDA and Stream is to provide a way to do more than just graphics with the GPU. I think the Stream articles I read a year and a quarter ago were describing it as regular and repetitive types of calculation. Better for pushing a long stream of data through the GPU and running a process on it than it would be for running an actual application like Vegas directly. But the data doesn't have to actually be graphics.

Then again, in this article they mentioned crashing the compressor and taking the graphics display with it.

Rob

Vegas isn't hardware agnostic, more accurate to call it atheistic. Ppro and AE are hardware agnostic. They believe in it but don't care which if any you use. As has been said before what Vegas needs is a Hardware Abstration Layer. That gives you the best of both worlds.
It's only high end systems from the likes of Avid that are truly hardware dependant and accelerated.

Bob.