Quote: I decided I would do the same test on my PC with the 680 card.

I used the same 3 minute video and selected HA in Prefs and checked the boxes in Produce it took 9 secs. I unchecked only the boxes in Produce and it took 9 secs !

I then unchecked HA in Prefs as well as the boxes in Produce and it took 17 secs.

I then left the HA in Prefs unchecked and checked the boxes in Produce and it took 9 secs !!!

I am now really confused about the settings options....

A very long response but if you read through and mimic the suggested tests you should understand the options that are currently not making much sense to you.

CL provided the details of pref > HA options and Produce "Fast video rendering technology" in this FAQ, http://www.cyberlink.com/support/product-faq-conte...&CategoryId=-1&keyword=effects

Basically:
Preference > Hardware acceleration > Enable OpenCL technology: This feature determines what technology is to be used for these specialized effects (the ones with the GPU logo in the corner) when applied to the timeline. When activated the GPU will be used during preview and render. So IF "Enable hardware encoding" in "Produce" is selected as well as this option, these specialized effects if used in the timeline will get the assistance of the GPU and the video will be hardware encoded with the GPU. If this option is unselected, but "Enable hardware encoding" is selected, the video will be hardware encoded by the GPU but these special effects will have the CPU do the task.
Likewise when previewing a video in the timeline that has one of these special effects applied. If this option is selected, the GPU will assist in the render to the playback window, if not selected, the CPU will do the effect task.

Preference > Hardware acceleration > Enable hardware decoding: Is pretty self-explanatory, it only affects decoding, nothing to do with encoding so does not affect the ability to "Enable hardware encoding" in "Produce"

Produce > Fast video rendering technology > enable Hardware video encoder: Again, pretty self-explanatory, if your GPU supports hardware encoding, you can enable this feature. When enabled, the encoding will be done with the GPU, when unselected, encoding is done with the CPU. Whether faster or slower or a change in output quality really depends on the hardware involved and the timeline contents.

From above, the Pref > HA > decode has nothing to do with encoding so I will skip discussion of that feature in the demonstration below. Yes for some timeline content it can affect encoding elapsed times, but it does not control encoding, it controls decoding.

The following tests will may help you understand if HA encoding is working on your GTX680 successfully and what PD is actually doing. Disclaimer: The timeline used below is a test timeline, it does not reflect an actual user timeline nor performance one may get with a real timeline, its purpose is purely educational.

For these series of tests I am using a GTX650 and Nvidia driver 347.88 with PD14 v2019. I’m assuming you have your IntelGPU deactivated on your i7-3770k and are using the GTX680 for HA encoding. Use of other drivers or other versions of PD14 will yield differing results. I’ve noticed many recent Nvidia drivers and OpenCL (active in Pref > HA > OpenCL) have dire consequences in PD14 when a acclerated effect is applied.

TestA CPU encoding:
1) Place 5 default video “Kite Surfing.wmv” in timeline
2) Pref > HA both options unchecked
3) Produce, set H.264, 1920x1080/60i 24Mbps, M2TS container
4) Produce, make sure "Fast video rendering technology:" is unchecked
5) Produce, record elapsed time as TimeA (For your i7-3770k this is probably about 40 seconds)

TestB HA GPU encoding:
1) Just use "Previous" to go back to Produce functionality
2) Produce, make sure "Fast video rendering technology" with the "Hardware video encoder" is checked
3) Produce, record elapsed time as TimeB (For my GTX650 this is was about 20 seconds, your GTX680 should be significantly faster)

For your i7-3770k and a GTX680, TimeB should be significantly faster than TimeA. You can play with Pref > HA settings but they will have no significant effect on the encode times of TestA or TestB. We have nothing in the timeline for Pref HA > OpenCL to aid in encoding or in this case with a wmv file in the timeline nothing to decode.

TestC CPU encoding with a fx applied:
1) Go back to the basic timeline
2) Add the effect Bloom to every clip. (I picked Bloom for a very specific reason, this is an educational timeline!)
3) Produce, verify H.264, 1920x1080/60i 24Mbps, M2TS container is still selected
4) Produce, make sure "Fast video rendering technology:" is unchecked
5) Produce, record elapsed time as TimeC (For your i7-3770k this is probably about 190 seconds)

TestD HA GPU encoding with a fx applied:
1) Just use "Previous" to go back to Produce functionality
2) Produce, make sure "Fast video rendering technology" with the "Hardware video encoder" is checked
3) Produce, record elapsed time as TimeD (For my GTX650 this was about 170 seconds, your GTX680 should be significantly faster)

For your i7-3770k and a GTX680, TimeC and TimeD are probably rather close. If monitoring with GPU-Z you would have seen a little activity under Video Engine Load, basically you are CPU governed, CPU load probably near 100% TestD was not significantly faster like it was in TestB vs TestA because this Bloom effect used requires the CPU to render the effect. It loads the CPU extensively so this dominates encoding times. The GPU in TestD is doing the encoding but all the prep work of the special effect applied to every clip is being done by the CPU.

TestE CPU encoding with a fx applied utilizing OpenCL functionality with Pref > HA > OpenCL checked:
1) Just use "Previous" to go back to Produce functionality
2) Pref > HA make sure OpenCL is checked
3) Produce, make sure "Fast video rendering technology" is unchecked
4) Produce, record elapsed time as TimeE

TestF GPU encoding with a fx applied utilizing OpenCL functionality with Pref > HA > OpenCL checked:
1) Just use "Previous" to go back to Produce functionality
2) Produce, make sure "Fast video rendering technology" with the "Hardware video encoder" is checked
3) Produce, record elapsed time as TimeF

For your i7-3770k and a GTX680, TimeE and TimeF are probably somewhat close, however, both these times significantly faster than TestC and TestD which was the identical timeline. This occurs because this Bloom accelerated effect that was applied utilizes OpenCL effects (we activated that setting in pref) to use the GPU cores to create this specialized effect we had applied to the timeline. For your particular box, your GTX680 is substantially faster than your CPU for encoding this particular educational timeline. If monitoring TestE or TestF with GPU-Z you should have seen significant load in the GPU Load sensor because this will show the OpenCL usage from the GPU accelerating the effect.

Jeff

Here are the results, it's only Time D that is a question ?

I have also update my profile, which was out of date. Intel Core i7 3770K 3.6 Ghz,
GTX 680, 2 X Benq23 3D monitors,
6G DDR3, Win 7 64, Win 10 (Insider) 64
PCIE SSD, Intel Sata SSD 2 500 Gbyte Seagate,
Minoru 3D WebCam, NVIDIA 3D Vision-Ready

Quote: Here are the results, it's only Time D that is a question ?

I have also update my profile, which was out of date.

Sorry, I don't know anything specific about your TestD as I can't get past TestA results. With 5 "Kite Surfing.wmv" on the timeline I've never seen a i7-3770k complete that in 5 sec. 10:1 encode to real time ratio (~50sec timeline, 5 sec encode) for this basic profile is well, extremely good, unheard of to be exact. Don't ever sell that box, that's light years ahead of any new processor. What that looks like to me is SVRT type speeds, only problem, SVRT does not work for 5 Kite Surfing.wmv files in the timeline.

Good luck, I'm unfamiliar with that type of capability for that specific timeline.

Jeff

Interesting...I did some experiments with rendering performance shortly after I put this system together but had no real comparisons except my own experiments as to whether it was getting better or worse, I did overclock the CPU for awhile and it made some difference but I didn't want to blow it up so I scaled it back. In the meantime, many thanks for your support, I have learned a great deal about HA...