OK. I went through the steps and ran the test using just QuickSync.

For thoroughness, I ran both projects with all three nVidia drivers and found that the 3x3 wall test took 12:09, 12:20 and 12:13 to complete with the three nVidia versions (from newest to oldest). All the production times are >2x longer than before, so it really looks like the GTX780Ti was helping in a multi-GPGPU sort of way. In adddition, the bit rate crept up a bit when the nVidia card was totally out of the picture.

There were no significant changes with the 20x boats project.

I've updated the spreadsheet and added the new output clips to the OneDrive folder, and now I may move on to other things unless there's some merit to re-running the CPU-only benchmarks with the GTX780Ti disabled and/or with OpenCL and HW decode unchecked. All were present and checked and only Fast/HVE was unchecked on the Produce tab the first time through.

YouTube/optodata

DS365 | Win11 Pro | Ryzen 9 3950X | RTX 4070 Ti | 32GB RAM | 10TB SSDs | 5K+4K HDR monitors

Canon Vixia GX10 (4K 60p) | HF G30 (HD 60p) | Yi Action+ 4K | 360Fly 4K 360°

Quote: For thoroughness, I ran both projects with all three nVidia drivers and found that the 3x3 wall test took 12:09, 12:20 and 12:13 to complete with the three nVidia versions (from newest to oldest). All the production times are >2x longer than before, so it really looks like the GTX780Ti was helping in a multi-GPGPU sort of way. In adddition, the bit rate crept up a bit when the nVidia card was totally out of the picture.

Now that's more like it, 12:00 vs 5:00, of course the 780 was assisting for the QS encode, that's what the prefs setting told it to do.

Quote: There were no significant changes with the 20x boats project.

Correct, there should be no change there, nothing for the 780 to assist with, just a straight encode, only QS capability at play when using QS HVE.

Quote: I've updated the spreadsheet and added the new output clips to the OneDrive folder, and now I may move on to other things unless there's some merit to re-running the CPU-only benchmarks with the GTX780Ti disabled and/or with OpenCL and HW decode unchecked. All were present and checked and only Fast/HVE was unchecked on the Produce tab the first time through.

Your CPU only times will get worse too for the 3x3_wall as the 780 was assisting there too if that's how you had OpenCL in the pref set.

To me your data all makes sense when one understands what pieces are doing what. The only merit in this effort to me is why encode file sizes (bitrates) are so different, that's essentially end user quality piece at play. I have a full review of all 192 Fx's with QS (HD4000), Nvidia(GTX650 and GTX970), AMD (R9 270) and CPU encoding that is very eye opening. I'm not really an FX's user but this thread caught my eye.

Jeff

Signature PC Profile:

H.264 1920x1080/60i 24Mbps NTSC

Open CL (ON) HVE (ON)

3_3_wall - Time 4.37 - size 48,825 Kb.

3_3_wall_abst - Time 5:36 - Size 98.976 Kb.

3_3_wall_glass - Time 06:09 - Size 194.160 Kb.

3_3_wall_waterrefl - Time 12:37 - Size 42.672 Kb.

Intrigued by the greatest time for 3_3_wall_waterrefl

I redo and again the time was longer.

I changed the profile toProfile:

H.264 1920x1080/60i 16 Mbps NTSC

I repeated the tests now consistent results.

3_3_wall_abst - Time 5:30 - Size 82.503 Kb.

3_3_wall_glass - Time 06:09 - Size 131.150 Kb.

3_3_wall_waterrefl - Time 5:36 - Size 129.083 Kb. AMD-FX 8350 / 8GB DDR3
SSD SUV400S37240G / 2-HD WD 1TB
AMD Radeon R9 270 / AOC M2470SWD
Windows 7-64 / PD16 Ultimate

Quote: ... I have a full review of all 192 Fx's with QS (HD4000), Nvidia(GTX650 and GTX970), AMD (R9 270) and CPU encoding that is very eye opening. I'm not really an FX's user but this thread caught my eye.

Jeff

Which thread has all that data? (said OPTO...)

YouTube/optodata

DS365 | Win11 Pro | Ryzen 9 3950X | RTX 4070 Ti | 32GB RAM | 10TB SSDs | 5K+4K HDR monitors

Canon Vixia GX10 (4K 60p) | HF G30 (HD 60p) | Yi Action+ 4K | 360Fly 4K 360°

Quote:
Which thread has all that data? (said OPTO...)

