Thanks, I reverted to 334.89 and it now can render the clip without crashing.

However, it's still significantly slower than VP 11. For an 18 minute clip shot in HD 30P, rendered to NTSC wide DVD format, 2 pass 6 Mbps variable, VP 11 does the render in just under 9 minutes, VP 13 (with GPU) takes just over 12 minutes. The VP 13 file is somewhat smaller.

This is using exactly the same clip and exactly the same rendering template with nothing else running on the machine.

I also tested stabilization with the Sony media FX. With VP 11 it took just about 30 min, but with VP 13 it took 55 min.

I still think VP 13's GPU code, at least for the GTX 570, isn't quite right.

I don't get that here. VP12 and 13 are in fact faster then VP11 on my machine. Are you using he VP13 trail version or full version?

Here is another trick for driver 334.89 and GTX570:

In Vegas open the "Preferences" by clicking and holding down the SHIFT key, this will bring up an additional tab called "Internal" In the search box enter "OpenCL Memory". In the field "OpenCL Memory Size Filter" change the Value to 1024. Press Apply and restart Vegas. This will help with preview performance and render performance.

Unfortunately I paid for the full version without trying the rendering first.

I tried changing the OpenCL Memory Size Filter as you suggested, but with no change to rendering times, VP11 is still about 25% faster than VP13, 9 minutes vs 12.

Same here, this is the length it took Vegas 12 vs Vegas 13 to render a video:

12 - 21:05
13 - 26:31

These data points are pretty surprising to me. As far as I can recall, we didn't change anything in the MPEG-2 renderer between VP12 b770 and VP13 b290... The only thing I personally changed in the render pipeline is the loudness meters, which should be inert when the render dialog is up (and even so, I can't imagine that causing a 25% hit). We did make changes in AVC render, especially XAVC, but that was the biggest change I think.

I'm puzzled...

What I'm doing is rendering a clip shot with a Panasonic GH2 30P HD using a template which started as the normal NTSC Widescreen DVD architect template, but I've changed it to progressive scan and 2 pass.

It's also pretty suspicious that the stabilization takes so much longer in VP 13 than VP 11.

My render times are also SUPER slow. The same project in vegas 9 that renders in 10 minutes, is now rendering in an hour and 10 minutes. All settings are the same, and it doesn't seem to matter if GPU acceleration is on or off.

I'm still playing with settings, but if anyone has a solution, please post!

That sounds like the GPU isn't being used. I can't imagine what else would cause that much of a slowdown.

I am also seeing 25% increases in rendering to Sony AVC in 13 vs 12, with and without GPU. This would be rendering XAVC S 1080P60 files to AVC 1080P60.

Strangely, on an old non GPU i3 laptop that I upgraded to an i7, the Sony AVC speed hit was only negligible, but everything else, including XDCAM EX, was still showing the 25% speed reduction.

I thought maybe I had some preference settings off, or that it was the first computer I tried it on, but it seems to be a substantial problem now. Adding 1 minute per minute to a render that takes 5 minutes per minute really adds a lot of time when you get into the half hour range.

Tell me about it. I render plays using multiple cameras and lots of cropping so my renders with GPU tend to run about 3 hours.

The internal prefs have been discussed here in different posts.

Would be usefull to the vegas pro user if sony could explain why :

1. openCL memory is default 384
why is this 384 ? can one increase it and what number
example : have 2 quadro 4000 ( each 2 GB ) -> .......
have 2 quadro k4000 ( each 3 GB ) ->......

2. max RAM preview is limited to 32 GB
why is this 32 GB limit and why does it not remember higher numbers
when changed in internal prefs ( after restart )

3. max threads is limited to 16 threads
why is this limited to 16 threads and why does it not remember hgher
numbers when changed in internal prefs ( after restart )

There has been lots of trials in this forum in regards of this and an official explanation would be helpfull to us , I think .

Thanks

Excellent questions, wilvan.

1) By 384 MB, I think you mean the "OpenCL Memory Size Filter" pref. This is an important threshold where we turn features off/on. If you have less than this amount, then we disable the GPU feature completely. If you have more than twice this amount of GPU RAM, then we enable OpenGL/OpenCL sharing which speeds up the Preview window. Setting this pref to a larger number will actually SLOW DOWN Vegas because we'll use fewer GPU features.

In general, Vegas uses at least 256MB of GPU RAM and no more than 1/3 all GPU memory for image cache, plus it uses additional GPU memory while actively rendering.

2) Wow, I didn't even know about that pref. This limit is 1GB for 32-bit Vegas because setting it higher makes Vegas hit the 2GB max per app too quickly. And that makes a lot of sense. But for 64-bit, as a guess I'd say we just needed some default and 32GB seemed high enough in 2008 (which is when this change went into the code by a programmer who no longer works here). So, I think it's really arbitrary but perhaps there's a deep reason that I'm overlooking...

3) The 16 thread limit matches the size of the thread manager's tracking data so increasing this number would likely crash Vegas. The value of 16 was chosen in 2007 when Vegas first started to support multi-core systems. We could possibly increase this now, but honestly I doubt it would help very much without other changes in Vegas to pre-cache more render frames. You'd just end up with more idle threads waiting for work and using up memory.

You'd just end up with more idle threads waiting for work and using up memory.

Lol . . . Vegas makes work for Idle Threads!

Thanks for the input Chris. Good to have you here amongst us.

G

Chris:
1) By 384 MB, I think you mean the "OpenCL Memory Size Filter" pref. This is an important threshold where we turn features off/on. If you have less than this amount, then we disable the GPU feature completely. If you have more than twice this amount of GPU RAM, then we enable OpenGL/OpenCL sharing which speeds up the Preview window. Setting this pref to a larger number will actually SLOW DOWN Vegas because we'll use fewer GPU features.
___________________________________________________________________

