Amount set to dynamic-ram preview DOES affect rendering! :-/

[Matt Carlson]

If your render runs fine for the beginning of it’s run then I would say memory calls are being duplicated (or tripled, or quadrupled)over time but I have done some tests as well and the memory does not see to fluctuate at a rate that could induce such extreme behavior. In fact system memory seems to hold steady. There are two reasons an “all other things being equal” computer slows down. The first is truly awful coding circumstances where a set of instructions are repeated (and because we are talking about modern cpu speeds these repetitions are in the tens of thousands) for one result. I am trying to think of a scenario where a change in available system ram somehow causes this kind of repetition but have not come up with any. The second scenario is a program waiting for the Windows API to get around to managing something. Windows indexing, etc., would have been my go to problem areas as well but that means the amount of memory task manager has been reporting used in these cases is flat out wrong.

That leads us back to CUDA or maybe just straight video card memory being messed with and not released over time. Over the YEARS that Vegas has been discussed on boards knowledgeable people have always said that preview ram has nothing to do with rendering. Somehow with the implementation of acceleration in 11 they now are stomping on the same turf. Several people since 11 came out have received the usual weak response from tech support but on one post I remember reading the person was told that the implementation of graphics acceleration was improperly done in 11. The people seeing strange behavior have all had cards above the 2.0 CUDA implementation from what I have read (while the ones below 2.0 have cards that do not seem to be affected by much but their performance is not making a big difference one way or the other anyway.)

Unfortunately this leaves us with the most likely possibility that a serious logic error is hiding in the Vegas code that programmers are assuming does not exist. One way to narrow down the possibilities is to take out some ram. Reduce your ram down to 4GB and keep preview at 128mb and see how long renders take. If it flies by at the same rate then it would point to Vegas forcing the Windows API to accept a memory limit that is faulty (as opposed to low preview allowing Windows its usual bullying of memory which in this case seems more effective.) If at some threshold of preview ram Vegas is forcing a static set of addresses (on gpu or motherboard memory) and it is not managing it correctly Windows would start to choke possibly trying in blind repetition to find some way around this memory hole.

Obviously all of these things are not what you want to hear. It would be nice if some distinct parameter was just easily fudged and things would slide back in to place. What are the results if you choose to force CPU rendering on the different preview ram scenarios?

[Dave Lozinski]

[Matt Carlson] “Obviously all of these things are not what you want to hear. It would be nice if some distinct parameter was just easily fudged and things would slide back in to place. What are the results if you choose to force CPU rendering on the different preview ram scenarios?”

Matt:

Thanks for the suggestion! I never thought to try that. So I did tonight. Here’s the interesting thing…

1) when I turned off GPU acceleration and had the dynamic ram preview setting at 9000MB, Vegas got up to about 40% before it started to slow down. It still slowed down though. 🙁

2) when I had the GPU acceleration turned off and set the dynamic ram preview to 128MB, this is where things got interesting! Not only did it zip through the video as it does with the GPU, but alas while watching task manager CPU usage was at a steady 50%! In scenario 1, the CPU usage hardly got above 15%!

So again it leaves me with a mystery as to why in this test lowering the dynamic ram preview increases CPU utilization.

When I have the dynamic ram preview set to 9000MB, the memory usage in the task manager and resource manager never gets above 4GB (and my machine has 16GB).

Any other theories to try?

—————————————–
https://www.davelozinski.com
https://www.davelozinski.com/DemoReel/
—————————————–

[Dave Haynie]

[Dave Lozinski] “1) when I turned off GPU acceleration and had the dynamic ram preview setting at 9000MB, Vegas got up to about 40% before it started to slow down. It still slowed down though. :(“

Yeah… it’s pretty typical, so far, to see CPU drop when the GPU is well used. In my experience (6 core AMD 1090T CPU and Radeon 6970 GPU), it’s still well worth the GPU being enabled.

After looking at your results, I did a test of my own. I’m not convinced Vegas knows what to do with crazy amounts of Preview RAM, at least during rendering, but I tried an experiment. I had a bunch of video segments, each about 50min, to render to AVC using Sony’s default Blu-ray 16Mb/s preset. I ran one with 128MB of preview, one with 1GB of preview, and one with 8GB of preview… like you, I have a 16GB system.

So … the curious thing is that it wasn’t at all curious. I did try no preview, and I had done tests in the past suggesting that’s a bad idea for anything complex. Maybe the fast it was basically just a straight conversion, no plug-ins, nothing interesting, colored the result. But I got the same rendering time for each one, just under two hours, with CPU and GPU both kept busy. This is with the very latest build of Vegas 11.. I’m pretty sure I’m seeing higher GPU peaks than I had in the past for a straight conversion (about 50%).

Anyway, each render ran just under 2hrs. That might be useful for you to compare, just where your performance is relative to mine. But it sure does sound like there is something very weird going on in your system. I do agree about your former suggestion in memory.. I NEVER saw an HD render go much about 6GB of committed memory in the past.

I upgraded to 16GB for other reasons (still photo work) this last summer, and like you, I kind of wanted Vegas to do something useful with that memory during a render. But some time back, I did a bunch of benchmarks and found 1GB, 2GB, and 4GB to deliver identical results, so I left it at 1GB… it’s not uncommon for me to have Vegas rendering while I’m doing other work, so I didn’t want to suck up all that free RAM. At a different point, I found things got slower when the preview was set to zero.

That made some sense. I came to digital video by way of digital audio, and back in the early days, every DAW had a way to set up some metric for track buffering, since the practical number-of-tracks versus the playback latency is inherently a trade-off. I never did anything live with Vegas, but later on, started messing around with this kind of stuff, and was kind of surprised that it didn’t really have any means of tweaking the buffering.

Or even optimizing it.. you would think that the Sony development team knows their system well enough to know what makes rendering faster or slower. And that’s information we’d all like to have. For DAW stuff, it was nearly universal that the first thing a new program install does it profile you system to optimize it. I’ve done much of that kind of thing with Vegas over the years, and I know what I’m doing, but I don’t always have access to the things that would allow deeper optimization. And yeah, if I could gain another 10% performance, I could spend a day or a few nights playing with it. It’s pretty clear Vegas left to its own can wind up in a pretty awful performance configuration.

-Dave

[Dave Lozinski]

Dave and everyone:

Check out this thread I started:
https://forums.creativecow.net/thread/24/941866

it has screen captures showing the disk activity and what’s happening when.

Dave Haynie: I even went back to the good old C= Amiga days and borrowed a concept from there: I installed a 2GB RAM Disk on my machine, running everything from there to eliminate the possibility of it being a drive bottleneck.

Hopefully you’re curious about the results too. 🙂

—————————————–
https://www.davelozinski.com
https://www.davelozinski.com/DemoReel/
—————————————–

[Carl Alessi]

One of the things that also affects rendering time and stability are the number of video tracks within the render time frame. I’ve found that if I mute any unnecessary video tracks within the selected area of the video I’m rendering, the time to render decreases and the stability (its proclivity to crash) decreases.