Thank you Nick, here is a better and more precise version of the question:

All things are equal BUT rendering engine, only that is compared.

Vegas is build 311. 

Windows is 7(64)

Box is a Dell Precision 490 with dual xeon, window performance rating for cpu is 7.2

GPU is a Nvidia GTX 1050ti, windows performance rating in box is 7.2 Card is recognized by Vegas.

Rendering is from a file on one usb disk to a file on another usb disk.

With no gpu assistance the rendering speed is 4.69 frames pr. second, with gpu Nvidia GTX 1050i the rendering speed is 3.41 frames per second. The same segment of a file was rendered. The rendering is a de-interlace job, options are figure 1 below, without gpu is figure 2 and with gpu is figure 3. Why is rendering slower with gpu than without?

What is the status of "GPU acceleration of video processing" in each case? (in Preferences > Video)

What is the status of "Encode mode" in each case? (at the bottom of the custom render settings). With the 1050Ti you should be able to use NVENC encoding and get a faster render.

Many Vegas versions ago I had similar questions - and used a lot of time trying to find fastest speed etc etc.

A few Vegas versions ago I finally realized that the topic is so complicated that there is no final (scientific) answer.

When you are rendering some CPU/GPU time is spent for decoding, applying FX's etc etc - and some CPU/GPU time is spent for encoding.

Some of the available decoding codecs are using the GPU in a good way - others are not so good - all even depending on the media used etc.

Most of the encoding codecs behave precisely the same way.

So one might be better off asking the speed question in another way: Is there a setting that gives me an optimum in rendering quality + speed + with my specific machine setup ?

I have a stack of strong Nvidia and ATI cards on the shelves from trying and trying and trying and ...

But finally: My own answer was "NO final answer".

So I decided to split the speed question in 2 parts:

1) Speed when wanting to render something to check the transitions to music, the foley to the movements etc - and here I found that rendering using the good old Mainconcept mpeg 2 format was nice and fast.

Even if I do a 4K or full HD project i just render in 10 Mbps 720p format - and maybe most urgently: in .MTS (transport stream) format since this gives the very best time control (many players are more or less slightly inaccurate when playing the .mpg format). Rendering this way is very fast on my 6 phys core machine.

I do these renders CPU only since I many years wasted far too much time noticing / trying to solve that (some) FX's (i.e. the blurring FX) did not play correctly with (some) GPU's etc etc. ( a lot of "etc's" are necessary here 🙂 )

2) Having edited the project this way then when coming to the finishing rendering(s) - then time is a not so important factor anymore - and here I keep using no GPU since it often does nothing good (as also in your example) - and here the important thing is to get the best final quality in the format you need / have chosen.

And for the final 5-10 renderings the speed is not so urgent any more.

Just my 2 Cents.

What is the status of "GPU acceleration of video processing" in each case? (in Preferences > Video)

That is where I toggled GPU on vs. off and restarted program as required for the change to take effect.

What is the status of "Encode mode" in each case? (at the bottom of the custom render settings). With the 1050Ti you should be able to use NVENC encoding and get a faster render.

No such option for that with that codec, see screen shapshot, iniatally with V15 - in 2017 - I used the Sony mp4 codec, but it has a graphics bug that makes it useless, a brief test I just made suggests however that it is about 30 to 50 percent faster with GPU that without.

What is quite confusing is that since the Magix codec has no option for choosing gpu on or off, but the encoding process (codec or V15, dunno) behaves differently depending on the global setting for use of GPU.

A couple of hours of googling and reading suggests that the answer to the microsoft exam question "did it ever  work" is a NO, it never really really did. 

The Vegas help file needs an update and or the program or codecs need to be brought into harmony with the implication of money spent on fancy graphics cards being money well spent. There is some indication in what I have read that the most modern graphics cars are not a good idea but most of it is V12 or V13 related and one would expect issues two generations back to be resolved. Nevertheless the vague memory of previously having read it was my reason to go for last years best buy that someone else had upgraded to this years best buy, hoping that it had been considered and catered for.

I'm wondering whether it will be worthwhile to benchmark all codecs with and without GPU .. but really, I have done so much of that kind of stuff, and I'd rather use my screen time on this here videoputer for making video with this generally great software that is so wonderfully capable.

Like @ritsmer, I've been in the CPU Only camp since about Vegas Pro 11, maybe earlier, since my video card was a GTS450 in that era. I secretly wish that I could find a way to monetize all the hours of experimentation on GPU encoding that have been expended by well-meaning people around the world. I'd be rich!

[Posit]

