WinXP & /3GB switch and Vegas

lewist57 wrote on 9/3/2008, 12:42 PM
QUESTION 1:
Windows XP machines don't work with more than 4GB of RAM, due to the addressing limitations of the 32 bit operating system. As normally configured, Windows XP will split 4GB of RAM into 2GB of usable memory for programs, and 2GB of RAM for the operating system. However, you can insert the "/3GB" switch into the bootup sequence to provide up to 3GB of RAM for programs, such as Vegas Pro 8. For this to be effective, the original program must be compiled as per this note from Microsoft: "To take advantage of the 3 GB available to user-mode programs, the program must be linked with the /LARGEADDRESSAWARE option.". So my question is to Sony, is Vegas Pro 8 compiled such that it can take advantage of the /3GB switch under Windows XP?
QUESTION 2:
How well does Vegas Pro 8 work with multi-core processors?

Thanks!

Comments

rmack350 wrote on 9/3/2008, 1:28 PM
1: Vegas is not Large Address Aware but there is a tool out there that can change the flag in the Vegas executable. If I was running a 64-bit OS I might consider using it because you'd have more memory available for Vegas to use.

In Windows, each application gets 2GB of space and that space is made up of actual and virtual memory. I'm guessing that allowing Vegas to use 3GB under 32-bit windows will result in Vegas using more space in the page file rather than using more RAM

2: Vegas has been able to use multiple cores for a long time now, but there's always room for improvement. You should take into account that some of the codecs Vegas uses are NOT multiprocessor aware. Also, you might find with some codecs that Vegas is processing video on one core and audio on another. That's not really all that earth shaking.

John_Cline wrote on 9/3/2008, 1:28 PM
Question 1: I'm not sure.

Question 2: It works pretty well with multi-core processors, particularly for those tasks which can be executed in parallel, like certain rendering tasks.

JohnnyRoy explained this quite eloquently last April. Here's what he said:

"What people who don't understand how computers do multi-tasking don't realize is that multiple cores can only be utilized when the task has steps that can be done in parallel. Work doesn't magically use all of the cores at 100%.
farss wrote on 9/3/2008, 1:29 PM
Be careful using that /3GB switch. It reduce the amount of memory available to the OS and could be the cause of system instability.

Bob.
lewist57 wrote on 9/3/2008, 1:57 PM
Thanks, I have located the tool, and will try it tonight. According to my research it should work well with my machine, which is a custom dual quad (8 cores) PC with 8 G of RAM and dual boot XP32 and XP64. Under XP32 it should allow up to 3 G of RAM, and up to 4G of RAM in XP64.

With regards to mulitcore processors, you can see with 8 cores, there is the potential for speed up, of course within the limitations of the operating system, and Vegas itself.

Perhaps if I have time I can post some benchmarks to show the relative improvements of more cores/more RAM.......................................if anyone might be interested. I am NOT a Vegas expert, if anyone could suggest a good test to run to show the relative speedup between operating systems, that would be appreciated.
rmack350 wrote on 9/3/2008, 3:09 PM
I wouldn't even bother with XP32 but hacking Vegas to use more RAM under XP64 will probably be fruitful-assuming you really need more RAM.

Vegas under 4 and 8 cores has been talked to death here. I'd say that Vegas can't always break tasks up enough to keep 4 cores busy, so I'd expect that you'll see underutilized cores.

I wouldn't trust paying jobs to a hacked Vegas on Win64. If it crashes you're on your own, but I'll bet it's fairly stable.

Rob Mack
Cliff Etzel wrote on 9/3/2008, 3:44 PM
What tool are you guys talking about to make Vegas Pro 8 large memory address aware???

Cliff Etzel - Solo Video Journalist
bluprojekt | solo video journalism blog
farss wrote on 9/3/2008, 3:56 PM
You guys are playing with fire!
The /3GB switch reduces the maximum non-paged pool from 285 to 154MB and system paged table entries from 106,000 to around 15,000.

Bob.
rmack350 wrote on 9/3/2008, 4:00 PM
Awwwwwww! Now I have to go look it up!

Laatido



Rob
rmack350 wrote on 9/3/2008, 4:02 PM
I'm not recommending the switch. I'm suggesting trying this under win64, which won't need the switch.

But I agree that this is playing with fire. What's the worst that could happen? Several years worth of work flushed down the drain?

