Announcement: Our new CyberLink Feedback Forum has arrived! Please transfer to our new forum to provide your feedback or to start a new discussion. The content on this CyberLink Community forum is now read only, but will continue to be available as a user resource. Thanks!
CyberLink Community Forum
where the experts meet
| Advanced Search >
Bug : Newblue Titler is eating GPU RAM like crazy
Julien Pierre [Avatar]
Contributor Joined: Apr 14, 2011 01:34 Messages: 476 Offline
[Post New]

  1. go to edit/preferences/hardware acceleration

  2. uncheck "Enable OpenCL technology"

  3. Uncheck "Enable hardware decoding"

  4. Restart PowerDirector, just in case

  5. Open up a project with some 4K clips in it .
    I'm using the one at https://drive.google.com/uc?export=download&id=0B1eSSO_7gwqed2tWdF9TNWxiZ0E

  6. Click produce

  7. Click H264

  8. Click M2TS

  9. Select AVC 4K 4096x2160/30p

  10. Uncheck "fast video rendering technology" to do a software encoding. This should also do a software decode, since that was disabled above in step 3. In other words, PowerDirector should not use the GPU at all for either encode or decode

  11. Start GPU-Z

  12. Check the video load usage and GPU RAM usage

  13. Click "start" in PowerDirector to start rendering

  14. Check the video load usage and GPU RAM usage as the progress starts. Both shoot way up, indicating that PowerDirector is still doing a GPU hardware decode of the clips, despite having been instructed not to do so through the settings

This message was edited 2 times. Last update was at Oct 09. 2015 23:49

MSI X99A Raider
Intel i7-5820k @ 4.4 GHz
32GB DDR4 RAM
Gigabyte nVidia GTX 960 4GB
480 GB Patriot Ignite SSD (boot)
2 x 480 GB Sandisk Ultra II SSD (striped)
6 x 1 TB Samsung 860 SSD (striped)

2 x LG 32UD59-B 32" 4K
Asus PB238 23" HD (portrait)
Julien Pierre [Avatar]
Contributor Joined: Apr 14, 2011 01:34 Messages: 476 Offline
[Post New]
I'm attaching a screen capture of the issue.

At 0:23 in the video, you can see GPU RAM usage of 952 MB. And GPU load is low accross the board.

At 0:44, after a couple of frames have been processed, you can see the GPU memory shooting up to 1927MB, and GPU load of 51%.
 Filename
Capture.mp4
[Disk]
 Description
GPU decode still happening even if disabled
 Filesize
23346 Kbytes
 Downloaded:
278 time(s)
MSI X99A Raider
Intel i7-5820k @ 4.4 GHz
32GB DDR4 RAM
Gigabyte nVidia GTX 960 4GB
480 GB Patriot Ignite SSD (boot)
2 x 480 GB Sandisk Ultra II SSD (striped)
6 x 1 TB Samsung 860 SSD (striped)

2 x LG 32UD59-B 32" 4K
Asus PB238 23" HD (portrait)
Julien Pierre [Avatar]
Contributor Joined: Apr 14, 2011 01:34 Messages: 476 Offline
[Post New]
Filed a bug with Cyberlink as CS001521449 .
MSI X99A Raider
Intel i7-5820k @ 4.4 GHz
32GB DDR4 RAM
Gigabyte nVidia GTX 960 4GB
480 GB Patriot Ignite SSD (boot)
2 x 480 GB Sandisk Ultra II SSD (striped)
6 x 1 TB Samsung 860 SSD (striped)

2 x LG 32UD59-B 32" 4K
Asus PB238 23" HD (portrait)
Julien Pierre [Avatar]
Contributor Joined: Apr 14, 2011 01:34 Messages: 476 Offline
[Post New]
Looks like the root cause of the high GPU load and GPU RAM usage is Newblue titler here.
If I disable the title track, all is fine. GPU RAM during rendering is actually only 662MB, and the GPU load is 0%.

