Processing chroma planes separately as luma is faster about vs-placebo HOT 9 OPEN

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

from vs-placebo.

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).

from vs-placebo.

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

from vs-placebo.

wait, I may just not be. e348108 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

from vs-placebo.

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.

from vs-placebo.

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)

from vs-placebo.

Thanks. I'll attempt to figure out why.

from vs-placebo.

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.

from vs-placebo.

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.

from vs-placebo.