If you want to test the encoder you must separate that process from decoding and effects processing. One way to approach that would be to render your finished project to an uncompressed file. The uncompressed file will have been decoded from any long group of pictures acquisition codecs and all effects will have been applied. Putting that on the timeline of a new Vegas Pro project will allow you to compare the capabilities of the different encoding hardware without the results being influenced by decoding and effects processing.

[/Posit]

Caveats:

1) USB to USB may not, probably won't handle the I/O rate of uncompressed video very well.

2) This process would not be a measure of the "clock hours" required to get a final output, just a way to measure the capabilities of different hardware.

I'm in "CPU only" camp as well. Quality is the reason. Nvidia/Intel encoders produce worse quality, however I'd like to have "the best". Speed is not vital as I'm rendering my small home videos during nights.

No such option for that with that codec, see screen shapshot, iniatally with V15 - in 2017 - I used the Sony mp4 codec, but it has a graphics bug that makes it useless, a brief test I just made suggests however that it is about 30 to 50 percent faster with GPU that without.

Then you have to allow those options in Preferences and maybe also the use of the old Mainconcept AVC encoder in Preferences/Internal.
But that's all old stuff.
If you want real faster renders with that codec you must use one of the other possibilities for the Magix AVC codec or choose in your rendersettings the other possibilties in what I cannot see in your screenshot rightnow

 

No, I don't have to update drivers. It is a new installation with the newest available drivers. I do not use the sony mp4 codec, which has a gpu yes or no option because it - or the software use of it - has a graphics ranging error that makes the image softer. The selected codec does not have that bug. So either the Magix codec autodecides or always runs only on the CPU. It should then not be slower with gpu selected. That is a plain bug no matter how you see it, but it may be about how V15 asks the codec to to its stuff.

Other than the issues, this mostly is a documentation flaw, one gets the impression that everything gets faster and better when using gpu accelleration but there is a lot left unsaid in the help file. The 5770 I tried first actually works a lot better for this, but before I put it back in I'll find a day to waste trying with and without GPU with a variety of codecs because their abilities are apparently left undocumented. It could rapidly become a vast forest to maintain, but a list of Vegas hardware qualified graphics cards would be helpful.

Are you listening Magix? - it is toy money out of my pocket that I could have shopped software for that I have used on a possibly not really useful graphics card, last years best buy so as to not be untimely modern.

> 1) USB to USB may not, probably won't handle the I/O rate of uncompressed video very well.
 

Not an issue, the video is not stored uncompressed on disk and thus not travels uncompressed on the usb bus. Also the renderspeed is in the interval 2  to 5 frames per second for full hd. Which is what made me interested in giving that double two core xeon (windows cpu rating 7.2) box an additional brain. The buggy Sony avc codec does a much better job of using the gpu, unfortunately it is currently useless because it has an always-mapping from computer graphics range to studio graphics range that softens the image.

The issue that does exist is that usb to usb disk is costlier in terms of processor use than internal disk to internal disk, but it still has a good chance of being a better choice than internal disk to same internal disk, even if a stripeset of raptors. Worst case usb to usb disk transfer is about 16 megabytes pr. second because the total usb subsystem bandwidth is about 32 megabytes pr. second.

The "Microsoft certification wisdom" is that the processor is the bottleneck if it runs at 100 percent cpu, it is first when it falls below 80 percent cpu the disk subsystem is the bottleneck because then the processor waits to be fed something to do something with.

Thank you all, thank you for all comments, great inspiration for this journey into understanding my soft- and hardware, there does not seem to be a solution this forum can provide, it is easy to see the resource issue for the vendor, but there seems to be some room for improvement. I should probably just have been happy with 5770 that I found at a real bargain price and that is of a family of cards that "googlesay" suggests has better performance in this context, but "more wants more" and I didn't know that when I got the newer card. At least with  the 5770 renderings ran with 80 percent cpu use and 80 percent gpu use. Because of the open nature of the issue - currrently unresolvable by softwares design, but software ran away from home and got new home and will perhaps get better resources here - I'¨ll not mark anything som "the solution". Thanks guys! - I may follow up if I end up with some rendering benchmarks for more codecs.

Usually, I don't mumble about subjects unless 1) I already know the answer or 2) I'm curious enough about it to actually do the work.

In Vegas Pro 14, I rendered a project with settings close to yours except that I'm in NTSC land and use 23.976p. Rendering to the Sony YUV Uncompressed file took 61 seconds (which can be added to the clock hours) 

for a file with these characteristics:

Rendering to the Mainconcept AVC render template from camera source (~35 Mbps, AVC + LPCM in a MOV wrapper) took 343 seconds.