So, it wasn't PD doing a GPU hardware decode after all.
Still a bug. There aren't any settings that I could find to disable the use of the GPU for Newblue titler.

It's also quite insane that having just two text elements, one with the word "HD" and another with the word "4K", causes the GPU RAM usage to go from 662MB to 1927MB - an additional 1265 of GPU RAM, and 51% GPU load.

I guess that means Newblue is basically unusable in 4K with a 2GB video card as it can consume all the GPU RAM just by itself.

This message was edited 3 times. Last update was at Oct 09. 2015 09:08

MSI X99A Raider
Intel i7-5820k @ 4.4 GHz
32GB DDR4 RAM
Gigabyte nVidia GTX 960 4GB
480 GB Patriot Ignite SSD (boot)
2 x 480 GB Sandisk Ultra II SSD (striped)
6 x 1 TB Samsung 860 SSD (striped)

2 x LG 32UD59-B 32" 4K
Asus PB238 23" HD (portrait)
Dafydd B [Avatar]
Senior Contributor Joined: Aug 26, 2006 08:20 Messages: 11973 Offline
[Post New]
An interesting read.
Dafydd
JL_JL [Avatar]
Senior Contributor Location: Arizona, USA Joined: Oct 01, 2006 20:01 Messages: 6091 Offline
[Post New]
Quote:

  1. Check the video load usage and GPU RAM usage as the progress starts. Both shoot way up, indicating that PowerDirector is still doing a GPU hardware decode of the clips, despite having been instructed not to do so through the settings


Decode won't show up in GPU load for Nvidia 750Ti. To my knowledge that's essentially OpenCL coding load. I'd infer from this load that NB Titler Pro uses OpenCL, at least the PD implementation.

To me this looks like NB Titler, at least within PD, simply has a memory leak. It appears to jump to max capacity of the card and bounces off this during encode process. I tried a 1GB RAM card and VRAM simply bounces off max, about 1 in 10 encodes for me fails. Tried a 2GB card and memory jumps to max capacity of the card and bounces off and have about the same failure rate. Similar to what you noted with your 2GB card.

Quote: So, it wasn't PD doing a GPU hardware decode after all.
Still a bug. There aren't any settings that I could find to disable the use of the GPU for Newblue titler.

I'd concur, there are other features where OpenCL via GPU cannot be turned off as well via PD pref, for instance, effect GPU Waterfall, as well as others.

Jeff
Julien Pierre [Avatar]
Contributor Joined: Apr 14, 2011 01:34 Messages: 476 Offline
[Post New]
Jeff,

Thanks for trying on your other cards. Seems like NewBlue titler is simply broken.

Note that I'm using the NewBlue Titler Pro 1.0 that came bundled with PD13, but using it in PD14, as I bought PD13 Ultimate, but upgraded to PD14 Ultra.

I don't know if that's part of the problem. I'm not sure if NewBlue Titler Pro was updated for PD14 or not. Do you happen to know ?

It seems you reproduced the high GPU RAM usage in NewBlue Titler, so it's likely not fixed in the latest version, even if it was updated.

I did verify that NewBlue Titler won't run at all when using the basic VGA drivers - and losing 2 out of 3 displays, and running one of them at 1600x1200 instead of 2560x1600 with that driver is not particularly fun.

Is there another way in PowerDirector to create those 2 text elements without using NewBlue titler ?

I looked at some of the basic title effects in PD but couldn't find a suitable simple one that I could easily make last for the entire clip duration. That's why I ended up using NewBlue. I would gladly stop using NewBlue Titler if there was another way. MSI X99A Raider
Intel i7-5820k @ 4.4 GHz
32GB DDR4 RAM
Gigabyte nVidia GTX 960 4GB
480 GB Patriot Ignite SSD (boot)
2 x 480 GB Sandisk Ultra II SSD (striped)
6 x 1 TB Samsung 860 SSD (striped)

