Vegas and x64 Machines

QueenGeek wrote on 10/7/2006, 5:08 AM
Stupid question here. I just upgraded to Vegas 7 and acquired an Athelon64 X2 machine. I'm running Windows XP x64 Professional. Vegas seems to be utilizing both cores. Good. But it is running in x32 mode. Is there any way to get it to run in x64 mode? Video processing is so computation intensive...

p.s. sorry for the multiple "deletes". I just noticed the "edit" button. :D

Comments

JohnnyRoy wrote on 10/7/2006, 6:03 AM
> Is there any way to get it to run in x64

Until Sony introduces a 64-bit version of Vegas I would say the answer is no.

~jr
QueenGeek wrote on 10/7/2006, 6:07 AM
Ugh. I was hoping there was an x64 version and I was just doing something wrong, like using the wrong version....

I guess that begs the question: WHEN? When will they have an x64 version???
JohnnyRoy wrote on 10/7/2006, 6:52 AM
My guess is the answer will be, when the market demand is big enough to warrant the time and money to port Vegas to 64-bit. Right now there isn’t much market penetration. I assume Vista will change all that.

~jr
Cliff Etzel wrote on 10/7/2006, 9:20 AM
I agree with JohnnyRoy - Once Vista 64 hits the market, NLE companies will have to develop for 64 bit. I run Vegas and PPro 1.5.1 on XP x64 and it runs just fine (BSOD's stopped once I upped the voltage 0.1v to my RAM)

Even though it's a kludge type affair, I recently installed Ubuntu x64 bit Linux along with Cinelerra - All I can say is native 64 bit Linux itself puts XP x64 to shame on speed, but since there are no apps that I use available for Linux, it was a test just to see how things worked. Ubuntu has my vote for Linux distro - it works the first time after install with no real tweaking. It's too bad none of the commercial NLE vendors have even a beta for the Linux platform - I am sure that if just one company developed one, the market would be blown wide open. I keep playing with Linux just to keep my feet wet so to speak for the day when there is an announcement of a commercial NLE for Linux.
JohnnyRoy wrote on 10/7/2006, 10:05 AM
> All I can say is native 64 bit Linux itself puts XP x64 to shame on speed,

I have been running Linux since 1995 (i.e., Slackware) when you had to compile your own kernel just to get it to run on your PC. Linux has always kicked Windows butt in performance by a wide margin. No so much now that Redhat and others have added their bloatware but it’s still a leaner and meaner OS than anything Microsoft can ever hope to develop. I too wish Vegas ran on Linux. I would be there in a heartbeat!

> ...it's too bad none of the commercial NLE vendors have even a beta for the Linux platform

Not true. MainConcept has had MainActor V5 on Linux for quite a while. It doesn’t have a big following like Vegas, FCP, or Premiere, but it’s not too shabby an NLE either. In fact if I remember correctly (it’s been a long time since I tried the demo) it had a 3D titler built right in. It has the added advantage that the Windows and Linux versions share the same serial number so you can use both.

~jr
Jay-Hancock wrote on 10/7/2006, 1:25 PM
I run Vegas on x64 and it works great. Memory management is better in x64, which causes Vegas to render better on the most demanding projects where memory usage is really high.

One reason we won't see Vegas in native 64-bit for some time to come is because it's not only Vegas that would need to be 64-bit native. A 64-bit app can not load 32-bit dlls. That means all the 32-bit codecs and plugins would stop working. You can see this by running the 64-bit native version of VirtualDub. The main app runs great, but until you find a 64-bit codec to use with it your just sitting idle wishing you could do something. (I think there are a few 64-bit codecs, but I haven't tried to find them).

Do a search in this forum on x64 and you'll find lots of discussion. A number of threads that I posted have plenty of technical detail, some render test results, etc.
jaydeeee wrote on 10/8/2006, 4:04 PM
Yep, if every app i need (3rd party cvrts,encoders, plugs, ...etc...everything) can't be utilized - then there is no need whatsoever (you need more than just vegas and dvda out there people).

"Memory management is better in x64, which causes Vegas to render better on the most demanding projects where memory usage is really high."

Bah, malarky. In many cases, depending on the app used, render times INCREASED with x64.

and even further (vista related)...

...just more reason there's no way in h*ll I or anyone else with a brain working with a/v/daw will be moving to the RIDCULOUS Microsoft Vista anytime soon.
My wife works for the Vista team, 6 of my friends program and test it....and all I can say is Vista is an OS release for the completely clueless (mom & dads who don't know any better, tired geeks who have no valid reasoning other than claiming ownership and gawking at the inane UI visuals).
Better security? Right, just give it time.
A bloated, pointless OS release. This is STRAIGHT from Vista team members mouths (off the record of course), not just me talking here.

It's release is nearing comical to any discerning users (people who actually have to output content on a daily basis), but should be a big hit to the moronic masses who think overly smoothed UI graphics are the bees knees.

WinXP SP2 (32bit) is going to be more than fine for quite some time.
Cliff Etzel wrote on 10/8/2006, 5:29 PM
Only problem is that Mainactor won't install on x64 Linux - already tried to install - no go...
Jay-Hancock wrote on 10/9/2006, 6:51 AM
Bah, malarky. In many cases, depending on the app used, render times INCREASED with x64.

Malarky? Really? NOT SO!

I had a Vegas 6 project that always died from an "out of memory" error in 32-bit XP. It had lots of stills, a few .mov clips, PIPs, and some other things. 32-bit supposedly allows 2GB of address space for the app, but the 32-bit OS takes some of that away. I ran the same project on the same machine using 64-bit XP (dual boot situation) and it sailed right on through.

I also ran the HDV rendertest from late 2005 that most people couldn't complete due to crashes on their machine (the "out of memory" error again), and I completed it no problem. With the OS not taking address space from Vegas, more RAM was being used (vs. swapfile), which renders vaster (RAM speed vs. Hard Drive speed). I completed it in a render time that smoked what others posted (those who actually completed it).

I don't know what testing you did, or what on your machine caused different results, but my own experience is a far cry from what you call "malarchy". Sometimes I got a slower render, but then I adjusted the Preview RAM and it got faster. More discussion here.

Finally, my experiences are all with XP x64, NOT Vista. I wouldn't even consider putting Vista on my machine.
jaydeeee wrote on 10/12/2006, 2:19 AM
>>>I had a Vegas 6 project that always died from an "out of memory" error in 32-bit XP. It had lots of stills, a few .mov clips, PIPs, and some other things. 32-bit supposedly allows 2GB of address space for the app, but the 32-bit OS takes some of that away. I ran the same project on the same machine using 64-bit XP (dual boot situation) and it sailed right on through.

I also ran the HDV rendertest from late 2005 that most people couldn't complete due to crashes on their machine (the "out of memory" error again), and I completed it no problem. With the OS not taking address space from Vegas, more RAM was being used (vs. swapfile), which renders vaster (RAM speed vs. Hard Drive speed). I completed it in a render time that smoked what others posted (those who actually completed it).

I don't know what testing you did, or what on your machine caused different results, but my own experience is a far cry from what you call "malarchy". Sometimes I got a slower render, but then I adjusted the Preview RAM and it got faster. More discussion here.

Finally, my experiences are all with XP x64, NOT Vista. I wouldn't even consider putting Vista on my machine<<<




Good, I'm sure you won't be jumping Vista soon. Smart man.

Now we have core2 system using x64, and the render times have increased with x64 in comparison it's counterpart sys (same) running x32 with the same projects. The result has never changed.
That is the testing we've done. It's not drastically longer, but it is is longer. Sorry. You're own experience withstanding...but it's malarchy from where I sit.
Not arguing just for the sake of it, I'm really telling you this as you may have sys issues.

And I've never received an "out of memory" error - ever on x32 or x64. From all our SD to HDv projects.
When and WHY are you seeing this? I'd seriously look into that if this is truth.
Jonathan Neal wrote on 10/12/2006, 5:06 AM
You all realize that:

The amount of work required by the Madison team to re-write the application x64 ready >= The amount of work required by the Madison team to re-vamp the existing x32 code.

Madison hasn't really re-vamped the x32 version (in the way that Adobe & Cakewalk have recently done with their applications), but rather, they have seriously refined and generously added to the existing platform. I don't necessarily consider that a lack of innovation, but you must also understand the undisguised dynamics of big business software. It takes a lot of work by the developers to produce such revisions, and I haven't seen a detectable push by our or any organized community for such revisions.

Let me state further that, in the case of Adobe (undeniably big business software), the way to get their attention is through reasonable competition (ahem, Macromedia, or any x86-ready OS X image editing app, ahem). Therefore, I can only offer that you can look towards Cockos Reaper for the competitive innovations you can reasonably expect Vegas to implement forthcoming. That and everything related to hardware, because, frankly, they kick major butt in that department.

Then again, these are only the opinions of a collegian man who has never actually worked for a large corporation, withstanding Ralph's Grocery Co. Oh, and if that's not damaging enough, I thought that the award-winning Waves audio plug-ins were over-rated. =P
Jay-Hancock wrote on 10/12/2006, 8:50 AM
And I've never received an "out of memory" error - ever on x32 or x64. From all our SD to HDv projects.

What do you mean by "if it is truth"? I'm not fabricating this stuff. You may not have personally observed this, but that doesn't mean it's "malarchy" or untrue.

I saw this "out of memory" error quite clearly in pop up dialogs, and it was supported by looking at the Task Manager and seeing how much the pagefile and RAM usage had climbed (i.e. pushing the 2GB total). In 32-bit XP, the crash occurred when the total memory usage (RAM + swapfile) hit about 1.8 GB. In x64 it went up to 2.0 GB on the same project and no crashes. And my system had memory to spare (whereas Vegas did not have address space to spare; an important distinction).

My experience was not due to sys issues. I ran on exactly the same hardware using dual boot, and one OS succeeded where the other failed. I'm not the first to experience an "out of memory" error. Search the forum and you'll see others (though it hasn't been reported for probably a year or more). Ed Troxel (aka jetdv) always advised them (on this and other forums) to break up their project into pieces and render, then stitch the renders together. And that HDV render test from last year caused it too. I found it far more prevalent in Vegas 5 when rendering to WMV. In Vegas 6, memory management got a lot more efficient, particularly with Cineform intermediates.

What causes memory usage to climb? Stills are one of the biggest culprits. I downres them before importing into Vegas, anywhere from 1 to 3 times the frame resolution (depending on whether I plan to zoom them). But if someone were to import 200 stills at a full 6 megapixel resolution, they'd probably see memory usage climb dramatically. I didn't do that, but having a lot of stills and doing pan / crop + track motion and doing compositing on those stills and putting PIP overlays on top of them, well that got my memory consumption up there. And Vegas 6 on x64 got the job done. Plus the nested veg feature, which enabled me to isolate a slide show and prerender it to a new track (inside the the nested veg).