I rendered to Mainconcept AVC from the Sony YUV Uncompressed avi file and the process took 330 seconds. At this point, I appear to be wasting time since both processes amount to at least 404 seconds of clock time as opposed to 343 seconds just rendering the project from camera source. The decoding and effects processing overhead seems to be 343 - 330 = 13 seconds for my project that only has a Color Curve applied. This doesn't seem like such a great thing to do except:

1) For any changes that I have to make in the future, I get to see this screen for any part of the project that's unchanged:

2) You can take your uncompressed file to any other encoder in the known universe and render it. Likely candidates would be Handbrake, MeGUI, FFMPEG and on and on.

No, USB disks won't cut the mustard if you choose to use uncompressed files.

If you want to test the encoder you must separate that process from decoding and effects processing.

Understood, what I want  to test is my actual production process for a concert  recording using multiple cameras. Using .mxf files a productioon folder during production is about 400 gigabytes.

Using uncompressed video is not in my current hardware budget. But is one of the very good things coming out of this to be made aware that perhaps I should consider a different production process and a different hardware setup, thank you!

OK, here is a rendertest of rendering to sony yuv with gpu render DISABLED while deinterlacing.

Vegas video settings:



Codec render settings:

Renderspeed:

which is an average of 9.6 frames per second. Notice the datarate, no disk performance issue to worry about even if worst case setup - from and to the same usb-disk.

OK, with gpu accelleration, surely must improve ... or ... ?

Vegas-settings for using the gpu as coprocessor:



Codec-settings for using the gpu as coprocessor:


And hey presto, no, hey largo, the rendering speed:


Average 4.83 frames pr. second. Basically half as fast. This is not gpu accelleration, it is gpu braking as words are usually deployed. Yes, it should have been uncompressed, I overlooked that it wasn't, otoh, what cuda accelleration according to googlesay is good for is perceptual encoding, so it should really help. It does not, it is a waste of computertime and mains power. See next post for the same test with yuv uncompressed, de-interlace and read-write on the same usb-disk just as here.
 

And now to rendering an uncompressed file, first the global vegas settings for no gpu use:

the codec settings:

and the resulting render speed:

ie. 5.75 frames pr. second. Disk queue was max 2.23, so it may be that it was the simultaneous read-write that was an issue. But the faster render to compressed file had the same disk conditions ...

Vegas global settings for the uncompressed render with gpu enabled:

and the codec settings:

which gives this result in terms of frames rendered pr. second:

ie. 5.11 frames pr. second. disk queue ended up in the same 2.2something turf, at least the uncompressed render was equally slow with and without gpu.

Here is a glimpse of the disk queue from the latest render:


A disk queue of 2 suggests that the disk is the limiting factor, the compressed avi file is about half as large and was twice as fast with no gpu assistance, with gpu assistance it is the same about 5 frames pr. second.

Do not assume that results with many digits are more precise than they are, it is fairly full disk, so life is hard when doing simultanous read-write on it. Large differences are probably conclusive, small are probably not, so the results that are certain are that the uncompressed rendering ran into disk performance limitation and that with the compressed rendering it was fastest not to use the gpu.

Renderspeed is not all there is in the universe, with a high power graphics card one advantage is obvious: prewiev actually works very well indeed, but rendering is at best not slower than with 4 xeon cores at 3 GHz. Googlesay is that ATI may be a better choice than Nvidia, but that googlesay is not recent and I have seen some reference to "improved nvidia compatiblity" with newer versions.

Magix! - some comment from you would be immensely helpful about now! - these performance oddities suggest that there is something I think you need to look into, using gpu acceleration should  be faster than not using it ... O;-)

Me, I'll sit down, get a cup of tea and be quietly confused, I had settled on using this format:



as the in-house intermediary format and with that I also see a lot of no re-rendering required, I think I'll stick to it due to the space demands of .avi, compressed or not, it has the advantage of not having perceptual encoding of the sound and just storing it as 16 bit linear 48 kHz.




 

A rendertest for the mxf-format illustrated above gave - with a disk queue of 0.01 or less - the result that rending with the gpu assistance ended up at 3.36 frames pr. second and without it 5.92 frames per second. Yes, again confirming the overall tendency of gpu render running at half the speed of no gpu render on this computer with the Nvidia 1050ti with its 768 cuda cores and 4 gigabytes ram. Not quite my expectation, but the video quality is very good and now preview actually works, which it also did with the ATI 5770. So yes, getting a capable card is a good idea, getting a too capable card perhaps just a waste of money better spent on disks.

As much as we enjoy this type of analysis, we would benefit from the Mediainfo reports from:

1) Your camera video and any other media that you might use. Nick mentioned this earlier.

2) Your delivery goal, youtube, vimeo, DVD, Blu-ray.