2 x LG 32UD59-B 32" 4K
Asus PB238 23" HD (portrait)
JL_JL [Avatar]
Senior Contributor Location: Arizona, USA Joined: Oct 01, 2006 20:01 Messages: 6091 Offline
[Post New]
Quote:
Is there another way in PowerDirector to create those 2 text elements without using NewBlue titler ?

I looked at some of the basic title effects in PD but couldn't find a suitable simple one that I could easily make last for the entire clip duration. That's why I ended up using NewBlue. I would gladly stop using NewBlue Titler if there was another way.


I did not see anything special in your text and was unclear why for that one would use NB Titler, I'd simply create with the basic default title in PD and drag to the full extent of your clip, just like your NB Titler.

Since NB Titler is at like version 4 and yet PD14 still has v1 per http://www.cyberlink.com/products/director-suite/compare_en_US.html , no I don't think it's changed at all from PD13.

Jeff
Julien Pierre [Avatar]
Contributor Joined: Apr 14, 2011 01:34 Messages: 476 Offline
[Post New]
Quote:
Quote:
Is there another way in PowerDirector to create those 2 text elements without using NewBlue titler ?

I looked at some of the basic title effects in PD but couldn't find a suitable simple one that I could easily make last for the entire clip duration. That's why I ended up using NewBlue. I would gladly stop using NewBlue Titler if there was another way.


I did not see anything special in your text and was unclear why for that one would use NB Titler, I'd simply create with the basic default title in PD and drag to the full extent of your clip, just like your NB Titler.

Since NB Titler is at like version 4 and yet PD14 still has v1 per http://www.cyberlink.com/products/director-suite/compare_en_US.html , no I don't think it's changed at all from PD13.

Jeff




I guess I never found the "basic default title" in PD . I need to look harder.

And it was a lot more work to make that NB titler last the whole clip than just dragging it to the full extent of the clip - I had to manually enter duration. Drove me crazy. I will be glad to get rid of it. Sometimes software is more valuable without the crappy add-ons ! Makes me glad I didn't pay for PD 14 Ultimate.

Seems Newblue has dropped support for Powerdirector in Titler . Titler Pro 4 doesn't support PD at all. And it costs $299 anyway. I can't see too many PD users wanting to fork that amount of money just for this plug-in.

Still, it will be very interesting to see if Cyberlink can get Newblue to fix the horrid GPU RAM utilization in a patch to Titler v1 or not. Guess we will find out just how much support there actually is for those add-ons. MSI X99A Raider
Intel i7-5820k @ 4.4 GHz
32GB DDR4 RAM
Gigabyte nVidia GTX 960 4GB
480 GB Patriot Ignite SSD (boot)
2 x 480 GB Sandisk Ultra II SSD (striped)
6 x 1 TB Samsung 860 SSD (striped)

2 x LG 32UD59-B 32" 4K
Asus PB238 23" HD (portrait)
JL_JL [Avatar]
Senior Contributor Location: Arizona, USA Joined: Oct 01, 2006 20:01 Messages: 6091 Offline
[Post New]
Try this default title in your own pds file.

Jeff
 Filename
4ktest-minuet_DT.pds
[Disk]
 Description
 Filesize
676 Kbytes
 Downloaded:
388 time(s)
Julien Pierre [Avatar]
Contributor Joined: Apr 14, 2011 01:34 Messages: 476 Offline
[Post New]
Quote: Try this default title in your own pds file.

Jeff


Thank you very much, that was very helpful.

I tried a bunch of renderings with this project, and with either the hardware or software encoder.

I also compared rendering time with the original project using Newblue, and an identical project using no titles at all (title track turned off).

And lastly, because optodata was saying in another thread that the older 337.88 drivers were performing better, I also tested that.

I have attached the results of all the tests in a screenshot.

The main takeaways are :

1) Newblue Titler Pro v1.0 is very good at filling the entire GPU memory. The default titles are much more efficient that way. My guess is that NewBlue Titler Pro v1.0 was never tested with 4K. And it is not usable with 4K in its current state.