Rob
farss wrote on 9/3/2008, 4:21 PM
Anyone silly enough to play with any of this stuff and loose anything because they were too daft to not have things backed up and have an exit stratergy deserves all that happens to them.

My concern is that if I can trust an article in the latest APC that switch can cause an increase in probablility of an errant driver crashing the OS.

Great article BTW. Covers how to run the MS debugger to try to diagnose a crash. Not as daunting a chore as most seem to believe. Also covers using the Windows Performance Monitor to get a better look at what's going on.

Bob.
rmack350 wrote on 9/3/2008, 4:23 PM
Agreed.

What publication is that?

Rob
farss wrote on 9/3/2008, 4:28 PM
Australian Personal Computer, September 2008 issue. Not available online as yet, I think when the next issue comes out then they put last issue's articles online.

Bob.
JJKizak wrote on 9/3/2008, 4:30 PM
That Windows performance monitor in Vista 64 just gets me more confused the more I look at it. Multiple things going on and constant changes then it finally settles down and everything still works and you are staring at the perf mon in bewildered amazment. And I say to myself that I need another computer in parallel to analize the perf. mon.
JJK
Bill Ravens wrote on 9/3/2008, 5:44 PM
I've had the 3Gb switch enabled for over a year without problems. In fact, Avid sends a batch file to perform the 3Gb enable as part of their installation utility. To suggest that you're "playing with fire" is...well...kinda paranoia. Just be sure you set your virtual memory consistent with your system reqmnts. Go for it. It works.
blink3times wrote on 9/3/2008, 5:45 PM
"What tool are you guys talking about to make Vegas Pro 8 large memory address aware???"

I think the easiest tool is here:

http://www.jaloonz.com/2008/04/enabling-large-address-aware-for-games.html

Follow the example they have listed. I'm playing with it right now.
blink3times wrote on 9/3/2008, 6:37 PM
Quite interesting.

I'm running Vista 64 with 8gig ram (no page file) and I have set Vegas for large address awareness. I have also gone into Vegas internal settings and increased "Memory needed by Vegas" from its default (384) to 500. I also set all 4 cores to be active on play back.

What I'm finding is a smoother playback, but more noticeably are the time line thumb nails. Usually when I play the time line the refresh rate of the thumbnails is almost always running behind and often does not refresh until I stop the playback.

I now have over an hour of M2T on the time line (about 175 scenes) and it's not refreshing at all...... because it doesn't have to! They're all there! I can roll the time line from one end to the other with no blank white spots (un refreshed thumbnails) showing up at all!
blink3times wrote on 9/3/2008, 6:50 PM
Well, I will say that if this is any indication of what Vages64 is going to be all about.... then I'm sold already. I just ran 2 layers of M2T without the frame rate changing much at all. Of course I'm in preview mode but still... it's pretty good.

(I should also point out that my viewer size is set pretty big right now too....960x540)
Chethu wrote on 9/3/2008, 9:06 PM
Regarding QUESTION 2 ,

You may not see all 8 cores hitting 100% during rendering , try network rendering on same machine with diffrent ports , I am sure that will keep all 8 cores busy ,
It will be great if you publish the time taken to render with single Vegas and Network Rendering on same machine.

Thx
Chethu
Robert W wrote on 9/4/2008, 5:15 AM
That is a good idea, but it illustrates my point that the multi threading of the software is severely under coded. When you have access to all of the processor arrays and memory regions etc. rendering with multiple cores should be somewhat like a network render, but with very very fast connections, and also the actual tasks working on a lower level.

I hate that shovel and hole analogy, and not just because I think road works are managed very inefficiently. Those 8 blokes down a hole just need proper management. Now if those 8 guys were each of equal ability, and could switch between tasks at a fraction of a millisecond, and were organised so they knew who would do what at any one time, then it would be closer.

I would propose a new analogy for how it should be. This time your render is analogous with a new brick wall. 8 brickies are going to build this wall. But at any one moment any one brickie can transmogrify into the position of the last worker. The first brickie picks up the trowel. The second worker is at the same time transmogrifying into the space of brickie one and putting cement on the trowel as it is being picked up and moved towards the wall. While all this is going on, brickies four and five are making the bricks. By the time the trowel is at the wall, brickie 6 had transported the bricks to the site, brickie 7 has applied the cement and brickie 8 has attached the brick to the wall.