My SWAG on your situation is that the vintage of your system (Core clocks < 4GHz, PCIe bus vintage) pushes GPU upgrades deep into diminishing returns. Eventually, you'll have to take a system approach to solve your render time problem. A system approach is a euphemism for a forklift upgrade.

As much as we enjoy this type of analysis, we would benefit from the Mediainfo reports from:

1) Your camera video and any other media that you might use. Nick mentioned this earlier.

2) Your delivery goal, youtube, vimeo, DVD, Blu-ray.

My SWAG on your situation is that the vintage of your system (Core clocks < 4GHz, PCIe bus vintage) pushes GPU upgrades deep into diminishing returns. Eventually, you'll have to take a system approach to solve your render time problem. A system approach is a euphemism for a forklift upgrade.

Thank you for asking John, I found an error, the file rendered is on the stripeset in the box, so all renders are from in box drive to usb. It doesn't really matter as other global variables that also does not matter, because what is tested is enabling or disabling gpu accellaration on the actual box, no claim of global validity of the test is made.

However with a 2:1 advantage of disabling gpu vs. enabling it in some of the cases, there IS an unavoidable issue for the developers to address, irrelevant of this here double twin core xeon Dell Precision 490 having been discarded in an engineering company when they moved their shop and got new computers in the process; I bought a pair and merged relevant components to one and bought additional (costly!) ram for it. This is not about minor nuances. And yes, the update is a new box with minimum 8 and preferably 12 xeon cores, making a smaller upgrade is a waste of time and money, but from the wording gpu accelleration my expectation was that I would be able to get a 20 to 50 percent improvement in rendering speed.

Here is the mediainfo for the file rendered from:



I decided to put the 5770 back in based on feel of the computer, it is closer to its hardware generation, the plugs in it fits the available two displays and the noise is less unpleasant. A simple comparative test showed that there is no relevant speed difference between rendering with it or without it, but it uses 25 percent of its capability when rendering to the magix mp3 legacy codec that offers no option for selecting gpu or not, googlesay is that it has a hard coded list of gpu's it knows about.



With what is today a "legacy" card running at 25 percent of what it claims it can there does not seem to be a lot of merit in having the newer card in the box, except perhaps that it uses less power. I did not check with other codecs, with no major differences the practicalities made the choice, not the performance. And the older card still gives a useful preview, something that was sorely lacking once I got to full HD with the ex works Nvidia Quattro. 

The delivery goal for this render was youtube.

 

For Nvidia GPUs, GPU rendering is only supported with the MAGIX AVC codec (only format NVENC supports), and you must select (or make your own) a preset that has NVENC enabled. Otherwise, you are only using your GPU to process the video on the timeline, and your CPU is doing the rest of the work by itself. This is why you have slow render speeds.

Currently, Nvidia is the way to go with Vegas, unless you have an intel CPU that supports quicksync, but that isn't available on the higher end CPUs.

AHA, thank you, makes sense. There is something to learn from programs like Feurio, I think Vegas direly needs a hardware test and configuration wizard added. It could also at least mention NVENC in its helpfile, it was a google search that told me what it is. What a wonderful pristine horizon of ignorance I have found. I will stop tinkering with hardware in this box and see if I can get NVENC to work on my hot spare. However it remains unexplained why enabling gpu support made encoding run at half the speed as CPU only with the Nvidia card, there is something weird about that .... but it is in the undocumented zone of the softwares behavior it seems .... so perhaps we'll never know, but also perhaps this is something to expect drastic improvements on eventually, whenever that is :)

Edit: I was mistaken with the post I removed, NVENC is supported on Nvidia GPUs beyond the 6xx series, anything beyond that should be good to go. Older than that (5xx and back), you must use Sony AVC codec and select OpenCL as the GPU acceleration mode..

Older than that (5xx and back), you must use Sony AVC codec and select OpenCL as the GPU acceleration mode.

For NVIDIA 5xx and older you use Mainconcept AVC with CUDA, not OpenCL which is for AMD cards and the Sony AVC encoder. However, for VP15 you have to enable "legacy GPU" support first.

@digilyd You said.

"Here is the mediainfo for the file rendered from:"

This file is not your camera source.

I read in one of your other posts that you want to keep PCM audio all the way to youtube, if possible.

If audio is a major concern, you might consider rendering to Sony XAVC S Long in an MP4 Wrapper with PCM audio. The stereo channels are not mapped the way they are in the MXF wrapper.

Edit: I was mistaken with the post I removed, NVENC is supported on Nvidia GPUs beyond the 6xx series, anything beyond that should be good to go. Older than that (5xx and back), you must use Sony AVC codec and select OpenCL as the GPU acceleration mode..

It is a 1050ti, but I can't find the option to use NVENC anywhere ... ??