2) Strangely, the PD hardware renderer actually uses a bit less GPU RAM when rendering with the default titles, than without any title track at all. You can see that for example by comparing test #1 with test #4, or test #2 with test #5 .

3) There was a significant increase in OS baseline GPU RAM usage between nVidia drivers 337.88 and 347.88 . About 200 MB more .

4) I didn't run into any issue with "out of GPU memory" this time, because I didn't have anything else of significance running on the machine at the time - no browser in particular. Just GPU-Z, HWmonitor, Task manager, and Openoffice.

5) Test #8 (and test #15, to a lesser extent) was seriously screwed up compared to all the others. During that test, the machine was nearly frozen, even though the CPU usage was down to the low 30% range . The bus load in GPU-Z had some very high peaks. Even just trying to drag the Task manager window during the rendering was very slow. I think this was due to the out of GPU RAM condition with Newblue, and memory being copied accross the PCIe 2.0 bus (there is no PCIe 3.0 on any AM3+ motherboard, sadly). I will attach a 4K video shot with my Note 4 of what the computer was acting like during this particular rendering.

I had to cut a few seconds in the middle of it when I noticed an envelope with my home address on it that came into the frame. You can really read everything with 4K

The day before, I actually had 2 BSODs during similar renderings, after hearing the PC speaker beep, which indicated the CPU was running too hot. This started to make me question my overclock. I decided to restore the AMD "cool & quiet" in the BIOS, even though that interferes with my audio recording with my Firewire interface as it adds pops & clicks into the recordings. At least I didn't have any other BSOD since restoring C&Q, .

6) When using titles, even with the default titles, the hardware acceleration is fairly minimal. Only an 11% difference between test #1 and tests #2 and #3 for example. And 15% between test #4 and test #5, also. The main benefit of the HA seems to be somewhat lower CPU utilization and lower temp, not so much as a faster rendering time. Presumably when using other CPU-based software effects, the remaining available CPU cycles would help.
[Thumb - pd14.png]
 Filename
pd14.png
[Disk]
 Description
Too many tests.
 Filesize
336 Kbytes
 Downloaded:
84 time(s)
 Filename
cutcapture.m2ts
[Disk]
 Description
Computer acting crazy during test #8
 Filesize
220605 Kbytes
 Downloaded:
223 time(s)

This message was edited 2 times. Last update was at Oct 10. 2015 12:40

MSI X99A Raider
Intel i7-5820k @ 4.4 GHz
32GB DDR4 RAM
Gigabyte nVidia GTX 960 4GB
480 GB Patriot Ignite SSD (boot)
2 x 480 GB Sandisk Ultra II SSD (striped)
6 x 1 TB Samsung 860 SSD (striped)

2 x LG 32UD59-B 32" 4K
Asus PB238 23" HD (portrait)
JL_JL [Avatar]
Senior Contributor Location: Arizona, USA Joined: Oct 01, 2006 20:01 Messages: 6091 Offline
[Post New]
Quote:
6) When using titles, even with the default titles, the hardware acceleration is fairly minimal. Only an 11% difference between test #1 and tests #2 and #3 for example. And 15% between test #4 and test #5, also. The main benefit of the HA seems to be somewhat lower CPU utilization and lower temp, not so much as a faster rendering time. Presumably when using other CPU-based software effects, the remaining available CPU cycles would help.


That's simply because you are CPU throttled vs your GPU capability when using HA. Use the below of your test case with the default title and HA as demonstration

GTX650 in Mid level CPU box, VE=50%, CPU=~100% Encode time=164 seconds
GTX650 in Higher end CPU box, VE=88%, CPU=~95% Encode time=74 seconds

