EternalStudent wrote:Which app was that in? I haven't used the transcoding feature much myself.
https://www.svp-team.com/wiki/Manual:SVPcode
Would be my guess. That page mentions ffmpeg. I don't know what options are passed down to ffmpeg, but this might be an issue for them to fix. If I was you I'd try to see what options were set when you run things. And what settings ffmpeg offers.
I wonder if lowering the threads to 8 from 16 would get you a little gain too? Optimum thread counts always sounded like black magic to me. "Take your actual core count and add 1" was something I'd seen before for video transcoding.
The problem is in the "SVP 4 Pro" app for sure, the one you'd find by typing SVP in the start menu. The video transcode function found in the Transcoding tab at the top is what I was doing, using the CPU to generate the interpolated frames at the highest quality settings (so SVP Shader: Complicated, Half pixel motion vector precision, Grid: 6 px. Small 2, Grid step: By two with global refinement, Small radius, Strongest search, Small top coarse level), and using the GPU to decode the video file for processing (Rendering device NVIDIA 3080) and to encode the processed video to 264 (H.264 AVC) by NVENC as interpolated frames were calculated by the CPU.
In describing this possible issue, the CPU has always been the limiting factor within SVP for the transcode - my GPU can encode this at up to 160fps (I found this by lowering SVP Shader, Grid, Grid Step etc. settings until the GPU saturated)
What I did to improve performance by 15% was, like you said, lowered the thread count to 8 manually, but not just any 8 or the first 8, I chose specifically to use cores # 0, 2, 4, 6, 8, 10, 12, and 14 within Windows Task Manager. Doing so is like disabling simultaneous multithreading in the BIOS for the application. This resulted in the transcode going from about 78FPS up to 90FPS, and CPU power consumption doing almost the exact same thing.
I'm not near that system right now, but I remember after adding the cores above, I also added 1, then 1 and 3, then 1, 3, and 5, checking performance each time. I think after cutting back to the proper 8 and gradually re-enabling virtual cores one at a time until 3 or 4 were available, the performance increase was less than one percent
Considering this, I very strongly believe this is a SVP software bug. 15% is a LOT of performance left on the table.
There is always the possibility that my computer is having a complicated interaction with the software though, so as always, someone with an AMD system will have to replicate the issue, record the performance, modify applicable settings, see if/how they affect performance, then review applicable code pertaining to multi-threading. They could skip diagnostics, but without the dry runs, the fix might be partial or not work