In earlier Vegas versions the size of Dynamic Preview RAM (DPR) had significant influence on the rendering speed.

Some versions were very sensitive - and had a clear peak - so that even a few KB more or less than the optimal value slowed Vegas down.

From version 12 it seems that DPR size does not mean much anymore to the speed.
This is very good because in the older versions you had to set the DPR as low as about 100 K (as far as I remember) to optimize the rendering speed - but again this was a far too low setting for any reasonable use of Dynamic Preview RAM for reviewing.

I have always wondered why Dynamic Preview was mixed so much up with rendering speed in these older Vegas versions.
Since it was that much either/or it would have been quite natural to have used 2 separate buffers with separately adjustable sizes.

Many have asked about this oddity in this forum then - but I think we never got an answer from SCS - so today - when at least 3-4 years have passed - maybe Chris or other from development / programming could tell the story ? please ?

In V13 it can still matter. I was trying out my new machine with some widely known benchmarks:

Sony press release (sexy Mercedes car) benchmark:

MainConcept MP4 output with GPU, the Dynamic Preview Ram made no difference (tested 0, 8, 200) Rendered in 82 seconds.

MainConcept MP4 without GPU:
DPR set to 200 rendered in 188 seconds
DPR set to 8 rendered in 185 seconds
DPR set to zero rendered in 350 seconds.

Sony XDCAM render with GPU:
DPR set to 200 rendered in 22 seconds,
DPR set to zero rendered in 27 seconds
DPR set to 4096 rendered in 28 seconds.

Sony XDCAM without GPU:
DPR set to 200 rendered in 212 seconds
DPR set to 8 rendered in 278 seconds.

Sony AVC MP4 with GPU:
DPR set to 1024, rendered in 76 seconds
DPR set to 512, rendered in CRASHED at 91% (tried it twice)
DPR set to 200, rendered in 77 seconds
DPR set to 8, rendered in 77 seconds
DPR set to zero, rendered in 89 seconds


MainConcept MPeg2 Widescreen for DVDA interlaced, VBR Peak 9.5M, Avg 8.5M, Min 5.0M
DPR set to 1024, rendered in 15 seconds
DPR set to 512, rendered in 15 seconds
DPR set to 200, rendered in 16 seconds
DPR set to 8, rendered in 14 seconds
DPR set to zero, rendered in 17 seconds


In the Sony car benchmark above, there are differences in stability as well as render time, depending on which render template you use.

John Cline's NewRendertest, quality at High (31):

DPR set to 1024, rendered in 22 seconds
DPR set to 512, rendered in 24 seconds
DPR set to 200, rendered in 26 seconds
DPR set to 8, rendered in 33 seconds
DPR set to zero, rendered in 36 seconds

For the HDV template, size counts. I don't know whether it affects stability.


Computer spec is system 3 in my specs.

Edited to include MC GPU render time (82 seconds)

@dxdy

Are you running the CPU at stock speeds? I am surprised by the rather slow render times you get with Sony AVC MP4 and the R9 290. Have you tried MC AVC with OpenCL?

I'm still using V12, but I've found the optimum setting for me - for preview AND render is 100. Really strange as I can preview a decent amount of shift/B with that too. Actually MORE than if I set it to 1000!

@ Athur.S

Interesting: I'm using V12/B770 too - but adding more and more Preview RAM just gives more and more seconds shift/B pre-rendered preview.
Tried it from 200 and up to 9.000 - and Windows Task Manager (CtrlShiftDel) shows the correct amount of memory used.

Project is 1920x1080 25i ...

OT:
That said, however, I never use shift/B but render out to Main Concept 1280x780 25p at some 9 Mbps which renders as fast as shift/B here and then at infinite length.
This format also seems to play perfectly well here with no audio/video delay.
... Ah, yes - and I play it in VLC player because then you can just render and rerender without having to close down the player. (The Windows player locks the output file)

@OldSmoke

I got 82 seconds for MC with GPU. DPR made no difference.

So far I have only been able to get 1 data disk running, so I am reading the input from it, and outputting the render to the C drive. Perhaps when I get another disk running it will help.

@dxdy

MC AVC set to OpenCL even with GTX580 which isn't as good with OpenCL as the R9 290, I get 48sec. on my system; MC AVC with CUDA I get 28sec. I think it has more todo with running the CPU at stock speeds.

@OldSmoke

4.3 GHz is 41% faster than 3.0 GHz. Simplistically one might expect a 41% improvement in render time (ignoring the other factors out there). So your OpenCL time of 48 seconds compared to my 84 seconds is about right. Should the additional 4 threads make a difference? Apparently not.

Once I get this puppy settled down (still a couple of finesses that need to occur), I will try to OC like Nick Hope did.

That is exactly my concern. How much more do we get from the extra 2C/4T with Vegas.

The danger of not going with the state of the art (even at a $500 premium) is that Sony Vegas 14 might really have the whole GPU and thread thing worked out.

I don't imagine SCS had any idea we would be buying 16 thread machines in quantity when they designed the current code base. Or that GPUs would look like they do today. How could they have?

While the GTX580 is a great value today, it is not the GPU for the future. For those who can afford interim solutions (e.g., used 580, i7-3770), and the time to implement them, they will have quick machines for a time. But every time I build a machine or make a big change, I spend days getting all the software and add-ons in place and working. I just need to do this upgrade in big chunks, far apart. IMHO.

[I]The danger of not going with the state of the art (even at a $500 premium) is that Sony Vegas 14 might really have the whole GPU and thread thing worked out.
[/I]

I don't see any danger there... knowing SCS. How long have we been waiting to have GPU acceleration work on newer cards.

whilst i acknowledge the sterling work and experimentation carried out by a number of contributors here, along with the sage advice given upon analysis of the results, i cannot but despair that scs has still not voiced ANY advice / suggestions regarding gpu acceleration...

it's been at least 2 years since scs launched amid much fanfare gpu implementation, and in the intervening time NOTHING seems to have been done to sort out the myriad problems some of us have encountered trying to use it. NOR does it appear that scs realises we've moved on 2 generations of nvidia cards, rendering (oops ;-)) the respected 5xx series well and truly obsolete.

i'm very happy with 13, and since i have a reasonably powerful cpu, and sleep at night, rendering is not my major concern - but i would dearly like improved playback preferably using a CURRENT video card.

if scs and vegas is to stay relevant in the nle market adding new gimmicks is NOT the way to go, especially since the competition seems to be moving ahead more quickly implementing hardware / software combinations that will make vegas look almost archaic.....

Ouch!, but oh so true..I'm still with v 12, managing to deliver what I need to, but am I confident? Nah, just waiting to VP 14, a sad admission.

Some years ago someone did a similar test and found the same conclusion - Vegas needs *some* Dynamic RAM for ordinary rendering. His tests showed the sweet spot at 1024.

I doubt that there is a sweet spot for it. What works for one doesn't work for others. My system works perfectly with the default setting of 200, any deviation from it and it slows down preview as well as rendering.