The same exact GPU card in two different boxes with the same exact driver versions with a 2X change in speed. So what is the capability of the GTX650 in HA encoding? Some may say only marginal and post pic show partial load, others claim significant. It really depends on what you put the GTX650 in as you simply need to get the data to the GPU. I wrote a thread on this, I will maybe try and locate it.

Jeff

This message was edited 1 time. Last update was at Oct 10. 2015 12:48

Julien Pierre [Avatar]
Contributor Joined: Apr 14, 2011 01:34 Messages: 476 Offline
[Post New]
Quote:
Quote:
6) When using titles, even with the default titles, the hardware acceleration is fairly minimal. Only an 11% difference between test #1 and tests #2 and #3 for example. And 15% between test #4 and test #5, also. The main benefit of the HA seems to be somewhat lower CPU utilization and lower temp, not so much as a faster rendering time. Presumably when using other CPU-based software effects, the remaining available CPU cycles would help.


That's simply because you are CPU throttled vs your GPU capability when using HA. Use the below of your test case with the default title and HA as demonstration

GTX650 in Mid level CPU box, VE=50%, CPU=~100% Encode time=164 seconds
GTX650 in Higher end CPU box, VE=88%, CPU=~95% Encode time=74 seconds

The same exact GPU card in two different boxes with the same exact driver versions with a 2X change in speed. So what is the capability of the GTX650 in HA encoding? Some may say only marginal, others significant. It really depends on what you put the GTX650 in as you simply need to get the data to the GPU. I wrote a thread on this, I will maybe try and locate it.

Jeff


That much is obvious - if you are bottlenecked on CPU, you can't benefit from the GPU HA.

However, in test #1, the one with HW acceleration, the CPU was not peaked - it was at 80 to 95% - meaning the CPU was not the bottleneck, and the max capabilities of the 750Ti card were being used.

And in test #3, the GPU was not used at all, and CPU was 95-100%, nearly peaked (but should have been 99-100, don't know why it wasn't), but test #3 only took about 10% more time than test #1 .

I'm not really sure how a more powerful CPU would have helped here - IMO, it would only have made the software encode go faster, and the GPU encode would not have changed much, because it was bottlenecked on the GPU, not the CPU.

But of course we can't really see that in GPU-Z, it doesn't seem to display the relevant GPU usage statistics for the NVENC, from what I can tell. MSI X99A Raider
Intel i7-5820k @ 4.4 GHz
32GB DDR4 RAM
Gigabyte nVidia GTX 960 4GB
480 GB Patriot Ignite SSD (boot)
2 x 480 GB Sandisk Ultra II SSD (striped)
6 x 1 TB Samsung 860 SSD (striped)

2 x LG 32UD59-B 32" 4K
Asus PB238 23" HD (portrait)
JL_JL [Avatar]
Senior Contributor Location: Arizona, USA Joined: Oct 01, 2006 20:01 Messages: 6091 Offline
[Post New]
Quote:
Quote:
Quote:
6) When using titles, even with the default titles, the hardware acceleration is fairly minimal. Only an 11% difference between test #1 and tests #2 and #3 for example. And 15% between test #4 and test #5, also. The main benefit of the HA seems to be somewhat lower CPU utilization and lower temp, not so much as a faster rendering time. Presumably when using other CPU-based software effects, the remaining available CPU cycles would help.


That's simply because you are CPU throttled vs your GPU capability when using HA. Use the below of your test case with the default title and HA as demonstration

GTX650 in Mid level CPU box, VE=50%, CPU=~100% Encode time=164 seconds
GTX650 in Higher end CPU box, VE=88%, CPU=~95% Encode time=74 seconds

The same exact GPU card in two different boxes with the same exact driver versions with a 2X change in speed. So what is the capability of the GTX650 in HA encoding? Some may say only marginal, others significant. It really depends on what you put the GTX650 in as you simply need to get the data to the GPU. I wrote a thread on this, I will maybe try and locate it.

Jeff


That much is obvious - if you are bottlenecked on CPU, you can't benefit from the GPU HA.

