Firstly, why doesn’t Proteus Natural use the GPU cores? Especially when you consider the new M5 has neural accelerators in each GPU core. However, let’s put that aside and give Topaz the benefit of doubt that they know best.
So why is it then, by using the CLI, I can get at least twice the speed? On my M3 Ultra, a 768x576 source gives around 7.4 FPS in the UI. But using my segment stacking command in the CLI, I get around 15 FPS.
But there’s more. Given the speed for a 4K source is around 1.3 FPS, the 768x576 source could achieve around 24 FPS if fully optimised.
Before Topaz comes back and say we can process up to 4 videos at once to increase the efficiency - YES, we know all that and I’ve already tried. It is reassuring that I can get the equivalent of around 16.2 FPS in total with 4 running at once. But that’s not the point. Why can’t we expect the maximum speed - or close to it - for a single video? If I can at least double the speed in a single command, is it too much to expect someone in your Dev Team to be able to do something similar? But please, don’t let me interrupt them from getting Starlight working properly.
And Topaz still think it’s a good idea to stop us from using the CLI?
Proteus natural is not using GPU cores on Mac due to a quality issue. We are working with Apple to address the problem. Once we have confirmation that it is fixed, we will enable the use of the GPU for Proteus Natural.
I will get the GUI team to look into the significant performance loss while using the GUI vs CLI. While there might be some performance loss, 50% is just ridiculous.
As far as single instance/process performance is concerned. There are inter frame dependencies, model input sizing, color correction, blending etc, while the bulk of the load is ANE/GPU bound. Many operations still need to happen on the CPU. In the 4K vs 768x576 example you cite it has more to do with block sizing. A 720p source vs 4K is a better example but I’m sure there might still be perf differences.
Starlight on Mac should be fixed in Mac OS 26.3, if you have access to the betas the latest one should already fix it.
Below is an example of the command I’ve created. In a nutshell here’s what it does in addition to a standard de-interlace and Proteus Natural upscale:
Prior to upscaling, create a (horizontal) stack of 5 streams. To picture the arrangement: A B C D E appears first followed by F G H I J etc. where each letter represents a 50-frame segment extracted sequentially from the original stream.
That stack stream is then upscaled, which is evidently much more efficient for the ANE having 5 x the original pixels (equal to 1920x1080 if the original was 720x576). That is the key to the speed increase.
The upscaled stack is then cropped and interleaved back to the original sequence ABCDEFGHIJ etc.
export TVAI_MODEL_DATA_DIR='/Applications/Topaz Video.app/Contents/Resources/models'
export TVAI_MODEL_DIR='/Applications/Topaz Video.app/Contents/Resources/models'
cd '/Applications/Topaz Video.app/Contents/MacOS'
The actual speed increase will depend on OS version, M chip type and original resolution. I got an 85% speed increase using the stacking method from a 720x576 PAL DVD source on my M3 Ultra running MacOS 26.3 Release Candidate.