This one, just posted it.

Looks to me like we must be seeing variation in PD encode logic and hardware. As I mentioned earlier, I’m not sure a bug but it surely is not what I would have expected. The table in pic1 shows a few different configurations of platforms, CPU, Intel, Nvidia, ATI, MGPGPU encoding with the sample files I had posted.

Because of the random luck of simply grabbing a few different FX’s and those showing issues in pic1, it caught my interest so I evaluated all 193 PD FX’s that I have (PD and NewBlue). For this I simply took 5 of the Boats.wmv in track 1 (65s total duration) and applied a given effect at default settings to the each clip in its entirety. I then produced at a standard 1920x1080/60i 24Mbps, M2TS container with NTSC settings. CPU encoding over the PD releases has been rather reliable, when one excludes a few outliers in the tested data for CPU encoding it looks like the resulting file size it's fairly constant at 184MB which agrees with the defined 24Mbps bitrate of the profile for this 65s duration timeline. The attached pic2, (looks like an eyestrain but it will zoom in with clarity) summarizes several stats from the automated testing of the 193 FX's tested in this fashion. The test was done on several different platforms with a couple different GPU’s. The highlights in red are any file size less than 184*.95=175MB, I have a hard time seeing a bitrate difference of 5% but can often easily detect 10% in finished H.264 encodings.

A little bit of a surprise, not sure what CL and PD is up to, the issues appear to affect many FX’s.

There must be some implementation anomaly with several of the Newblue FX’s, like NB Oil, NB Rolling Shutter to name a few. Maybe someone else could try them and see how they work on your platforms.

I’m not a big FX user so no real impact to me but it would appear something CL should maybe glance at and see if they are providing users with the best quality when using certain effects.

Jeff

Jeff, Ron;

As you both will know, I haven't the competance to follow your testing. I am just a user - who some times stumbles over something I find odd. Like the NB Fx's.

Jeff just said:

"There must be some implementation anomaly with
several of the Newblue FX’s, like NB Oil, NB Rolling Shutter to name a
few. Maybe someone else could try them and see how they work on your
platforms."

No matter which computer, the NB Fx's are demanding/using/ sucking out lots of power, in PD as well as in another editor I have. Back in September / October, I posted something about it:



http://forum.cyberlink.com/forum/posts/list/40485.page#208815

Many of the NB Fx's are slowing down not only produce, but also preview- no matter how you set the preview. In my "other editor" the NewBlues always get marked red in preview rendering and may also cause the audio to spark in preview. So yes, if I use a NB effect (which I try to avoid, really) I experience anomaly.

Nina



PS: Does this new text editor have a hidden possibility to post a quote?
Just something.
https://www.petitpoisvideo.com

JL_JL you can update your image OpenCL_table.png 3_3_wall_nofx.pds for my computer.
it is 185.2MB - same as yours as expected.

Looks like you are also getting the smaller file sizes for the 3_3_wall when using CPU only - I was wondering if it was only my computer - looks like that is "normal" also. Win8.1 Pro x64 / Dual x5670 / 24GB / GTX960 4GB / 240GB SSD + 640GB HDD / PD13 Ultimate

Jeff, if you can wait a few minutes I'll run the test projects as well and post the results.

Quote: PS: Does this new text editor have a hidden possibility to post a quote?

Is this what you're looking for?



YouTube/optodata

DS365 | Win11 Pro | Ryzen 9 3950X | RTX 4070 Ti | 32GB RAM | 10TB SSDs | 5K+4K HDR monitors

Canon Vixia GX10 (4K 60p) | HF G30 (HD 60p) | Yi Action+ 4K | 360Fly 4K 360°

Jeff -

That is the most amazingly thorough testing I've ever seen posted in these forums (aside from the others you've done). Thoroughly implemented & documented. Your investigative work in so many aspects of PDR is certainly valued by all of us.

You, sir, are truly professional!

Cheers - Tony
Visit PDtoots. PowerDirector Tutorials, tips, free resources & more. Subscribe!
Full linked Tutorial Catalog PDtoots happily supports fellow PowerDirector users!

Quote: Jeff -

That is the most amazingly thorough testing I've ever seen posted in these forums (aside from the others you've done). Thoroughly implemented & documented. Your investigative work in so many aspects of PDR is certainly valued by all of us.

You, sir, are truly professional!

Cheers - Tony

Absolutely! No doubt! Fantastic!