However, in test #1, the one with HW acceleration, the CPU was not peaked - it was at 80 to 95% - meaning the CPU was not the bottleneck, and the max capabilities of the 750Ti card were being used.

And in test #3, the GPU was not used at all, and CPU was 95-100%, nearly peaked (but should have been 99-100, don't know why it wasn't), but test #3 only took about 10% more time than test #1 .

I'm not really sure how a more powerful CPU would have helped here - IMO, it would only have made the software encode go faster, and the GPU encode would not have changed much, because it was bottlenecked on the GPU, not the CPU.

But of course we can't really see that in GPU-Z, it doesn't seem to display the relevant GPU usage statistics for the NVENC, from what I can tell.


Avg of 87% CPU in #1 and 97% in #3, both CPU governed. Your highest VE load in any of your tests for this format, ~20%, I'll guarantee that's not the throughput capability of that card. So you think my little GTX650 can simply beat your GTX750Ti by a factor of 2.7X (74 vs 200 seconds) for case #1? If a GTX750Ti is available I'll drop it in a show a load significantly higher than your 13-16%VE for #1.

GPUZ VE is NVENC load, what else do you want?

Jeff
optodata
Senior Contributor Location: California, USA Joined: Sep 16, 2011 16:04 Messages: 8630 Offline
[Post New]
Quote: ...Seems Newblue has dropped support for Powerdirector in Titler. Titler Pro 4 doesn't support PD at all. And it costs $299 anyway. I can't see too many PD users wanting to fork that amount of money just for this plug-in...


That's not quite correct. TP 4 is available as a standalone product just like TP1, and it actually works with any version of PD. There's no true editor integration in either version, and the only difference is that PD13 and 14 let you place a TP title from the Title Room on the timeline, and double-clicking on the title launches TP1.

From there, you build your title in the stand-alone app and when you close it, the title is imported back to the timeline much in the same way that ColorDirector, AudioDirector or WaveEditor do when you launch them from PD's timeline.

TP4 works separately and you essentially produce the title to a .MOV (for action titles) or export to a JPG or even the clipboard for a static title, and then import (or paste) into any version of PD.

It's basically one extra step, and while technically TP4 is "not supporting PD at all" because you can't launch it from the timeline like TP1, it certainly is compatible with PD and provides far deeper creative options.

There are ways around the steep price as well, as I picked it up for $104 when they had their customer appreciation sale last month. Don't get me wring, it's still a fair chuck of change but it's is a lot more palatable than the full list price.

One other benefit is that the memory leak apparently caused the TP1 would completely go away because the app is finshed when you export the title and it will never be called by PD when producing.

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°
Julien Pierre [Avatar]
Contributor Joined: Apr 14, 2011 01:34 Messages: 476 Offline
[Post New]
Quote:
Avg of 87% CPU in #1 and 97% in #3, both CPU governed. Your highest VE load in any of your tests for this format, ~20%, I'll guarantee that's not the throughput capability of that card. So you think my little GTX650 can simply beat your GTX750Ti by a factor of 2.7X (74 vs 200 seconds) for case #1? If a GTX750Ti is available I'll drop it in a show a load significantly higher than your 13-16%VE for #1.


What I don't understand is how you can get pretty similar CPU utilization to mine of 87% CPU in test #1, and yet you are getting much higher GPU load than I am. Something here just doesn't make sense.

Is the PCIe 2.0 bus possibly the bottleneck on my system, rather than either the GPU or CPU ? Both memory controller and bus load are showing as quite low in test #1 on my system. What were yours like ?

Perhaps your GTX 650 has 4GB of RAM instead to my GTX 750Ti with only 2GB ?

Is your system that got 74 seconds rendering time using PCIe 3.0 ?

Or perhaps the Quicksync and MultiGPGPU was in use and is what made it use a very different code path and fly somehow ? I'm running with an AMD CPU which does not have Quicksync. If you have quicksync, I don't suppose there is any setting in PD for you to disable just the Quicksync, and only use the nVidia GPU ?

It would help if you could detail the system specs for your two machines that got the 74 and 200 second times - CPU model, motherboard, version of PCIe bus, exact GPU version and GPU RAM.

GPUZ VE is NVENC load, what else do you want?


OK, I didn't know that.

I just ran another test - just put the trim-4k clip on the timeline on a track by itself - no effects, nothing else. Thus, the CPU should have essentially nothing else to do but pass the data to the GPU to encode - no processing of masks and crops of multiple clips like in the 4ktest-minuet project.

I rendered this lone clip to H.264 M2TS AVC 4K 3840x2160/30p. OpenCL and hardware decode were disabled.

The rendering time was 0:44 .

GPU-Z showed AVG GPU load 12%, AVG memory controller load of 7%, AVG video engine load of 55%, and AVG bus interface load of 5%.

CPU utilization was was between 41% and 58%.

In other words, both the CPU utilization and GPU video engine load were about half. This doesn't make sense, unless there is some sort of bus bottleneck, which there doesn't appear to be, or some huge inefficiency somehow in PowerDirector on my system.

What are your numbers for this test ?

FYI, a software encode for this same test, with OpenCL & hardware decoder also disabled, took 47 seconds - almost the same as the hardware encode. And CPU utilization was only about 70% throughout. It seems that PD is just not able to utilize my entire CPU for this clip, somehow ! The GPU-Z was showing near 0% for all values in this test. So, PD cannot possibly have been bottlenecked on the GPU or bus in this test. The mystery deepens.

This message was edited 2 times. Last update was at Oct 10. 2015 22:53

MSI X99A Raider
Intel i7-5820k @ 4.4 GHz
32GB DDR4 RAM
Gigabyte nVidia GTX 960 4GB
480 GB Patriot Ignite SSD (boot)
2 x 480 GB Sandisk Ultra II SSD (striped)
6 x 1 TB Samsung 860 SSD (striped)

2 x LG 32UD59-B 32" 4K
Asus PB238 23" HD (portrait)
Julien Pierre [Avatar]
Contributor Joined: Apr 14, 2011 01:34 Messages: 476 Offline
[Post New]
Quote:
I rendered this lone clip to H.264 M2TS AVC 4K 3840x2160/30p. OpenCL and hardware decode were disabled.

The rendering time was 0:44 .

GPU-Z showed AVG GPU load 12%, AVG memory controller load of 7%, AVG video engine load of 55%, and AVG bus interface load of 5%.

CPU utilization was was between 41% and 58%.

In other words, both the CPU utilization and GPU video engine load were about half. This doesn't make sense, unless there is some sort of bus bottleneck, which there doesn't appear to be, or some huge inefficiency somehow in PowerDirector on my system.

What are your numbers for this test ?

FYI, a software encode for this same test, with OpenCL & hardware decoder also disabled, took 47 seconds - almost the same as the hardware encode. And CPU utilization was only about 70% throughout. It seems that PD is just not able to utilize my entire CPU for this clip, somehow ! The GPU-Z was showing near 0% for all values in this test. So, PD cannot possibly have been bottlenecked on the GPU or bus in this test. The mystery deepens.




I hate it when test results are not repeatable. I closed my browser and ran both again. I enabled the audio track also (it was disabled, per the project).

Now, PD was able to do a HW encode of the clip in only 19 seconds, Video engine load reached 98%, GPU load at 1% and memory controller load at 10-13%. Bus interface load 0%. CPU was at only 4-5%.

And the software encode peaked the CPU at 99-100% as you would expect, and finished in 70seconds (1:10).

I reopened my browser and redid both - same results that make complete sense...

This message was edited 1 time. Last update was at Oct 10. 2015 23:17

MSI X99A Raider
Intel i7-5820k @ 4.4 GHz
32GB DDR4 RAM
Gigabyte nVidia GTX 960 4GB
480 GB Patriot Ignite SSD (boot)
2 x 480 GB Sandisk Ultra II SSD (striped)
6 x 1 TB Samsung 860 SSD (striped)