What I am trying to describe is a situation where software is coded to split procedures over the several cores. Coders do not seem to have grasped this concept yet, but it is essential to exploiting the power in these processors. Perhaps it will take a shift in operating systems technology tp get this to happen and have processors treat code in a modular fashion.

The easiest short term solution from where I sit would be to have a version of vegas with three active tasks. The first would be standard vegas application, the second a gui-less vegas engine and the third a development of the network render manager to exploit the multi cores. The multi core management engine would delegate rendering tasks on a much lower level than the network render engine and would allow each of the rendering engines to access each other's memory space. It is a bit of a kludge but it would result in speed ups 8 core systems, even if you had to dedicate one core to the management task.

It is not incredibly well know, but ever since the Pentium Pro II class of processors came out the 32bit series of Intel processors have supported virtual 64bit memory addressing. This can be used to get around the 4gb system and 2gb application limit by swapping in chunks of memory from the extended region into the application's virtual memory address (sound familiar 286 and 386 users?)

It is part of the kernal of Windows 2000, but I am very suprised they did not include support for it in XP. I suspect it is not supported in Vista 32 either which suggests they are keen on forcing people into a migration to 64 bit platforms in the coming years. Maybe it is implementable in Vegas under Windows 2000 and 2003? It would certainly be a big benefit for screen redraws and previews, not mention beign a big aid to multi core processing. I mean that is a big drag at the minute really isn't it? You can have 8 cores but at best they can only work on an average of 256 megs of data per core at any one time.
ScorpioProd wrote on 9/4/2008, 7:40 PM
Newtek also recommends the /3GB switch with their SpeedEDIT NLE. They include the instructions on implementing it in the readme shown during the install.
megabit wrote on 9/4/2008, 11:50 PM
I'm running Vista 64 with 8gig ram (no page file) and I have set Vegas for large address awareness

Well. I got seduced by what Blink says, as I am running Vegas on exactly the same system. So far so good - single instance of Vegas with multi-camera project (single track made from 3 camera takes), full HD, 25p is using now almost 5GB of RAM at playback (well, with a couple of other apps running as well, like IE, Windows Mail etc). The thumbnails either don't need redrawing, or get redrawn very quickly. Changing takes in multi--camera view is a breeze (before the change, it could freeze Vegas for split second from time to time).

I wonder how many instances of Vegas can be run this way without system crashing (didn't try yet, as I would need to set up some page file with this memory usage).

Has anyone tried to allow Vegas even more memory (with 384 being the default, I set it now to 512)?

Oh, and BTW: with my single track created from 3 cameras, can I consider the 3 streams to be open at the same time, or just one (whose take is active at any given moment)? Of course, I'm NOT talking about all 3 previews active (when all streams play at the same time obviously)... I'm asking, because I can get full speed (25fps) playback even with Best/Full !

AMD TR 2990WX CPU | MSI X399 CARBON AC | 64GB RAM@XMP2933  | 2x RTX 2080Ti GPU | 4x 3TB WD Black RAID0 media drive | 3x 1TB NVMe RAID0 cache drive | SSD SATA system drive | AX1600i PSU | Decklink 12G Extreme | Samsung UHD reference monitor (calibrated)

megabit wrote on 9/5/2008, 2:45 AM
No matter what I do to >2GB awareness, or internal Vegas properties - once I move the focus away from a Vegas instance, it takes ages for it to open operational again...

I guess I could set ClosePortsonFocusLoss (or whatever to this effect) to False, but I'm a bit anxious about the integrity of my source video once something goes wrong. Any experience/advise on that?

AMD TR 2990WX CPU | MSI X399 CARBON AC | 64GB RAM@XMP2933  | 2x RTX 2080Ti GPU | 4x 3TB WD Black RAID0 media drive | 3x 1TB NVMe RAID0 cache drive | SSD SATA system drive | AX1600i PSU | Decklink 12G Extreme | Samsung UHD reference monitor (calibrated)

lewist57 wrote on 9/29/2008, 7:22 AM
My machine is dual boot XP 32 and XP 64, and I could not install Vegas Pro 8 under x64, is there a certain procedure to install it for 64 bit systems?
rmack350 wrote on 9/29/2008, 7:50 AM
I think you needed to jump through a few hoops to manually install some needed windows components like Dot net and an SQL engine. Search this forum, it's spelled out somewhere.

Rob