To help broaden the scope, I've just completed running all of the projects in CPU, HA, MGPGPU and QS modes and have attached the results here. I've also updated my spreadsheet from a few posts back on OneDrive, and all the produced files are there as well.

Basically, I had good/consistent results with all modes with wall_glass, but MGPGPU stumbled with wall_abst and my 780Ti did poorly (bit-rate-wise) on waterrefl. The Intel HD4600 did well with the bit rate on wall_abst but it took much longer than any other mode, including CPU...

YouTube/optodata

DS365 | Win11 Pro | Ryzen 9 3950X | RTX 4070 Ti | 32GB RAM | 10TB SSDs | 5K+4K HDR monitors

Canon Vixia GX10 (4K 60p) | HF G30 (HD 60p) | Yi Action+ 4K | 360Fly 4K 360°

Quote: Looks like you are also getting the smaller file sizes for the 3_3_wall when using CPU only - I was wondering if it was only my computer - looks like that is "normal" also.

Yes, a little strange to me, CPU encoding overall rather good at meeting bitrate. Funny the issue occurs with Gaussian Blur, the effect in the original 3_3_wall.pds. That effect often used in photo and video editing to mask effects of jagged edges, especially of straight lines, when going to DVD type output. A tiny bit, based on original frame size, often hides things very well without a significant sacrifice on clarity. I film a lot of indoor court sports and often deal with jagged court lines as camera pans. I currently run everything through a third party editor to add just a little Gaussian Blur and it does wonders for DVD type productions out of my higher resolution source.
Even if you use a 1920x1080 24Mbps source, PD13 with Gaussian Blur effect applied will downgrade the output bitrate, it's not just a Boats.wmv effect. The downgrade in bitrate is a function of how much Gaussian Blur is applied.

Quote: No matter which computer, the NB Fx's are demanding/using/ sucking out lots of power, in PD as well as in another editor I have. Back in September / October, I posted something about it:

Yes, same effect you noted earlier I believe. Based on the CPU load profile in PD with certain effects, to me likely a coding implementation issue, but you indicate the same with another editor so maybe NB effect issue. Needs some attention as not real practical to use at this point.


