Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make use of hardware acceleration on machines with GPUs #579

Open
thekalinga opened this issue Jul 11, 2018 · 6 comments
Open

Make use of hardware acceleration on machines with GPUs #579

thekalinga opened this issue Jul 11, 2018 · 6 comments

Comments

@thekalinga
Copy link

thekalinga commented Jul 11, 2018

Synfig version & platform:
1.3.9, Ubuntu 14.04

Issue description:

Currently when I try to render using synfig, the ffmpeg runs without any hardware acceleration flag

ffmpeg -f image2pipe -vcodec ppm -r 24.000000 -i pipe: -an -metadata title="Final Aggregate" -vcodec libx264 -b:v 2000k -tune fastdecode -pix_fmt yuv420p -qp 0 -y /home/user/Desktop/Presentation/thread-per-connection/end-to-end-flow-test.mkv

I'm not that well versed in ffmpeg/GPUs, but from ffmpeg documentation its quite clear that passing -hwaccel auto will allow ffmpeg to automatically determine whether or not to use hardware acceleration when it is available, else it will continue to use CPU for rendering. By default hardware acceleration is disabled, i.e -hwaccel none is assumed by ffmpeg

https://ffmpeg.org/ffmpeg.html

I'm not sure why auto is not the default while rendering

Please note that I'm complete noob when it comes to synfig, ffmpeg & GPUs, yet this seems quite obvious


Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@thekalinga
Copy link
Author

thekalinga commented Jul 11, 2018

This article which talked about using hardware acceleration to speed up rendering

http://ntown.at/de/knowledgebase/cuda-gpu-accelerated-h264-h265-hevc-video-encoding-with-ffmpeg/

@thekalinga
Copy link
Author

thekalinga commented Jul 12, 2018

Since we will not know in advance what type of device people would be using synfig in, its better to allow users to specify custom ffmpeg arguments (as an advanced option). This way synfig can just focus on the pushing images to ffmpeg & expect advanced users to worry about additional optimizations w.r.t ffmpeg

@ice0
Copy link
Collaborator

ice0 commented Jul 12, 2018

Hello, Ashok! Nice offer! I apologize for not being able to comment in a timely manner, as I'm currently engaged in Synfig current bugs.
We have already discussed with Konstantin (@morevnaproject ) improvements in the export window and have come to exactly the same conclusions.

Also I want to note that I read all the messages, but I do not answer them, since there is nothing to add. I'll answer when I start making changes and if there are questions.

Thanks again for the excellent comments.

@thekalinga
Copy link
Author

thekalinga commented Jul 12, 2018

@ice0 A new observation. I tried rendering just pngs using synfig instead of video via ffmpeg. Other than the obvious ffmpeg parameter hardcoding, there seems to something else fundamental that needs to be modified in synfig. Its to do with utilisation of system resources (CPU & RAM) in synfig

Even when trying to render the pngs, the CPU & RAM are never fully utilised & the rendering is very very slow & only a single core of the CPU is used. It is one thing not to be CPU hog, but its an another thing not to utilise the existing resources & render really slowly. It even discards the number of threads supplied in the terminal & goes about in its own way using just single core of a multicore CPU (intel cores even have hyperthreading enabled)

In my quad core machine, out of 4 cores (4*2 = 8 hyper threads) synfig uses just 1 for some unknown reason, even if specify -threads 8 at the terminal

When synfig UI is running, sure, provide an option to the user to specify how many CPUs should be utilised. But when running in silent mode, synfig should utilise every bit of resource & render as fast as it can. Currently it is not

This is the command I ran

eval /home/user/Downloads/SynfigStudio-1.3.9-testing-18.06.17-linux64-67e10.appimage -q \
--benchmarks \
--verbose 10 \
--input-file /home/user/Desktop/Presentation/thread-per-request/end-to-end-flow.sif \
--target png \
--threads 8 \
--start-time 1s \
--end-time 90s \
--fps 1 \
--output-file /home/user/Desktop/Presentation/thread-per-connection/files/end-to-end-flow.png

So the issues are at multiple levels

  1. At hard coding ffmpeg
  2. At inefficient utilisation of available resources

Please correct me incase if I missed something obvious

@jhojen26
Copy link

jhojen26 commented Jul 17, 2018

uses this to run parallel render process
synfig -b Name.sifz -w 1600 -h 900 -o Image.png --start-time 0f --end-time 2s12f & synfig -b Name.sifz -w 1600 -h 900 -o Image.png --start-time 2s13f --end-time 5s
sometimes the render at 1920 x 1080 causes strange noises 1600 x 900 it can be scaled 1.2 later in the video editor
if have alpha channel use this to join the images
ffmpeg -framerate 24000/1001 -start_number 0000 -i "Image.%4d.png" -vcodec qtrle -pix_fmt argb Image.mov
if don't have alpha channel use this
ffmpeg -framerate 24000/1001 -start_number 0000 -i "Image.%4d.png" -vcodec qtrle -pix_fmt rgb24 Image.mov
works better with kdenlive

@thekalinga
Copy link
Author

@jhojen26 Running multiple synfig processes such that each process occupies one core is a workaround. But the fundamental issue needs to be addressed inside synfig

Also, scaling up is a terrible idea as you would lose quality

Thanks anyways for your suggestion

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants