Processing chroma planes separately as luma is faster

[kgrabs]

Splitting up the planes and processing them all separately gives me a pretty big speedup.

import vsutil

clip = core.ffms2.Source()
clip = vsutil.depth(clip, 16)

a = core.placebo.Deband(clip, planes=1|2|4, threshold=4, radius=16, grain=0)
b = vsutil.join([core.placebo.Deband(x, planes=1, threshold=4, radius=16, grain=0) for x in vsutil.split(clip)])

core.std.Expr([a,b], 'x y = 0 65535 ?').set_output() # green
a.set_output() # Time elapsed: 0:43.090 - 69.62245859547165593995 FPS
b.set_output() # Time elapsed: 0:26.074 - 115.05868775474569076778 FPS

[luglio]

The pros and cons I can think about using 1|2|4 are less time spent on initializing stuffs, but some time wasted on waiting for the slowest processed plane (if in the plugin they were in parallel) for each frame.

I'm personally interested in the ratio of time between initialization and the actual processing, but it might not be easy to quantitatively estimate it in this example. The split-join approach does have some freedom in the order of creating debanded yuv planes provided the buffer size allows, but the planes are also regularly joined into frames (which should be instant), so we won't know how much it benefits from such freedom. In contrast, when I tried to bench the YUV444 clips using the split-join approach, since processing the planes takes nearly equal time, the GPU-memory bandwidth of my PC seemed to be fully used (so I failed to quantitatively estimate it again).

[Lypheo]

@kgrabs can you try this one and report the fps for both clips? http://maven.whatbox.ca:11665/f/libvs_placebo.dll

[kgrabs]

a.set_output() # Time elapsed: 0:40.132 - 74.75310283559599611181 FPS
b.set_output() # Time elapsed: 0:25.891 - 115.87157682773170108703 FPS

Same problem, but it seems to have improved a bit. After testing it 3 times for consistency I tested the current release immediately afterward and only barely got 71 fps each time

[Lypheo]

wait, I may just not be. e3481082d516d51885d581bae7905ddf03efd0bd diminishes the speed differences for me, but I can’t really tell because the differences were always pretty small to begin with on my shitty 2010 rig, so testing would be appreciated: http://maven.whatbox.ca:11665/f/libvs_placebo.dll

[quietvoid]

Is this still an issue with 1.4.1? placebo.Deband is already processing planes separately internally.

Also, 100 FPS seems pretty slow for debanding only.

[Setsugennoao]

Doesn't seem to be the case, still slower

from vsutil import split, join
import vapoursynth as vs

core = vs.core

clip = core.std.BlankClip(None, 1920, 1080, vs.YUV420P16, 30000)

a = core.placebo.Deband(clip, planes=1 | 2 | 4, threshold=4, radius=16, grain=0)
b = join([core.placebo.Deband(x, planes=1, threshold=4, radius=16, grain=0) for x in split(clip)])

a.set_output(0)
b.set_output(1)

> vspipe -o 0 placebo_test.py .
Output 30000 frames in 111.48 seconds (269.11 fps)
> vspipe -o 1 placebo_test.py .
Output 30000 frames in 80.70 seconds (371.73 fps)

[quietvoid]

Thanks. I'll attempt to figure out why.

[quietvoid]

I've reimplemented the idea from the refactor branch in master, and it's around 10% slower on average compared to processing planes separately. Will make a PR, but I'll try to improve it more.

At some point it's possible the speed is limited by the sequential access to the GPU, because of thread safety.

[mysteryx93]

I'm the author of AvisynthShader, and I had spent time investigating YUVA processing vs planar processing. Here's what I found out.

1. Shader performance was limited by the bandwidth from the GPU back to the CPU, since graphic cards are designed to push data to the GPU and not the other way around. Passing 3 planes instead of 4 saves on bandwidth.
2. Various GPUs support different video buffer formats, and single-plane buffer for planar doesn't work with all graphic cards.
3. Planar output did provide some performance grain... perhaps around 10%. Planar input did not give improvements.

I was only experimenting with planar input/output. I haven't tried internal planar processing.