Some else asked me if I would describe the loads a little better and what was done and what's really in the previous table. The chart attached shows loadings for the GTX650 with OpenCL and HVE settings applied and the Beating FX being evaluated. It's a good effect to understand as it's an OpenCL accelerated effect which PD denotes with the GPU icon in left corner of effect.
Recent Nvidia cards (GTX600's and newer) have a Integrated encoder for certain video formats on the card. GPU-Z shows both this VE load and the GPU load. VE performance indicator for HVE encoding and GPU for OpenCL effect crunching. The basic effect of this is simply to distribute load around a little for faster encoding, hardware dependent. One obviously would like to maintain quality. Older Nvida cards only had a CUDA encoder so load would show on the GPU stats, no VE. Earlier PD13 versions didn't support the VE encoding, only CUDA. When one unchecks the OpenCL in pref, the GPU will unload as the CPU now does that task as well so it will load up more or the encode process will simply take longer, very hardware dependent which will work best.
Recent AMD cards (HD7900 and newer) are somewhat similar, except their Integrated encoder is VCE (Video Coding Engine). To my knowledge they don't currently offer a VCE performance monitor, only a GPU load monitor. GPU-Z will only show GPU load, so if using HVE encoding on AMD card it's hard to monitor that load with GPU-Z as it's not represented in GPU load as the onboard VCE is doing the work. I looked around some but never found a VE load monitor like Nvidia supports. Intel HDxxxx somewhat similar, there everything lumps in GPU load stats.

Tony, optodata, thanks, this type of stuff not up everyone’s alley but some enjoy! Many valued contributors on the forum.

Jeff

This is just to show how confusing Hardware Encoding settings are:

One would think that if Hardware Encoding is turned off in the Produce tab then PD will use the CPU only.

This is not the case (as others have noted).

When "Enable OpenCL technology to speed up video preview/render" is enabled it acts as if hardware video encoding is enabled (even if it is not).

In my case the graphic card is weak ( Radeon HD5450 just makes the PD hardware requirments).

with these settings:



It produces the following. Notice the GPU load and the black frames in the video being rendered. These black frames are also in the final video.





Once I disable "Enable OpenCL technology to speed up video preview/render" the produce renders proper with no load on the GPU.

Win8.1 Pro x64 / Dual x5670 / 24GB / GTX960 4GB / 240GB SSD + 640GB HDD / PD13 Ultimate

Quote: This is just to show how confusing Hardware Encoding settings are:

One would think that if Hardware Encoding is turned off in the Produce tab then PD will use the CPU only.

Not all I guess think that way. As I've mentioned many times, I believe these settings control two totally different encoding aspects. Below is a repeat of http://forum.cyberlink.com/forum/posts/list/40407.page .

CL provided the details in this FAQ, http://www.cyberlink.com/support/product-faq-content.do?id=12777&prodId=4&prodVerId=-1&CategoryId=-1&keyword=hardware%20acceleration

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.

Your results are totally what is to be expected for the settings you have selected and the FX's in this timeline. Remove the accelerated FX's, OpenCL setting in pref is mundane then as there is nothing for the GPU to do when you are using CPU encoding and GPU will be idle. So basically when a timeline has accelerated FX's one can either get the assistance of the GPU or simply use the CPU to apply this effect. This is independant of how the final encoding is done, CPU or HVE which is controlled in the "Produce" or "Create Disc' areas. What a user should do is very depedent on hardware one has and timeline content.

Jeff

I guess I'm to dum to understand how this works.

When choosing produce - I want to pick what it should use CPU/GPU on the produce tab.
In my case I have nothing I can choose on the produce tab (all grayed out).

When I Enable OpenCL technology and then produce the video the result is rubbish (black frames in the video as shown in my post above - not in preview only but also in the result). This is the Gaussian Blur affect - that is supported in PD as AMD accelerated affect.

When I disable OpenCL technology and then produce the video (this is the only way to get CPU usage only) the resulting video is good.

In other words one can't enable OpneCL in the time-line preview and disable OpenCL in the produce tab without going into system properties ever time. Win8.1 Pro x64 / Dual x5670 / 24GB / GTX960 4GB / 240GB SSD + 640GB HDD / PD13 Ultimate

Here I am using, 14.12 AMD Catalyst Omega, "Open CL" + "LVH" works well for my video card, this signature is the same for your AMD Radeon HD 5450 2GB.
http://support.amd.com/en-us/download/desktop?os=Windows%207%20-%2064 AMD-FX 8350 / 8GB DDR3
SSD SUV400S37240G / 2-HD WD 1TB
AMD Radeon R9 270 / AOC M2470SWD
Windows 7-64 / PD16 Ultimate

Quote: In other words one can't enable OpneCL in the time-line preview and disable OpenCL in the produce tab without going into system properties ever time.

Correct, for the current implementation.

With a vintage card as yours and current PD13 release, I wouldn't use it to accelerate anything, your dual CPU's much better choice.

Jeff

I agree Jeff - In my case I only want to use my CPU, but my point was that others also see the HA radio button on the the produce tab and think that is the only way the GPU will be used when a video is being produced and that is not the case.

HA is very sensitive to driver version and what hardware you have (not as important during timeline preview) but very important in the produce section so that you final video is the best quality it can be.


Win8.1 Pro x64 / Dual x5670 / 24GB / GTX960 4GB / 240GB SSD + 640GB HDD / PD13 Ultimate

Guys, I'm building a new system for 4K editing. Have been using PD13 on an older system for 1080p editing. I read this thread because it seemed to have the perfect title to help me either verify that my GPU choice was okay or that it should be changed. I believe I now know less than when I started. :o) I was in IT for 25 years, primarily on the software side, but my eyes are glazing over with some of the posts here. I'm looking for good, not ultimate, in producing 4K/1080p output from 4K original files. I'm considering an i7-4790K CPU and GTX 960 GPU. Just today I've found that the 900 series isn't listed in PD's hardware requirements but aren't sure if that's because it isn't recommended or the list just isn't inclusive. I'm willing to put up to $100 more than the cost of the 960 ($240) if I need to. Any specific suggestions on the viability of the 960 or a better choice? Thanks. Tom
i7-4790K, Asus Z97-A, 16GB RAM, GTX 960, SSDs, Monoprice 28" 4K CrystalPro, Acer 23" 1080p H236HL - Full system at http://pcpartpicker.com/p/kYxw23

Hi Tom,
Please post your question as a New Topic and reference this thread if you need to. Adding new questions where you are not the OP just keeps expanding a thread beyond the OP's original post.

Thread closed.
Dafydd