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
Comments
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/ |
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 |
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. 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. |
@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 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
Please correct me incase if I missed something obvious |
uses this to run parallel render process |
@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 |
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 byffmpeg
https://ffmpeg.org/ffmpeg.html
I'm not sure why
auto
is not the default while renderingPlease 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.
The text was updated successfully, but these errors were encountered: