Welcome, Guest
Username Password: Remember me
  • Page:
  • 1
  • 2

TOPIC: Improved Background Export [feature]

Re: Improved Background Export [feature] 8 months, 1 week ago #191388

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 11352
  • 8 months, 1 week ago
Rubenstein reminds me of the way my grandmother used to play.

Re: Improved Background Export [feature] 8 months, 1 week ago #191398

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 3374
  • 8 months, 1 week ago
So, now I'm back on a stationary computer with a mouse and the real keyboard. Mine attempts with mobile devices to throw short comments on complex technical contexts into a discussion obviously leads to misunderstandings.

hugly wrote:
Schrauber,
What do you think, where is the bottleneck?

I think, although there is probably a statistical focus, this depends on the individual case.

hugly wrote:
... I'd suggest implementing either an automatic which allows simultaneous editing and background export and balances load of the processes ...

If this solution is sought, I would wish that under almost all conditions, it should be guaranteed that no system component slows down the Edit & Playback. If the export were speed up based only on the CPU data, then this would also increase the GPU load, data transfer load, and so on. However, if in some cases the CPU is not the bottleneck, then another component would touch the 100% limit, slowing down the edit & playback.
One solution could be that the user could optionally choose the previous functionality. This leads to the question of how this setting can be found and what is enabled by default.

hugly wrote:
... or..., some settings adjustable by the user to enable/disable background export while playing and to assign a certain number of cores to foreground/background as soon as export in background is active. An alternative could be a separate program just to run scheduled export tasks in the background ...


This should be easier to implement, assuming that the export works correctly. Up to now the export on my system works without any problems even if it runs slower than in real time.

OT: Personally, I think proxy creation could give even greater benefit by optimizing load balancing. But that's another topic.
Mainly automatically translated
--------------------------------------------
Windows 10, 64 Bit
Intel i5-4440 (3,1 GHz) ; Intel HD Graphics 4600
Last Edit: 8 months, 1 week ago by schrauber.

Re: Improved Background Export [feature] 6 months, 1 week ago #194424

  • hugly
  • OFFLINE
  • Platinum Boarder
  • Posts: 20563
  • 6 months, 1 week ago
schrauber wrote:
I think proxy creation could give even greater benefit by optimizing load balancing.

I just created a h.264-480-medium proxy from 2160p60 source with a duration of 05:37 minutes. It took 25 minutes to create on the 1920x, the overall average CPU load was below 15 %.

Is that normal?

This image is hidden for guests. Please log in or register to see it.
It's better to travel well than to arrive...

Re: Improved Background Export [feature] 6 months, 1 week ago #194433

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 3374
  • 6 months, 1 week ago
I replied to the proxy topic in a new thread:
Performance during proxy creation with Lightworks
Mainly automatically translated
--------------------------------------------
Windows 10, 64 Bit
Intel i5-4440 (3,1 GHz) ; Intel HD Graphics 4600
Last Edit: 6 months, 1 week ago by schrauber.

Re: Improved Background Export [feature] 4 months, 1 week ago #197507

  • hugly
  • OFFLINE
  • Platinum Boarder
  • Posts: 20563
  • 4 months, 1 week ago
One question to those who know the internal pipeline: Could it be that Lightworks uses GPU-based scaling even on export and even without any effects in place?


Edit: Maybe for proxy creation as well?
It's better to travel well than to arrive...
Last Edit: 4 months, 1 week ago by hugly.

Re: Improved Background Export [feature] 4 months, 1 week ago #197510

  • Great White
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 1542
  • 4 months, 1 week ago
hugly wrote:
One question to those who know the internal pipeline: Could it be that Lightworks uses GPU-based scaling even on export and even without any effects in place?

Edit: Maybe for proxy creation as well?

Scaling and colour-space conversion is always performed on the GPU.
Lightworks Development

Re: Improved Background Export [feature] 4 months, 1 week ago #197512

  • hugly
  • OFFLINE
  • Platinum Boarder
  • Posts: 20563
  • 4 months, 1 week ago
Thank you for clarifying.

I think, this explains some (most) of my findings.

Does this mean that, as soon as CPU and GPU speed exceed a certain limit, the transfer speed on the bus limits overall performance when creating proxies and exporting?
It's better to travel well than to arrive...
Last Edit: 4 months, 1 week ago by hugly.

Re: Improved Background Export [feature] 4 months, 1 week ago #197513

  • Great White
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 1542
  • 4 months, 1 week ago
hugly wrote:
Thank you for clarifying.

I think, this explains some (most) of my findings.

Does this mean that, as soon as CPU and GPU speed exceed a certain limit, the transfer speed on the bus limits overall performance when creating proxies and exporting?

I imagine so
Lightworks Development

Re: Improved Background Export [feature] 4 months, 1 week ago #197515

  • hugly
  • OFFLINE
  • Platinum Boarder
  • Posts: 20563
  • 4 months, 1 week ago
Thank you.

Based on the newly gained knowledge and on the fact that on my system GPU tests show GPU to host transfer half as high as in the opposite direction, I'll order a GTX 1080 (with 30 days return guarantee) to see and tell what it changes.

I suspect, with CPU based decoding/encoding, CPU based scaling when creating proxies could shorten conversion times significantly due to less overhead for the transfer, in particular on high performance CPUs?
It's better to travel well than to arrive...
Last Edit: 4 months, 1 week ago by hugly.

Re: Improved Background Export [feature] 4 months, 1 week ago #197517

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 3374
  • 4 months, 1 week ago
hugly wrote:
... I suspect, with CPU based decoding/encoding, CPU based scaling when creating proxies could shorten conversion times significantly due to less overhead for the transfer, in particular on high performance CPUs?

But maybe slow down systems with integrated GPU?

I also suspect that there is a difference between scaling up and scaling down. Upscaling is an easy task for a GPU. Downscaling can be a bit trickier if you want to avoid interferences. No idea how much a CPU would have to do with it?

Would perhaps the optimum, if possible, be to run two GPU´s in parallel?

Just brainstorming:

The possibly integrated GPU could be used for high bidirectional data transfer between CPU, GPU and RAM, provided that GPU and V-RAM requirements are low.

A separate high-performance graphics card would then be used for applications that cause a high GPU load or require a lot of V-RAM.

I don't know if this is possible.

However, my current PC only has the GPU integrated in the I5 anyway.
Mainly automatically translated
--------------------------------------------
Windows 10, 64 Bit
Intel i5-4440 (3,1 GHz) ; Intel HD Graphics 4600
Last Edit: 4 months, 1 week ago by schrauber.

Re: Improved Background Export [feature] 4 months, 1 week ago #197522

  • hugly
  • OFFLINE
  • Platinum Boarder
  • Posts: 20563
  • 4 months, 1 week ago
schrauber wrote:
But maybe slow down systems with integrated GPU?

I'm perfectly unsure if GPU scaling with two transfer operation from RAM to VRAM and back over the bus will beat CPU scaling. Unless you have a completely overpowerd system, like I have now, compared with a low powered system.

Edit: But yes you are right, on systems with integrated CPU and shared RAM it could be that the scaling with the CPU only could be slower, if first, the CPU has something meaningful to do ,different from waiting, while the GPU is scaling and second, GPU scaling is faster than CPU scaling, what has to be shown first. And, as far as I can remember the recommended specs list dedicated GPU (not integrated) for best performance. Anyway, that's all theory and pure guessing.. All that has to be tested with hands on the code to find out, users can't do it.
It's better to travel well than to arrive...
Last Edit: 4 months, 1 week ago by hugly.
  • Page:
  • 1
  • 2
Time to create page: 0.29 seconds
Scroll To Top