View Full Version : KNLMeansCL: OpenCL NLMeans de-noising algorithm [2018-01-29]
dipje
21st November 2016, 17:49
Not that much different to mine: https://snag.gy/9pi31Z.jpg
CruNcher
21st November 2016, 18:00
hmm except 1 extension less that seems not the be in your driver available
But yeah 1060 and 970 are very similar in Performance 1060 is more a improved version of it with less latency issues and some updated toolset gimicks and the fewer compute units are compensated mostly by the clock it seems most was pushed into improving the overall efficiency since 2014 :)
And the RX480 is what would have destroyed it in 2014 ;)
tormento
21st November 2016, 18:12
just replace cmode=true
In script cmode=chroma is present, not cmode=true
Groucho2004
21st November 2016, 18:14
Mine:
https://s6.postimg.org/v6k37mbup/Image1.png
tormento
21st November 2016, 18:17
Someone who has a nvidia gpu could post this screen? Thank you.
http://i.imgur.com/Bf1Tw9Rm.jpg (http://imgur.com/Bf1Tw9R)
dipje
22nd November 2016, 09:39
Hey you actually got a rise? You got the newest driver I see. Let me test with that as well.
Something else (and not relevant I guess, but still) why is your 'thread count' 24 and mine 17, while we both have 4 cores + HT ? Or is it a multisocket system or something?
edit:
oh wait, gtx660, that's old-skool Kepler instead of Maxwell-based. Might be a reason.
edit2:
I got no different results with the latest drivers. The same +/- 6.5% drop in speed.
I did notice that adding prefetch(2) at the end of the benchscript gave me an AVSMeter thread count of 33, more cpu usage but also a slight increase in speed.
(0.7.7 normal: 14.4 fps, 0.8.0-a3: 13.5 fps, 0.8.0-a3 with prefetch(2): 14.2 fps)
Ofcourse, 0.7.7 also gives me a slight speed boost (15.24 fps) with prefetch(2) so in the end 0.8.0 is still a bit slower :)
Groucho2004
22nd November 2016, 12:12
I ran this with newer drivers, now I get a slight increase in speed:
[OS/Hardware info]
Operating system: Windows XP (x86) Service Pack 3 (Build 2600)
CPU (brand string): Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz
CPU (code name): Sandy Bridge (Core i5)
CPU clock (measured): 3951 MHz
CPU cores / Logical cores: 4 / 4
Video card: NVIDIA GeForce GTX 750
GPU name: GM107
NVIDIA VPU version: VP6
Video memory size: 1024
OpenCL version: OpenCL 1.2 CUDA
Graphics driver version: 10.18.13.6881 (ForceWare 368.81) / XP
[Script]
colorbars(width = 1920, height = 1080, pixel_type = "yv12").killaudio().assumefps(25, 1)
KNLMeansCL(d = 2, a = 2)
0.7.7:
Frames processed: 338 (0 - 337)
FPS (min | max | average): 5.382 | 5.643 | 5.616
Memory usage (phys | virt): 66 | 90 MiB
Thread count: 16
CPU usage (average): 25%
GPU core clock | memory clock: 1215 | 1253
GPU usage (average): 99%
VPU usage (average): 0%
GPU memory usage: 123 MiB
0.8.0-a3:
Frames processed: 348 (0 - 347)
FPS (min | max | average): 5.593 | 38.12 | 5.788
Memory usage (phys | virt): 66 | 90 MiB
Thread count: 16
CPU usage (average): 25%
GPU core clock | memory clock: 1215 | 1253
GPU usage (average): 98%
VPU usage (average): 0%
GPU memory usage: 174 MiB
dipje
22nd November 2016, 12:36
368.x still isn't the latest right? Or is it for XP?
Anyway, you have a GM107 GTX750, the older one. So I guess the speed drop is in more recent maxwell 2.x / pascal cards... or just on my system :).
Like I said before, I'm not sweating too much about a 6% drop. If I would worry about stuff like that I'm in need of something else to do :).
I'm hoping Vapoursynth gets fixed though.
Groucho2004
22nd November 2016, 13:21
368.x still isn't the latest right? Or is it for XP?It's the latest available driver for XP.
Khanattila
24th November 2016, 13:28
In all your nvidia gpu the local mem size is 48 KB and work group size is 1024, good to know.
tormento
27th November 2016, 10:55
Tried to adapt SMDegrain script to alpha version but it is beyond my capabilities. :(
real.finder
27th November 2016, 15:10
Tried to adapt SMDegrain script to alpha version but it is beyond my capabilities. :(
just replace
cmode=chroma && fullchr
with
channels=chroma && fullchr ? "YUV" : "Y"
tormento
27th November 2016, 20:56
just replace
cmode=chroma && fullchr
with
channels=chroma && fullchr ? "YUV" : "Y"
Simple x264 Launcher (Build #1060), built 2016-10-21
Job started at 2016-11-27, 20:56:21.
Source file : E:\in\2_03 Jason Bourne\jason_44.avs
Output file : E:\in\2_03 Jason Bourne\jason_44.mkv
--- SYSTEMINFO ---
Binary Path : D:\eseguibili\media\x264 launcher
Avisynth : Yes
VapourSynth : No
--- SETTINGS ---
Encoder : x264 (AVC/H.264), 64-Bit (x64), 8-Bit
Source : Avisynth (avs)
RC Mode : CRF
Preset : slow
Tuning : <None>
Profile : High
Custom : --level 4.1 --keyint 240 --vbv-bufsize 78125 --vbv-maxrate 62500 --aq-mode 2 --sar 1:1
--- CHECK VERSION ---
Detect video encoder version:
Creating process:
"D:\eseguibili\media\x264 launcher\toolset\x64\x264_8bit_x64.exe" --version
x264 0.148.2721kMod 72d53ab
(libswscale 4.1.100)
(libavformat 57.50.100)
(ffmpegsource 2.22.1.0)
built by Komisar on Sep 23 2016, gcc: 4.9.2 (multilib.generic.Komisar)
x264 configuration: --bit-depth=8 --chroma-format=all
libx264 configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later
Detect video source version:
Creating process:
"D:\eseguibili\media\x264 launcher\toolset\x64\avs2yuv_x64.exe"
Avs2YUV 0.24bm3
> x264 revision: 2721 (core #148) - with custom patches!
> Avs2YUV version: 0.24.3
--- GET SOURCE INFO ---
Creating process:
"D:\eseguibili\media\x264 launcher\toolset\x64\avs2yuv_x64.exe" -frames 1 "E:\in\2_03 Jason Bourne\jason_44.avs" NUL
error: Script error: expected a , or )
((null), line 21, column 190)
(D:/Programmi/media/AviSynth+/plugins64/SMDegrain-2016_1114�realfinder.avsi, line 743)
(D:/Programmi/media/AviSynth+/plugins64/SMDegrain-2016_1114�realfinder.avsi, line 172)
(E:\in\2_03 Jason Bourne\jason_44.avs, line 19)
PROCESS EXITED WITH ERROR CODE: 1
real.finder
27th November 2016, 22:54
why don't just use avspmod?
anyway
nlc = Eval("nlc.KNLMeansCL(D=d, A=a, h=h,lsb_inout=lsb_in || lsb,device_type=devicetype,device_id=deviceid,cmode=chroma && fullchr" + knlm_params + ")")
cnl = chroma && fullchr ? "YUV" : "Y"
nlc = Eval("nlc.KNLMeansCL(D=d, A=a, h=h,lsb_inout=lsb_in || lsb,device_type=devicetype,device_id=deviceid,channels=cnl" + knlm_params + ")")
I don't have gpu for test
tormento
28th November 2016, 08:44
Ok, tested encoding two movies from BD to SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,truemotion=true,plane=4,chroma=true,lsb=true,mode=6,TV_range=false)
Tested with Prefetch(8).
No noticeable difference in speed or visual quality. Will test better next hours.
Khanattila
5th December 2016, 15:26
https://github.com/Khanattila/KNLMeansCL/releases/tag/v1.0.0-beta.1
KNLMeansCL v1.0.0-beta.1
* Improved performance with CPU.
* Improved performance with AMD GCN Architecture.
* Reduced CPU overload in some system.
* Improved de-noising quality around image edge.
* Replaced 'cmode' with 'channels' and added the options to only process the chroma.
* Two new modified bisquare weighting functions.
* Increased the maximum 's' value to 8.
* Removed Cauchy weighting function.
* Updated to VapourSynth R35.
* Fixed second clip 'rclip' in some circumstances.
tormento
5th December 2016, 15:55
https://github.com/Khanattila/KNLMeansCL/releases/tag/v1.0.0-beta.1
Please release x64 version too.
Khanattila
5th December 2016, 16:13
Please release x64 version too.
Thanks for your report, fixed.
real.finder
5th December 2016, 17:01
https://github.com/Khanattila/KNLMeansCL/releases/tag/v1.0.0-beta.1
KNLMeansCL v1.0.0-beta.1
* Improved performance with CPU.
* Improved performance with AMD GCN Architecture.
* Reduced CPU overload in some system.
* Improved de-noising quality around image edge.
* Replaced 'cmode' with 'channels' and added the options to only process the chroma.
* Two new modified bisquare weighting functions.
* Increased the maximum 's' value to 8.
* Removed Cauchy weighting function.
* Updated to VapourSynth R35.
* Fixed second clip 'rclip' in some circumstances.
I can't use this filter, but I did some edit in SMDegrain so with channels there is no need to Stack chroma Horizontal trick in SMDegrain prefilter?
Khanattila
5th December 2016, 18:13
I can't use this filter, but I did some edit in SMDegrain so with channels there is no need to Stack chroma Horizontal trick in SMDegrain prefilter?
If I remember correctly this trick is used only if video is not planar.
However, what problems do you have?
real.finder
5th December 2016, 19:38
If I remember correctly this trick is used only if video is not planar.
However, what problems do you have?
the trick for yv12 too, to process chroma because back then it's just copy, irc
I don't have good opencl device, and trid OpenCL™ Runtime with device_type="cpu" and then I get a crash!
Groucho2004
5th December 2016, 21:51
https://github.com/Khanattila/KNLMeansCL/releases/tag/v1.0.0-beta.1
0.7.7 and 1.0.0b1 comparison:
[OS/Hardware info]
Operating system: Windows XP (x86) Service Pack 3 (Build 2600)
CPU (brand string): Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz
CPU (code name): Sandy Bridge (Core i5)
CPU clock (measured): 3952 MHz
CPU cores / Logical cores: 4 / 4
Video card: NVIDIA GeForce GTX 750
GPU name: GM107
NVIDIA VPU version: VP6
Video memory size: 1024
OpenCL version: OpenCL 1.2 CUDA
Graphics driver version: 10.18.13.6881 (ForceWare 368.81) / XP
[Script]
colorbars(width = 1920, height = 1080, pixel_type = "yv12").killaudio().assumefps(25, 1)
KNLMeansCL(d = 2, a = 2)
0.7.7:
[Runtime info]
Frames processed: 338 (0 - 337)
FPS (min | max | average): 5.349 | 5.644 | 5.616
Memory usage (phys | virt): 57 | 78 MiB
Thread count: 9
CPU usage (average): 25%
GPU core clock | memory clock: 1215 | 1253
GPU usage (average): 98%
VPU usage (average): 0%
GPU memory usage: 121 MiB
1.0.0b1:
[Runtime info]
Frames processed: 309 (0 - 308)
FPS (min | max | average): 4.928 | 36.20 | 5.143
Memory usage (phys | virt): 64 | 78 MiB
Thread count: 9
CPU usage (average): 25%
GPU core clock | memory clock: 1215 | 1253
GPU usage (average): 98%
VPU usage (average): 0%
GPU memory usage: 163 MiB
tormento
6th December 2016, 05:33
Has video memory usage changed?
Pee Wee's big adventure.264 (http://www40.zippyshare.com/v/hpuIEgAG/file.html) (Pee Wee's big adventure.dgi (http://www77.zippyshare.com/v/xrWrucVu/file.html)) and the script
SetMemoryMax(8000)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("ChangeFPS", 3)
SetFilterMTMode("DGSource", 3)
LoadPlugin("D:\eseguibili\media\DGDecNV\x64\DGDecodeNV.dll")
DGSource("F:\raw\Pee Wee's big adventure.dgi")
ChangeFPS(last,last,true)
SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,truemotion=true,plane=4,chroma=true,lsb=true,mode=6,TV_range=false)
Prefetch(8)
crashes with latest beta of KNLMeansCL, while works with 0.7.7.
To make it work with latest beta, I have to use Prefetch(7).
Khanattila
6th December 2016, 09:49
0.7.7 and 1.0.0b1 comparison:
[OS/Hardware info]
Operating system: Windows XP (x86) Service Pack 3 (Build 2600)
CPU (brand string): Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz
CPU (code name): Sandy Bridge (Core i5)
CPU clock (measured): 3952 MHz
CPU cores / Logical cores: 4 / 4
Video card: NVIDIA GeForce GTX 750
GPU name: GM107
NVIDIA VPU version: VP6
Video memory size: 1024
OpenCL version: OpenCL 1.2 CUDA
Graphics driver version: 10.18.13.6881 (ForceWare 368.81) / XP
[Script]
colorbars(width = 1920, height = 1080, pixel_type = "yv12").killaudio().assumefps(25, 1)
KNLMeansCL(d = 2, a = 2)
0.7.7:
[Runtime info]
Frames processed: 338 (0 - 337)
FPS (min | max | average): 5.349 | 5.644 | 5.616
Memory usage (phys | virt): 57 | 78 MiB
Thread count: 9
CPU usage (average): 25%
GPU core clock | memory clock: 1215 | 1253
GPU usage (average): 98%
VPU usage (average): 0%
GPU memory usage: 121 MiB
1.0.0b1:
[Runtime info]
Frames processed: 309 (0 - 308)
FPS (min | max | average): 4.928 | 36.20 | 5.143
Memory usage (phys | virt): 64 | 78 MiB
Thread count: 9
CPU usage (average): 25%
GPU core clock | memory clock: 1215 | 1253
GPU usage (average): 98%
VPU usage (average): 0%
GPU memory usage: 163 MiB
At this point it seems clear that I have to add some fine tuning options.
dipje
6th December 2016, 11:03
The regular bench-script, ran for a minute or so on my Core i7-2670QM with HD6990M
colorbars(width = 1920, height = 1080, pixel_type = "yv12").killaudio().assumefps(25, 1)
KNLMeansCL(d = 2, a = 2)
v0.7.6: 4.282 fps, cpu usage 6%
v0.7.7: 3.984, cpu usage 6%
v1.0.0: 5.034 fps, cpu usage 4%
CPU frequency was scaling between +/- 1.3ghz and at max 1.6 - 1.7 ghz. Mostly sitting in between. In heavy multi-core load this CPU clocks at 2.2 while in heavy single-core load this CPU clocks easily to around 2.8ghz, so this means that KNLMeansCL isn't saturating my cpu power at all. Nice.
edit: Even tested v1.0.0 with device_type = 'cpu'. My CPU usage went to 100% (of course) and my clocks stay at 2.69ghz. I'm getting like 2 to 3 frames _per minute_ in speed though :P.
Vapoursynth x64 works again! v1.0.0 showed the same speed for the sort of same bench script. So it's working fine :).
What's even weirder: I said before that nothing ever shows any kind of GPU usage on this laptop? The sensors in AMD Overdrive and gpu-z are always 0%?
v0.7.6 and v0.7.7 keep the GPU usage at 0% for the entire minute, but 1.0.0 beta suddenly jumps from 0% to 95% GPU usage after 10 seconds into the benchmark.
Running games, SVP, Madvr, OpenCL demos.. nothing ever showed anything but 0% GPU usage but your 1.0.0 suddenly shows full GPU usage. Very weird :).
Anyway, can test the real question (for me at least), my i7 / GTX 1060 tonight back at home.
Khanattila
6th December 2016, 22:59
KNLMeansCL-benchmark-only.zip (http://www.mediafire.com/file/j378p8yj2eajznk/KNLMeansCL-benchmark-only.zip)
If you like to have fun, 3 more args: ocl_x, ocl_y and ocl_r.
Rules:
- (ocl_x * ocl_y) <= Device work group size
- min(ocl_x, ocl_y) >= 4.
- ocl_z >= 1.
In the next post some results.
Khanattila
7th December 2016, 13:48
Optimize for AMD was pretty simple. Max work group size is 256.
// ocl_x * ocl_y = 256
ocl_x = 64, ocl_y = 4, ocl_r = 1, 40.50 FPS
ocl_x = 32, ocl_y = 8, ocl_r = 1, 46.53 FPS <----
ocl_x = 16, ocl_y = 16, ocl_r = 1, 45.95 FPS
ocl_x = 8, ocl_y = 32, ocl_r = 1, // redundant
ocl_x = 4, ocl_y = 64, ocl_r = 1, // redundant
// Increment ocl_r
ocl_x = 32, ocl_y = 8, ocl_r = 1, 46.53 FPS
ocl_x = 32, ocl_y = 8, ocl_r = 2, 45.65 FPS
ocl_x = 32, ocl_y = 8, ocl_r = 3, 45.40 FPS
ocl_x = 32, ocl_y = 8, ocl_r = 4, 44.94 FPS
Also for Intel GPU. Max work group size is 512. (d=1, a=1)
// ocl_x * ocl_y = 512
ocl_x = 128, ocl_y = 4, ocl_r = 1, 6.01 FPS
ocl_x = 64, ocl_y = 8, ocl_r = 1, 6.11 FPS
ocl_x = 32, ocl_y = 16, ocl_r = 1, 5.63 FPS
// ocl_x * ocl_y = 512
ocl_x = 128, ocl_y = 4, ocl_r = 2, 6.50 FPS
ocl_x = 64, ocl_y = 8, ocl_r = 2, 6.61 FPS
ocl_x = 32, ocl_y = 16, ocl_r = 2, 6.86 FPS
// ocl_x * ocl_y = 512
ocl_x = 128, ocl_y = 4, ocl_r = 3, 7.85 FPS
ocl_x = 64, ocl_y = 8, ocl_r = 3, 7.94 FPS <----
ocl_x = 32, ocl_y = 16, ocl_r = 3, 7.29 FPS
// ocl_x * ocl_y = 512
ocl_x = 128, ocl_y = 4, ocl_r = 4, 7.98 FPS
ocl_x = 64, ocl_y = 8, ocl_r = 4, 7.52 FPS
ocl_x = 32, ocl_y = 16, ocl_r = 4, 7.58 FPS
// ocl_x * ocl_y = 512
ocl_x = 128, ocl_y = 4, ocl_r = 5, 7.95 FPS
ocl_x = 64, ocl_y = 8, ocl_r = 5, 8.01 FPS
ocl_x = 32, ocl_y = 16, ocl_r = 5, 7.45 FPS
Atak_Snajpera
7th December 2016, 14:11
Khanattila but this is faster for INTEL ocl_x = 64, ocl_y = 8, ocl_r = 5, 8.01 FPS instead of this ocl_x = 64, ocl_y = 8, ocl_r = 3, 7.94 FPS <----
PS. What does ocl_r mean exactly?
ShogoXT
7th December 2016, 14:31
New version of amd performance drivers coming in a day or so with new features including hevc encoding support on amd amf 1.4 . Since I have the rx 480 which versions do you want me to try to test and compare?
Also should I be using avisynth+ or Mt instead?
Khanattila
7th December 2016, 14:48
Khanattila but this is faster for INTEL ocl_x = 64, ocl_y = 8, ocl_r = 5, 8.01 FPS instead of this ocl_x = 64, ocl_y = 8, ocl_r = 3, 7.94 FPS <----
PS. What does ocl_r mean exactly?
Yes, but it's more or less the same thing.
olc_r is result for work-item. So if ocl_r = 1, each work-item calculates a pixel.
However, all work-item perform (2 + olc_r) memory accesses:
ocl_r = 1 ---> 3 memory access for 1 pixel
ocl_r = 2 ---> 4 memory access for 2 pixel
ocl_r = 3 ---> 5 memory access for 3 pixel
ocl_r = 4 ---> 6 memory access for 4 pixel
ocl_r = 5 ---> 7 memory access for 5 pixel
It is a way to make better use of the bandwidth.
However if ocl_r is too large it requires more registers, for example, of those available.
Khanattila
7th December 2016, 14:51
New version of amd performance drivers coming in a day or so with new features including hevc encoding support on amd amf 1.4 . Since I have the rx 480 which versions do you want me to try to test and compare?
Also should I be using avisynth+ or Mt instead?
v1.0.0-beta.1 is stable enough if you want to try it.
If you have problems back to v0.7.7.
Using AviSynth MT is useless. Instead AviSynth+ is supported but not required.
Atak_Snajpera
7th December 2016, 15:08
I wonder why ocl_y = 8 appears to be a "magic numer" ? (at least for AMD/INTEL)
Khanattila
7th December 2016, 16:48
I wonder why ocl_y = 8 appears to be a "magic numer" ? (at least for AMD/INTEL)
Global memory access by threads can be coalesced to one transaction.
Should be the alignment of the memory.
Khanattila
7th December 2016, 17:50
Intel i5-4690
// (ocl_x * ocl_y) = 2048
ocl_x = 512, ocl_y = 4, ocl_r = 1, 1.798 FPS
ocl_x = 256, ocl_y = 8, ocl_r = 1, 1.761 FPS
ocl_x = 128, ocl_y = 16, ocl_r = 1, 1.805 FPS
ocl_x = 64, ocl_y = 32, ocl_r = 1, 1.738 FPS
// (ocl_x * ocl_y) = 1024
ocl_x = 256, ocl_y = 4, ocl_r = 2, 2.358 FPS
ocl_x = 128, ocl_y = 8, ocl_r = 2, 2.290 FPS
ocl_x = 64, ocl_y = 16, ocl_r = 2, 2.259 FPS
ocl_x = 32, ocl_y = 32, ocl_r = 2, 2.225 FPS
// (ocl_x * ocl_y) = 1024
ocl_x = 256, ocl_y = 4, ocl_r = 3, 2.555 FPS
ocl_x = 128, ocl_y = 8, ocl_r = 3, 2.672 FPS
ocl_x = 64, ocl_y = 16, ocl_r = 3, 2.573 FPS
ocl_x = 32, ocl_y = 32, ocl_r = 3, 2.485 FPS
// (ocl_x * ocl_y) = 1024
ocl_x = 256, ocl_y = 4, ocl_r = 4 2.796 FPS
ocl_x = 128, ocl_y = 8, ocl_r = 4, 2.792 FPS
ocl_x = 64, ocl_y = 16, ocl_r = 4, 2.705 FPS
ocl_x = 32, ocl_y = 32, ocl_r = 4, 2.641 FPS
dipje
7th December 2016, 22:19
My speed seems to be fastest with ocl_y = 8 as well.
But maxing my workgroup size means ocl_x = 128, ocl_y = 8 (which is the fastest of all the combinations with ocl_x * ocl_y = 1024)
But any combination with ocl_y = 8 is faster except ocl_x = 4. So my fastest ended up being ocl_x = 16, ocl_y = 8.
Then, increasing ocl_r skyrockets performance some more. It tops out eventually.. but.. completely different to the combinations posted before.
Will post all my benches in some mintues.
----------------------------------
Core i7 860 @ 3.36 ghz, GTX 1060 6GB
First off, 0.7.6 / 0.7.7 / 1.0b1. Avisynth x64, d = 2, a = 2:
0.7.6 = 14.52
0.7.7 = 14.45
1.0b1 = 12.95
Sort of the same speed decrease as the 0.8 test/alpha thing
----------------------------------
The 'benchmark only' thing, 32bit (took me a while to figure out the DLL wasn't x64 :P), d = 1, a = 1
Nvidia max work size = 1024, So I started with this:
ocl_x = 256 ocl_y = 4 ocl_r = 1 123.6
ocl_x = 128 ocl_y = 8 ocl_r = 1 126.2
ocl_x = 64 ocl_y = 16 ocl_r = 1 119.4
ocl_x = 32 ocl_y = 32 ocl_r = 1 121.1
ocl_x = 16 ocl_y = 64 ocl_r = 1 106.7
ocl_x = 8 ocl_y = 128 ocl_r = 1 102.7
ocl_x = 4 ocl_y = 256 ocl_r = 1 97.25
ocl_y = 8 is supreme again apparently.
Then, just for curiousity I tried the other ocl_x parameters but kept ocl_y at 8:
ocl_x = 4 ocl_y = 8 ocl_r = 1 91.12
ocl_x = 8 ocl_y = 8 ocl_r = 1 140.5
ocl_x = 16 ocl_y = 8 ocl_r = 1 141.3
ocl_x = 32 ocl_y = 8 ocl_r = 1 134.3
ocl_x = 64 ocl_y = 8 ocl_r = 1 134.5
ocl_x = 128 ocl_y = 8 ocl_r = 1 126.2
Most of them are much faster! So I started testing ocl_r with the x = 16, y = 8 combination:
ocl_x = 16 ocl_y = 8 ocl_r = 1 141.5
ocl_x = 16 ocl_y = 8 ocl_r = 2 162.5
ocl_x = 16 ocl_y = 8 ocl_r = 3 169.7
ocl_x = 16 ocl_y = 8 ocl_r = 4 171.4
ocl_x = 16 ocl_y = 8 ocl_r = 5 173.5
ocl_x = 16 ocl_y = 8 ocl_r = 6 172.7
ocl_x = 16 ocl_y = 8 ocl_r = 7 173.4
ocl_x = 16 ocl_y = 8 ocl_r = 8 172.1
ocl_x = 16 ocl_y = 8 ocl_r = 9 172.7
ocl_x = 16 ocl_y = 8 ocl_r = 10 170.9
Huge speed increase with the first few ocl_r increases, from around ocl_r = 5 and up it seems to be 'generally the same' and probably in the margin of benchmark-error / variation.
I wanted to see the effect of ocl_r when using all the complete work-size my OpenCL info reports. So testing some more with ocl_x = 128, ocl_y = 8:
ocl_x = 128 ocl_y = 8 ocl_r = 1 126.2
ocl_x = 128 ocl_y = 8 ocl_r = 2 151.2
ocl_x = 128 ocl_y = 8 ocl_r = 3 160.9
ocl_x = 128 ocl_y = 8 ocl_r = 4 165.5
ocl_x = 128 ocl_y = 8 ocl_r = 5 168.4
ocl_x = 128 ocl_y = 8 ocl_r = 6 167.2
ocl_x = 128 ocl_y = 8 ocl_r = 7 167.6
ocl_x = 128 ocl_y = 8 ocl_r = 8 168.8
ocl_x = 128 ocl_y = 8 ocl_r = 9 168.6
ocl_r = 10 gave an error. Probably asking too much or out of memory or something.
I see the same speed increase in the first few ocl_r increases, and again from ocl_r = 5 it seems to reach a good 'max' leaving the rest in 'pretty much the same'-ballpark.
The speed comes very close to ocl_x = 16, ocl_y = 8, ocl_r = 5, but never quite matches it.
Are you looking to find an x/y/r combination sweet spot for all cards, or looking to pick different parameters on different generations + brands of cards? of max memory, or whatever?
For what's it worth, not specifying the parameters gives me 166.2 fps
dipje
7th December 2016, 23:08
Btw, Khanattila, if you say 'Intel i5-4690', do you mean with the gpu on that i5? because If I try to do CPU only (device_type = "CPU") with the benchmark-only version it says "no compatible opencl platforms available"
Atak_Snajpera
7th December 2016, 23:53
install intel opencl runtime and drivers
ShogoXT
8th December 2016, 00:54
He might have the IGPU disabled in his BIOS. Usually its default disabled on custom mobos. You have to go through hoops to enable it along side a normal GPU on Windows 7, but you can have them both enabled fine on Windows 10.
Can use quicksync that way.
dipje
8th December 2016, 08:49
I don't have a iGPU. But cpu type is working with the previous versions. Maybe a x86 / x64 thing.
Anyway , I was asking if he said ' core i5' if that was the CPU or iGPU.
Khanattila
8th December 2016, 12:03
I don't have a iGPU. But cpu type is working with the previous versions. Maybe a x86 / x64 thing.
Anyway , I was asking if he said ' core i5' if that was the CPU or iGPU.
CPU, otherwise I would write HD Graphics 4600 or Haswell(GT2).
Khanattila
8th December 2016, 12:21
@ dipje
Thanks for the informations, they explain why the new version is slower.
ocl_x, ocl_y and olc_r will be set internally by the program. I can read some information from the device such as local memory (L2 cache) and local work size.
dipje
8th December 2016, 20:52
CPU, otherwise I would write HD Graphics 4600 or Haswell(GT2).
So any reason why the 'benchmark only' build will not run CPU mode on my i7-860 but previous versions worked fine?
Or am I confused between my i7-860 and my ui7-2670qm and is it another case of AVX support or something like that.
ShogoXT
9th December 2016, 10:03
Trying to use 1.0.0b1 in regular use in staxrip to see if it can help with some rainbow and dot crawl issues.
How do you use the new channels setting? Wiki only mentions cmode.
Khanattila
9th December 2016, 16:56
Trying to use 1.0.0b1 in regular use in staxrip to see if it can help with some rainbow and dot crawl issues.
How do you use the new channels setting? Wiki only mentions cmode.
channels = {"YUV", "Y", "UV", "RGB", "auto"}.
"auto" is "Y" for YUV colour space and "RGB" for RGB color space.
ShogoXT
10th December 2016, 07:29
Fiddling around with it in Staxrip I found a few things.
With default settings and with d=0 (Temp on or off made no difference), there was significant blurring compared to the older 7.7 version.
See here:
http://screenshotcomparison.com/comparison/193278/picture:0
Its two sets, first is with 1.0b1 vs 7.7, and second with 1.0b1 vs OFF.
Keep in mind this is after it was upsampled and sharpened (awarpsharp2 and LSFMod) a good bit, so the blurring is actually a bit worse before probably (I cant take a pic without LSFMod because id have to redo how havfunc is loaded to make NNedi3 work)
Also with channels = "YUV", although Staxrip doesnt complain, it makes the preview window only show this:
http://imgur.com/mmjCT8e
EDIT: Tried setting all the basic values to 1, but no effect on reducing blur (a,s, and h. Did d as well to play with it)
tormento
12th December 2016, 11:34
I have tested SMDegrain with newer KNLMeansCL on lot of movies during these days.
The final result is an average 3-7% less noise reduction, measured very roughly on bitrate output and visual comparison frame by frame.
Any idea of why? What has changed in newer version that could have so much impact?
Plus: with stable version I can use 8 threads, with beta only 7.
WolframRhodium
12th December 2016, 15:42
I have tested SMDegrain with newer KNLMeansCL on lot of movies during these days.
The final result is an average 3-7% less noise reduction, measured very roughly on bitrate output and visual comparison frame by frame.
Any idea of why? What has changed in newer version that could have so much impact?
Plus: with stable version I can use 8 threads, with beta only 7.
Maybe because "wmode" has changed? For v1.0.0-beta.1, you should set it to 0 (Welsch weighting function), which is used in v0.7.7 by default.
tormento
12th December 2016, 16:20
Maybe because "wmode" has changed? For v1.0.0-beta.1, you should set it to 0 (Welsch weighting function), which is used in v0.7.7 by default.
Uh... is there any doc for newer version? I found nothing in the release zip file, only a changelog on github.
Khanattila
12th December 2016, 17:37
Uh... is there any doc for newer version? I found nothing in the release zip file, only a changelog on github.
v1.0.0-beta.2 will be well documented.
WolframRhodium
12th December 2016, 17:39
Uh... is there any doc for newer version? I found nothing in the release zip file, only a changelog on github.
I'm also looking for official document for new version...
Update: oh the next version will be documented, that's great!
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.