This is actually opposite for many users. Setting to a higher value especially with newer drivers like the Nvidia 334.89 driver provides much faster render times and better preview performance. I think to recall a user with a GTX780 changed this value and finally got good GPU acceleration with the GTX780.

Chris ,

Thank you for giving this some attention and clarification .

In regards of RAM preview amount ( 64 bit , of course ) and amount of threads , I can confirm on my workstations ( dell T7500 and HP Z820's ) that using all threads
available ( and that's 32 to 40 threads on the Z820's ) and adjusting preview RAM to 45 GB ( on the Z820's ) , works like a charm and previewing is real time .
Vegas uses all the cores ( when required ) and the RAM ( without build dynamic preview , just playing the timeline ) .
This is actually how it should be ( in 2014 ) and like after effects uses the power of the workstations .

( experiences are with vegas pro 12 - pro 13 I bought but am not using since preview is giving 15 to 16 frames / sec for exact same veg file which vegas pro 12 previews at a steady 25 frames/sec -> did some more tests and putting all media files ( used by the veg ) on the Intel SSD instead of the SASWD2001FYYG makes vegas pro 13 preview fine . Vegas pro 11 and 12 does not require this and plays fine from the normal SAS disk )

Petty though one has to adjust in internal pref the max RAM and amount of threads to workstation values and that the amount of threads resets to max 16 after restart.
So each time I restart , have to .......

Same for rendering , full blasting all cores makes rendering a joy and fast but personally I don't care whether that goes 0,003 seconds faster or slower since that
is done after weeks of evening work on video clips .
Realtime previewing I am interested in since that speeds up work .

Would suggest to look into these 2007,2008 numbers ( RAM , threads ) and make them up-to-date adjustable .
In regards of GPU RAM , don't understand why only 1/3 GPU memory is being used for previewing , that's a rather low amount .... what's the thinking behind that ?

@oldsmoke :

Makes perfectly sense what Chris confirms about the threshold .
Did quickly a test and changed that openCL mem filter to 4096 ( on my Z820 with 2 quadro 4000's , total of 4 GB GPU mem ) .
After doing that , in options , the GPU turn ON could not be used anymore ( was gone ).
Lowering it back to the default 384 , allowed to turn on GPU again .

The use of 1/3 only of the available GPU mem is a waiste for the remaining 2/3 though , can we change that value too somewhere and/or what is the reason for not using what we paid for ( hardware ) :-)

Another bizar internal prefs settings are the Autocalculate Video Memory (64-bit) which shows default being TRUE but the value being FALSE and can not be putten to TRUE . OpenCL Vendor 1 Old Driver shows 270.0 whilst the OpenCL 1 New Driver shows 285.58 . Apparently these figures are with everyone the same and maybe irrelevant , no idea .

Wilvan

It doesn't really make sends to me. My GTX580 has 1.5GB of memory and setting the value to 1024 with driver 334.89 improved preview and render times significantly, close to driver 296.10. I could also observe a higher usage of GPU memory. You may want to try that value too. Other users with different cards have used different values to achieve better performance and Chris explanation doesn't explain that.

Vegas isn't the only thing using memory on your card. Windows itself uses the card's memory. It's quite possible that if you set Vegas' usage too high (especially using a single card) you'd start getting screen corruptions and maybe blue screens. So Vegas' setting is conservative.

Rob

oldsmoke :

I was just , in general , asking why the 384 and apparently it is only used to decide whether or not to allow GPU inside vegas .

I , myself , am not at all using GPU and let the many cores and RAM do the job ( better ).

Same experience with after effects , so this is not vegas only related.

But that is my personal experience on all workstations here ( also with adobe after effects , btw adobe also came up with alternatives such as caching to a SSD disk and will soon release an even faster alternative , they claim .... )

@oldsmoke, @wilvan,
I wouldn't have expected that setting the filter memory limit higher would help, but this code is not my expertise so maybe I overlooked another place that this value is used...

Regarding the 1/3 GPU RAM value -- remember that's just the cache size. Vegas is indeed using more than that during render. Anecdotally, I heard from other programmers that a higher fraction is harmful. I didn't see the data behind that decision, but I'm willing to speculate that a higher value takes performance away from other parts of the system in negative ways -- e.g. OpenFX plugins need GPU memory too, as does Windows itself.

This is not the end of the story, though. If you look at the public meeting minutes of the OpenFX group (http://openeffects.org/minutes/meeting-2014-04-09), you'll see that some of my colleagues have proposed a more efficient way for hosts and plugins to divvy up GPU memory. So hopefully this will all get simpler for you folks in the future.

On my system, a higher setting only works with driver 334.89 but has no influence with driver 296.10. If I leave the value at 384 with driver 334.89, Vegas performance for preview and render will be down but at 1024 it is actually faster then 296.10. I also tried different settings but 1024 seems to be the sweat spot for my 1536MB GPU ram.

VP 11 renders a 5 minute project in about 8:34, VP13 crashes on the same one. Both are rendering to widescreen DVD 30P.

This is a fairly complex clip with 2 video tracks being displayed on top/bottom half screens and a partially transparent overlay track over all that. The rendering engine is clearly struggling, but VP11 does complete it whereas VP13 doesn't.

I'm still using my NVidia 570 GTX with driver 334.89 and VP 13 build 310.

I sent in a crash report, but thus far VP 13 isn't looking very good to me compared to VP 11.