2 x LG 32UD59-B 32" 4K
Asus PB238 23" HD (portrait)
Julien Pierre [Avatar]
Contributor Joined: Apr 14, 2011 01:34 Messages: 476 Offline
[Post New]
Quote:
I rendered this lone clip to H.264 M2TS AVC 4K 3840x2160/30p. OpenCL and hardware decode were disabled.

...
FYI, a software encode for this same test, with OpenCL & hardware decoder also disabled, took 47 seconds - almost the same as the hardware encode. And CPU utilization was only about 70% throughout. It seems that PD is just not able to utilize my entire CPU for this clip, somehow ! The GPU-Z was showing near 0% for all values in this test. So, PD cannot possibly have been bottlenecked on the GPU or bus in this test. The mystery deepens.


Only explanation that possibly makes sense about this low CPU is that the SSD may have been in the middle of TRIMing after all the renderings I did, and somehow that held back the rendering which was serialized on it. I had been rendering with source file on my RAID HDD array, and output files on the RAID SSD array (C: system drive).

And the second test must have been a HW encode and not software or it should have taken much longer somehow.

I should probably switch to using source files on SSD and output to HDD for performance test.

My SSD is way too small to hold all my source files. I guess another upgrade is in my future.

This message was edited 1 time. Last update was at Oct 10. 2015 23:18

MSI X99A Raider
Intel i7-5820k @ 4.4 GHz
32GB DDR4 RAM
Gigabyte nVidia GTX 960 4GB
480 GB Patriot Ignite SSD (boot)
2 x 480 GB Sandisk Ultra II SSD (striped)
6 x 1 TB Samsung 860 SSD (striped)

2 x LG 32UD59-B 32" 4K
Asus PB238 23" HD (portrait)
Julien Pierre [Avatar]
Contributor Joined: Apr 14, 2011 01:34 Messages: 476 Offline
[Post New]
FYI, repeated test #17 (same as #1, but with latest nVidia drivers) - here is what the CPU usage looked like during the rendering.

There were plenty of lows in the 80% range in the middle, but also some highs above 95%.

Perhaps the project really is CPU bound on my system, but it didn't appear to me at first.

Rendering time was 3:32 (212 seconds) , almost the same as the 208 seconds I recorded in the table last night, so at least that one is repeatable.
[Thumb - cpu.png]
 Filename
cpu.png
[Disk]
 Description
 Filesize
96 Kbytes
 Downloaded:
79 time(s)
MSI X99A Raider
Intel i7-5820k @ 4.4 GHz
32GB DDR4 RAM
Gigabyte nVidia GTX 960 4GB
480 GB Patriot Ignite SSD (boot)
2 x 480 GB Sandisk Ultra II SSD (striped)
6 x 1 TB Samsung 860 SSD (striped)

2 x LG 32UD59-B 32" 4K
Asus PB238 23" HD (portrait)
Neil.F.1955 [Avatar]
Senior Contributor Joined: Mar 07, 2012 09:15 Messages: 1303 Offline
[Post New]
Hi everyone!

One thing I've learned is DON'T RENDER in AVCHD using PD8! Tried it once, took nearly forever to render a 1-hour video. So, even though the new digital video camera I bought a few weeks back shoots in AVCHD or MP4, I've opted for MP4 in the camera, and for PD14(when I get it), I'll be sticking with tried-and-true MPEG2 which, in most cases renders so fast, you barely have time to sneeze before your video is rendered! That's the case with PD8. As for titling applications in PD14, is there an option? NewBlue or regular titling? As it is, I create my own animated titles, using letters I designed myself using Microsoft Paint. Having the vastly-expanded number of PiP tracks in PD14 with lift my game considerably there.

Cheers!

Neil.
Powered by JForum 2.1.8 © JForum Team