x264 OpenCL

[mogobime]

I did some CRF18-encodings now with the regular vanilla-build and the one with the OpenCL-patch (720p stuff).

Without OpenCL the patched build was marginal faster (0,6%), with OpenCL enabled the speed gain with the patched build was 3,1% compared to the regular build - less than i achieved with my ABR encodes.
I think it's because CRF18 resulted in a for 720p stuff high bitrate of 6500 kbit/s (in my ABR encodings lower bitrates always were faster).

vanilla build, CRF 18:
mencoder -lavdopts threads=6 -really-quiet -of rawvideo -o - -ovc raw -demuxer lavf -vfm ffmpeg -noskip -vf scale,format=i420 -forcedsubsonly -nosub -nosound -mc 0 "C:\SSDWOR~1\HBR_Test\8MIN_H~1.MKV" | x264 --crf 18 --profile high --level 4.2 --ref 3 --keyint 250 --min-keyint 0 --scenecut 40 --bframes 3 --b-bias 0 --b-pyramid normal --direct spatial --b-adapt 1 --lookahead-threads 2 --sync-lookahead 150 --cplxblur 20 --qcomp 0.6 --qblur 0.5 --mbtree --rc-lookahead 40 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --qpmin 0 --qpmax 69 --qpstep 4 --partitions i4x4,i8x8,p8x8,b8x8 --8x8dct --no-dct-decimate --me hex --merange 16 --mvrange -1 --subme 7 --cabac --trellis 1 --psy-rd 1:0 --weightp 2 --aq-mode 1 --aq-strength 1 --vbv-maxrate 62500 --vbv-bufsize 78125 --nr 0 --deadzone-inter 21 --deadzone-intra 11 --cqm flat --threads auto --sar 1:1 --deblock 0:0 --ssim --colormatrix bt709 --fps 25000/1000 --input-res 1280x720 --output "C:\Users\ANONYM~1\AppData\Local\Temp\02_07_35_3910_01.264" -


x264 (1 pass) encoding started...
Starting Main@02:30:51.577:
"C:\Program Files\Hybrid\x264.exe" --crf 18 --profile high --level 4.2 --ref 3 --keyint 250 --min-keyint 0 --scenecut 40 --bframes 3 --b-bias 0 --b-pyramid normal --direct spatial --b-adapt 1 --lookahead-threads 2 --sync-lookahead 150 --cplxblur 20 --qcomp 0.6 --qblur 0.5 --mbtree --rc-lookahead 40 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --qpmin 0 --qpmax 69 --qpstep 4 --partitions i4x4,i8x8,p8x8,b8x8 --8x8dct --no-dct-decimate --me hex --merange 16 --mvrange -1 --subme 7 --cabac --trellis 1 --psy-rd 1:0 --weightp 2 --aq-mode 1 --aq-strength 1 --vbv-maxrate 62500 --vbv-bufsize 78125 --nr 0 --deadzone-inter 21 --deadzone-intra 11 --cqm flat --threads auto --sar 1:1 --deblock 0:0 --ssim --colormatrix bt709 --fps 25000/1000 --input-res 1280x720 --output "C:\Users\ANONYM~1\AppData\Local\Temp\02_07_35_3910_01.264" -
raw [info]: 1280x720p 1:1 @ 25/1 fps (cfr)
x264 [warning]: --ssim used with psy on: results will be invalid!
x264 [warning]: --tune ssim should be used if attempting to benchmark ssim!
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast FastShuffle SSEMisalign LZCNT
x264 [info]: profile High, level 4.2
x264 [info]: frame I:177 Avg QP:15.60 size:135298
x264 [info]: frame P:6165 Avg QP:18.52 size: 44314
x264 [info]: frame B:5987 Avg QP:20.49 size: 17290
x264 [info]: consecutive B-frames: 24.6% 28.5% 10.4% 36.5%
x264 [info]: mb I I16..4: 5.7% 82.9% 11.3%
x264 [info]: mb P I16..4: 1.7% 12.8% 1.0% P16..4: 45.6% 23.2% 10.7% 0.0% 0.0% skip: 5.0%
x264 [info]: mb B I16..4: 0.1% 1.3% 0.1% B16..8: 56.5% 8.9% 2.0% direct: 4.8% skip:26.3% L0:44.1% L1:47.2% BI: 8.7%
x264 [info]: 8x8 transform intra:82.6% inter:61.4%
x264 [info]: coded y,uvDC,uvAC intra: 84.0% 88.8% 51.6% inter: 39.7% 52.3% 22.5%
x264 [info]: i16 v,h,dc,p: 41% 19% 14% 26%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 13% 31% 6% 8% 7% 8% 7% 9%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 14% 18% 19% 7% 10% 9% 9% 7% 7%
x264 [info]: i8c dc,h,v,p: 56% 20% 17% 6%
x264 [info]: Weighted P-Frames: Y:2.6% UV:1.0%
x264 [info]: ref P L0: 57.1% 12.5% 19.8% 10.5% 0.1%
x264 [info]: ref B L0: 81.5% 15.1% 3.5%
x264 [info]: ref B L1: 92.9% 7.1%
x264 [info]: SSIM Mean Y:0.9823529 (17.533db)
x264 [info]: kb/s:6499.54
encoded 12329 frames, 38.42 fps, 6499.54 kb/s
finished after 00:05:21.072
finished...

vanilla build with OpenCL-patch, CRF 18, OpenCL OFF:
mencoder -lavdopts threads=6 -really-quiet -of rawvideo -o - -ovc raw -demuxer lavf -vfm ffmpeg -noskip -vf scale,format=i420 -forcedsubsonly -nosub -nosound -mc 0 "C:\SSDWOR~1\HBR_Test\8MIN_H~1.MKV" | x264 --crf 18 --profile high --level 4.2 --ref 3 --keyint 250 --min-keyint 0 --scenecut 40 --bframes 3 --b-bias 0 --b-pyramid normal --direct spatial --b-adapt 1 --lookahead-threads 2 --sync-lookahead 150 --cplxblur 20 --qcomp 0.6 --qblur 0.5 --mbtree --rc-lookahead 40 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --qpmin 0 --qpmax 69 --qpstep 4 --partitions i4x4,i8x8,p8x8,b8x8 --8x8dct --no-dct-decimate --me hex --merange 16 --mvrange -1 --subme 7 --cabac --trellis 1 --psy-rd 1:0 --weightp 2 --aq-mode 1 --aq-strength 1 --vbv-maxrate 62500 --vbv-bufsize 78125 --nr 0 --deadzone-inter 21 --deadzone-intra 11 --cqm flat --threads auto --sar 1:1 --deblock 0:0 --ssim --colormatrix bt709 --fps 25000/1000 --input-res 1280x720 --output "C:\Users\ANONYM~1\AppData\Local\Temp\02_07_35_3910_01.264" -


x264 (1 pass) encoding started...
Starting Main@02:07:59.326:
"C:\Program Files\Hybrid\x264.exe" --crf 18 --profile high --level 4.2 --ref 3 --keyint 250 --min-keyint 0 --scenecut 40 --bframes 3 --b-bias 0 --b-pyramid normal --direct spatial --b-adapt 1 --lookahead-threads 2 --sync-lookahead 150 --cplxblur 20 --qcomp 0.6 --qblur 0.5 --mbtree --rc-lookahead 40 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --qpmin 0 --qpmax 69 --qpstep 4 --partitions i4x4,i8x8,p8x8,b8x8 --8x8dct --no-dct-decimate --me hex --merange 16 --mvrange -1 --subme 7 --cabac --trellis 1 --psy-rd 1:0 --weightp 2 --aq-mode 1 --aq-strength 1 --vbv-maxrate 62500 --vbv-bufsize 78125 --nr 0 --deadzone-inter 21 --deadzone-intra 11 --cqm flat --threads auto --sar 1:1 --deblock 0:0 --ssim --colormatrix bt709 --fps 25000/1000 --input-res 1280x720 --output "C:\Users\ANONYM~1\AppData\Local\Temp\02_07_35_3910_01.264" -
raw [info]: 1280x720p 1:1 @ 25/1 fps (cfr)
x264 [warning]: --ssim used with psy on: results will be invalid!
x264 [warning]: --tune ssim should be used if attempting to benchmark ssim!
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSEMisalign LZCNT
x264 [info]: profile High, level 4.2
x264 [info]: frame I:177 Avg QP:15.60 size:135298
x264 [info]: frame P:6165 Avg QP:18.52 size: 44315
x264 [info]: frame B:5987 Avg QP:20.49 size: 17291
x264 [info]: consecutive B-frames: 24.6% 28.5% 10.4% 36.5%
x264 [info]: mb I I16..4: 5.7% 83.0% 11.3%
x264 [info]: mb P I16..4: 1.7% 12.7% 1.0% P16..4: 45.6% 23.2% 10.7% 0.0% 0.0% skip: 5.0%
x264 [info]: mb B I16..4: 0.1% 1.3% 0.1% B16..8: 56.5% 8.9% 2.0% direct: 4.8% skip:26.2% L0:44.1% L1:47.2% BI: 8.7%
x264 [info]: 8x8 transform intra:82.6% inter:61.3%
x264 [info]: coded y,uvDC,uvAC intra: 84.0% 88.8% 51.6% inter: 39.7% 52.3% 22.5%
x264 [info]: i16 v,h,dc,p: 41% 19% 14% 26%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 13% 31% 6% 8% 7% 8% 7% 9%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 14% 18% 19% 7% 10% 9% 9% 7% 7%
x264 [info]: i8c dc,h,v,p: 56% 20% 17% 6%
x264 [info]: Weighted P-Frames: Y:2.6% UV:1.0%
x264 [info]: ref P L0: 57.1% 12.5% 19.8% 10.5% 0.1%
x264 [info]: ref B L0: 81.5% 15.1% 3.4%
x264 [info]: ref B L1: 92.9% 7.1%
x264 [info]: SSIM Mean Y:0.9823518 (17.533db)
x264 [info]: kb/s:6499.71
encoded 12329 frames, 38.66 fps, 6499.71 kb/s
finished after 00:05:19.059
finished...

vanilla build with OpenCL-patch, CRF 18, OpenCL ON:
mencoder -lavdopts threads=6 -really-quiet -of rawvideo -o - -ovc raw -demuxer lavf -vfm ffmpeg -noskip -vf scale,format=i420 -forcedsubsonly -nosub -nosound -mc 0 "C:\SSDWOR~1\HBR_Test\8MIN_H~1.MKV" | x264 --crf 18 --profile high --level 4.2 --ref 3 --keyint 250 --min-keyint 0 --scenecut 40 --bframes 3 --b-bias 0 --b-pyramid normal --direct spatial --b-adapt 1 --lookahead-threads 2 --sync-lookahead 150 --cplxblur 20 --qcomp 0.6 --qblur 0.5 --mbtree --rc-lookahead 40 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --qpmin 0 --qpmax 69 --qpstep 4 --partitions i4x4,i8x8,p8x8,b8x8 --8x8dct --no-dct-decimate --me hex --merange 16 --mvrange -1 --subme 7 --cabac --trellis 1 --psy-rd 1:0 --weightp 2 --aq-mode 1 --aq-strength 1 --vbv-maxrate 62500 --vbv-bufsize 78125 --nr 0 --deadzone-inter 21 --deadzone-intra 11 --cqm flat --threads auto --sar 1:1 --deblock 0:0 --ssim --colormatrix bt709 --fps 25000/1000 --input-res 1280x720 --opencl --opencl-clbin "C:\Users\ANONYM~1\AppData\Local\Temp\x264_lookahead_02_07_38_3510_01.clbin" --output "C:\Users\ANONYM~1\AppData\Local\Temp\02_07_38_3510_01.264" -


x264 (1 pass) encoding started...
Starting Main@02:13:21.598:
"C:\Program Files\Hybrid\x264.exe" --crf 18 --profile high --level 4.2 --ref 3 --keyint 250 --min-keyint 0 --scenecut 40 --bframes 3 --b-bias 0 --b-pyramid normal --direct spatial --b-adapt 1 --lookahead-threads 2 --sync-lookahead 150 --cplxblur 20 --qcomp 0.6 --qblur 0.5 --mbtree --rc-lookahead 40 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --qpmin 0 --qpmax 69 --qpstep 4 --partitions i4x4,i8x8,p8x8,b8x8 --8x8dct --no-dct-decimate --me hex --merange 16 --mvrange -1 --subme 7 --cabac --trellis 1 --psy-rd 1:0 --weightp 2 --aq-mode 1 --aq-strength 1 --vbv-maxrate 62500 --vbv-bufsize 78125 --nr 0 --deadzone-inter 21 --deadzone-intra 11 --cqm flat --threads auto --sar 1:1 --deblock 0:0 --ssim --colormatrix bt709 --fps 25000/1000 --input-res 1280x720 --opencl --opencl-clbin "C:\Users\ANONYM~1\AppData\Local\Temp\x264_lookahead_02_07_38_3510_01.clbin" --output "C:\Users\ANONYM~1\AppData\Local\Temp\02_07_38_3510_01.264" -
raw [info]: 1280x720p 1:1 @ 25/1 fps (cfr)
x264 [warning]: --ssim used with psy on: results will be invalid!
x264 [warning]: --tune ssim should be used if attempting to benchmark ssim!
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSEMisalign LZCNT
x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce GTX 660
x264 [info]: Compiling OpenCL kernels...
x264 [info]: profile High, level 4.2
x264 [info]: frame I:169 Avg QP:15.62 size:137770
x264 [info]: frame P:6170 Avg QP:18.51 size: 44398
x264 [info]: frame B:5990 Avg QP:20.50 size: 17258
x264 [info]: consecutive B-frames: 24.0% 29.6% 11.9% 34.5%
x264 [info]: mb I I16..4: 5.9% 82.7% 11.4%
x264 [info]: mb P I16..4: 1.7% 12.9% 1.1% P16..4: 45.7% 23.4% 10.6% 0.0% 0.0% skip: 4.6%
x264 [info]: mb B I16..4: 0.1% 1.4% 0.1% B16..8: 56.0% 9.1% 2.0% direct: 4.8% skip:26.4% L0:44.1% L1:47.1% BI: 8.8%
x264 [info]: 8x8 transform intra:82.7% inter:61.3%
x264 [info]: coded y,uvDC,uvAC intra: 84.1% 88.9% 51.5% inter: 39.9% 52.4% 22.5%
x264 [info]: i16 v,h,dc,p: 41% 19% 14% 26%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 13% 31% 6% 8% 7% 8% 7% 9%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 14% 18% 19% 7% 10% 9% 9% 7% 7%
x264 [info]: i8c dc,h,v,p: 56% 20% 17% 6%
x264 [info]: Weighted P-Frames: Y:2.5% UV:1.0%
x264 [info]: ref P L0: 56.8% 12.5% 20.0% 10.6% 0.1%
x264 [info]: ref B L0: 81.3% 15.3% 3.3%
x264 [info]: ref B L1: 92.8% 7.2%
x264 [info]: SSIM Mean Y:0.9821631 (17.487db)
x264 [info]: kb/s:6498.37
encoded 12329 frames, 39.61 fps, 6498.37 kb/s
finished after 00:05:11.466
finished...


I will repeat this now with CRF 22 and post it here.

EDIT:

Sorry, I was to tired to post here, had to get some sleep first ;)

CRF22 with identical settings didn't really change much, speed gain of regular vanilla build compared to OpenCL-patched vanilla build with OpenCL ON was 4,06%:


vanilla build, CRF 22:

x264 [info]: SSIM Mean Y:0.9709515 (15.369db)
x264 [info]: kb/s:3363.14
encoded 12329 frames, 47.05 fps, 3363.14 kb/s


vanilla build with OpenCL-patch, CRF 22, OpenCL OFF:

x264 [info]: SSIM Mean Y:0.9709510 (15.369db)
x264 [info]: kb/s:3363.02
encoded 12329 frames, 47.25 fps, 3363.02 kb/s


vanilla build with OpenCL-patch, CRF 22, OpenCL ON:

x264 [info]: SSIM Mean Y:0.9707238 (15.335db)
x264 [info]: kb/s:3357.07
encoded 12329 frames, 48.96 fps, 3357.07 kb/s


I'm not sure if it's the CRF mode itself which is slower then my ABR encodings (http://forum.selur.de/topic249-dgdecnv-gpu-decoding-x264-opencl-lookahead-benchmarks.html) done with the older TMod, which seems to act very similar to this build at my system (speed gain with ABR encodings @ 3000 kbit's was about 10-12%).
And I really have no idea why this new patched build is so slow at your system, because at mine with OpenCL disabled it seems to act like the regular build *confused*

Maybe you can try to encode with my CLI with mencoder piping to x264, to figure out if it's the settings or your system, that causes the problem?!?

[mogobime]

I tested the CRF-mode with different settings now (the test settings I used in my test-thread (http://forum.selur.de/topic249-dgdecnv-gpu-decoding-x264-opencl-lookahead-benchmarks.html) for ABR-encoding), and now the encoding was speeded up as I was used to:
Patched vanilla-build with opencl enabled was 13,66% faster then the unpatched build.
Without OpenCL the two builds were equal in speed:

x264 was called with mencoder as before, but the call is missing in the code:

vanilla, CRF 22:


x264.exe --crf 22 --profile high --level 4.2 --ref 6 --keyint 250 --min-keyint 0 --scenecut 40 --bframes 5 --b-bias 0 --b-pyramid normal --direct auto --b-adapt 2 --lookahead-threads 4 --sync-lookahead 150 --lookahead-threads 4 --cplxblur 20 --qcomp 0.6 --qblur 0.5 --mbtree --rc-lookahead 60 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --qpmin 0 --qpmax 69 --qpstep 4 --partitions i4x4,i8x8,p8x8,b8x8 --8x8dct --no-dct-decimate --me umh --merange 16 --mvrange -1 --subme 7 --cabac --trellis 1 --no-psy --weightp 2 --aq-mode 2 --aq-strength 1 --vbv-maxrate 62500 --vbv-bufsize 78125 --nr 0 --deadzone-inter 21 --deadzone-intra 11 --cqm flat --threads 16 --sar 1:1 --deblock -1:-1 --ssim --colormatrix bt709 --fps 25000/1000 --input-res 1280x720 --output "C:\Users\ANONYM~1\AppData\Local\Temp\12_28_44_8010_01.264" -
raw [info]: 1280x720p 1:1 @ 25/1 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSEMisalign LZCNT
x264 [info]: profile High, level 4.2
x264 [info]: frame I:133 Avg QP:19.05 size:118726
x264 [info]: frame P:2698 Avg QP:22.35 size: 26333
x264 [info]: frame B:9498 Avg QP:24.47 size: 7302
x264 [info]: consecutive B-frames: 2.4% 3.7% 6.9% 16.5% 16.4% 54.1%
x264 [info]: mb I I16..4: 15.9% 74.2% 9.9%
x264 [info]: mb P I16..4: 11.9% 17.5% 1.3% P16..4: 38.9% 13.0% 4.9% 0.0% 0.0% skip:12.5%
x264 [info]: mb B I16..4: 1.6% 1.8% 0.1% B16..8: 34.5% 4.0% 0.6% direct: 1.8% skip:55.5% L0:42.0% L1:49.3% BI: 8.7%
x264 [info]: 8x8 transform intra:57.1% inter:66.5%
x264 [info]: direct mvs spatial:99.9% temporal:0.1%
x264 [info]: coded y,uvDC,uvAC intra: 60.1% 64.4% 23.0% inter: 14.1% 18.2% 3.4%
x264 [info]: i16 v,h,dc,p: 26% 21% 30% 22%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 12% 17% 31% 5% 7% 7% 7% 6% 7%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 14% 19% 23% 6% 10% 8% 8% 6% 6%
x264 [info]: i8c dc,h,v,p: 53% 23% 19% 4%
x264 [info]: Weighted P-Frames: Y:2.4% UV:1.3%
x264 [info]: ref P L0: 54.9% 15.4% 14.7% 5.7% 5.7% 3.5% 0.2% 0.0%
x264 [info]: ref B L0: 80.0% 12.1% 5.5% 1.8% 0.7%
x264 [info]: ref B L1: 93.4% 6.6%
x264 [info]: SSIM Mean Y:0.9728666 (15.665db)
x264 [info]: kb/s:2533.80
encoded 12329 frames, 34.51 fps, 2533.80 kb/s


OpenCL-patched vanilla with OpenCL ON:


x264.exe --crf 22 --profile high --level 4.2 --ref 6 --keyint 250 --min-keyint 0 --scenecut 40 --bframes 5 --b-bias 0 --b-pyramid normal --direct auto --b-adapt 2 --lookahead-threads 4 --sync-lookahead 150 --lookahead-threads 4 --cplxblur 20 --qcomp 0.6 --qblur 0.5 --mbtree --rc-lookahead 60 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --qpmin 0 --qpmax 69 --qpstep 4 --partitions i4x4,i8x8,p8x8,b8x8 --8x8dct --no-dct-decimate --me umh --merange 16 --mvrange -1 --subme 7 --cabac --trellis 1 --no-psy --weightp 2 --aq-mode 2 --aq-strength 1 --vbv-maxrate 62500 --vbv-bufsize 78125 --nr 0 --deadzone-inter 21 --deadzone-intra 11 --cqm flat --threads 16 --sar 1:1 --deblock -1:-1 --ssim --colormatrix bt709 --fps 25000/1000 --input-res 1280x720 --opencl --opencl-clbin "C:\Users\ANONYM~1\AppData\Local\Temp\x264_lookahead_12_28_53_1010_01.clbin" --output "C:\Users\ANONYM~1\AppData\Local\Temp\12_28_53_1010_01.264" -
raw [info]: 1280x720p 1:1 @ 25/1 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSEMisalign LZCNT
x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce GTX 660
x264 [info]: Compiling OpenCL kernels...
x264 [info]: profile High, level 4.2
x264 [info]: frame I:137 Avg QP:19.14 size:116097
x264 [info]: frame P:2657 Avg QP:22.26 size: 26380
x264 [info]: frame B:9535 Avg QP:24.49 size: 7303
x264 [info]: consecutive B-frames: 2.1% 3.5% 6.4% 17.6% 15.9% 54.6%
x264 [info]: mb I I16..4: 16.2% 73.9% 9.9%
x264 [info]: mb P I16..4: 12.2% 18.0% 1.4% P16..4: 38.6% 12.7% 4.7% 0.0% 0.0% skip:12.4%
x264 [info]: mb B I16..4: 1.7% 1.8% 0.1% B16..8: 34.4% 4.1% 0.6% direct: 1.8% skip:55.6% L0:42.1% L1:49.2% BI: 8.7%
x264 [info]: 8x8 transform intra:57.1% inter:66.8%
x264 [info]: direct mvs spatial:99.9% temporal:0.1%
x264 [info]: coded y,uvDC,uvAC intra: 60.1% 64.5% 23.2% inter: 13.9% 18.0% 3.3%
x264 [info]: i16 v,h,dc,p: 26% 22% 30% 22%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 12% 17% 31% 5% 7% 7% 7% 6% 7%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 19% 23% 6% 10% 8% 8% 6% 6%
x264 [info]: i8c dc,h,v,p: 53% 23% 19% 4%
x264 [info]: Weighted P-Frames: Y:2.7% UV:1.5%
x264 [info]: ref P L0: 54.4% 15.0% 15.4% 5.8% 5.7% 3.5% 0.2% 0.0%
x264 [info]: ref B L0: 80.1% 12.0% 5.5% 1.7% 0.7%
x264 [info]: ref B L1: 93.5% 6.5%
x264 [info]: SSIM Mean Y:0.9725541 (15.615db)
x264 [info]: kb/s:2524.64
encoded 12329 frames, 39.35 fps, 2524.64 kb/s


At the moment I have no idead what makes the difference...

[mogobime]

To me it seems that increasing bframes from 3->6 increases encoding speed at faster presets than "very slow" - contrary to regular CPU-based lookahead.

Also subme 7 seems to benefit more from OpenCL-lookahead than subme 9.


EDIT 30.03.2013:

CRF22, preset --slower, (sync-lookahead modified to 150), OpenCL OFF:

x264.exe --crf 22 --profile high --level 4.2 --ref 8 --keyint 250 --min-keyint 0 --scenecut 40 --bframes 3 --b-bias 0 --b-pyramid normal --direct auto --b-adapt 2 --lookahead-threads 2 --sync-lookahead 150 --cplxblur 20 --qcomp 0.6 --qblur 0.5 --mbtree --rc-lookahead 60 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --qpmin 0 --qpmax 69 --qpstep 4 --partitions all --8x8dct --no-dct-decimate --me umh --merange 16 --mvrange -1 --subme 9 --cabac --trellis 2 --psy-rd 1:0 --weightp 2 --aq-mode 1 --aq-strength 1 --vbv-maxrate 62500 --vbv-bufsize 78125 --nr 0 --deadzone-inter 21 --deadzone-intra 11 --cqm flat --threads auto --sar 1:1 --deblock 0:0 --colormatrix bt709 --fps 25000/1000 --input-res 1280x720 --output "..." -
raw [info]: 1280x720p 1:1 @ 25/1 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSEMisalign LZCNT
x264 [info]: profile High, level 4.2
x264 [info]: frame I:140 Avg QP:19.44 size:120148
x264 [info]: frame P:3826 Avg QP:22.08 size: 25941
x264 [info]: frame B:8363 Avg QP:23.83 size: 10445
x264 [info]: consecutive B-frames: 2.2% 4.6% 52.1% 41.1%
x264 [info]: mb I I16..4: 7.0% 82.3% 10.7%
x264 [info]: mb P I16..4: 2.5% 9.8% 0.5% P16..4: 56.8% 11.7% 8.6% 0.1% 0.0% skip:10.0%
x264 [info]: mb B I16..4: 0.2% 1.8% 0.0% B16..8: 50.4% 4.4% 0.8% direct: 5.1% skip:37.3% L0:44.6% L1:50.8% BI: 4.6%
x264 [info]: 8x8 transform intra:80.5% inter:71.4%
x264 [info]: direct mvs spatial:99.9% temporal:0.1%
x264 [info]: coded y,uvDC,uvAC intra: 76.9% 76.8% 36.9% inter: 19.3% 32.4% 7.6%
x264 [info]: i16 v,h,dc,p: 38% 21% 15% 26%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 7% 8% 11% 10% 14% 12% 14% 10% 14%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 9% 13% 6% 8% 14% 12% 13% 10% 14%
x264 [info]: i8c dc,h,v,p: 50% 25% 16% 9%
x264 [info]: Weighted P-Frames: Y:2.5% UV:1.4%
x264 [info]: ref P L0: 48.5% 10.9% 16.8% 8.1% 5.1% 4.0% 3.3% 2.1% 1.1% 0.0%
x264 [info]: ref B L0: 74.5% 11.4% 7.1% 2.9% 2.2% 1.3% 0.6%
x264 [info]: ref B L1: 88.0% 12.0%
x264 [info]: kb/s:3299.97
encoded 12329 frames, 17.81 fps, 3299.97 kb/s

CRF22, preset --slower, (sync-lookahead modified to 150), OpenCL ON:

x264.exe" --crf 22 --profile high --level 4.2 --ref 8 --keyint 250 --min-keyint 0 --scenecut 40 --bframes 3 --b-bias 0 --b-pyramid normal --direct auto --b-adapt 2 --lookahead-threads 2 --sync-lookahead 150 --cplxblur 20 --qcomp 0.6 --qblur 0.5 --mbtree --rc-lookahead 60 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --qpmin 0 --qpmax 69 --qpstep 4 --partitions all --8x8dct --no-dct-decimate --me umh --merange 16 --mvrange -1 --subme 9 --cabac --trellis 2 --psy-rd 1:0 --weightp 2 --aq-mode 1 --aq-strength 1 --vbv-maxrate 62500 --vbv-bufsize 78125 --nr 0 --deadzone-inter 21 --deadzone-intra 11 --cqm flat --threads auto --sar 1:1 --deblock 0:0 --colormatrix bt709 --fps 25000/1000 --input-res 1280x720 --opencl --opencl-clbin "..." --output "..." -
raw [info]: 1280x720p 1:1 @ 25/1 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSEMisalign LZCNT
x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce GTX 660
x264 [info]: Compiling OpenCL kernels...
x264 [info]: profile High, level 4.2
x264 [info]: frame I:139 Avg QP:19.53 size:118485
x264 [info]: frame P:3722 Avg QP:22.11 size: 25743
x264 [info]: frame B:8468 Avg QP:23.82 size: 10457
x264 [info]: consecutive B-frames: 2.3% 4.3% 42.3% 51.1%
x264 [info]: mb I I16..4: 7.5% 81.8% 10.7%
x264 [info]: mb P I16..4: 2.6% 10.2% 0.5% P16..4: 56.5% 11.6% 8.5% 0.1% 0.0% skip:10.0%
x264 [info]: mb B I16..4: 0.2% 1.8% 0.0% B16..8: 50.6% 4.5% 0.8% direct: 5.1% skip:36.9% L0:45.0% L1:50.4% BI: 4.5%
x264 [info]: 8x8 transform intra:80.1% inter:71.6%
x264 [info]: direct mvs spatial:99.9% temporal:0.1%
x264 [info]: coded y,uvDC,uvAC intra: 76.5% 76.3% 36.1% inter: 19.1% 32.0% 7.1%
x264 [info]: i16 v,h,dc,p: 38% 21% 15% 26%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 7% 8% 10% 10% 14% 12% 14% 10% 14%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 9% 13% 6% 8% 14% 12% 13% 10% 14%
x264 [info]: i8c dc,h,v,p: 49% 25% 16% 9%
x264 [info]: Weighted P-Frames: Y:2.3% UV:1.3%
x264 [info]: ref P L0: 48.7% 10.9% 17.3% 7.6% 5.1% 4.0% 3.3% 2.1% 1.0% 0.0%
x264 [info]: ref B L0: 74.2% 11.8% 7.1% 2.9% 2.2% 1.3% 0.6%
x264 [info]: ref B L1: 89.4% 10.6%
x264 [info]: kb/s:3257.93
encoded 12329 frames, 18.53 fps, 3257.93 kb/s

->speed increase 4,0%


CRF22, preset --slower, (sync-lookahead modified to 150), bframes increased to 6, OpenCL OFF:

x264.exe --crf 22 --profile high --level 4.2 --ref 8 --keyint 250 --min-keyint 0 --scenecut 40 --bframes 6 --b-bias 0 --b-pyramid normal --direct auto --b-adapt 2 --lookahead-threads 2 --sync-lookahead 150 --cplxblur 20 --qcomp 0.6 --qblur 0.5 --mbtree --rc-lookahead 60 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --qpmin 0 --qpmax 69 --qpstep 4 --partitions all --8x8dct --no-dct-decimate --me umh --merange 16 --mvrange -1 --subme 9 --cabac --trellis 2 --psy-rd 1:0 --weightp 2 --aq-mode 1 --aq-strength 1 --vbv-maxrate 62500 --vbv-bufsize 78125 --nr 0 --deadzone-inter 21 --deadzone-intra 11 --cqm flat --threads auto --sar 1:1 --deblock 0:0 --colormatrix bt709 --fps 25000/1000 --input-res 1280x720 --output "..." -
raw [info]: 1280x720p 1:1 @ 25/1 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSEMisalign LZCNT
x264 [info]: profile High, level 4.2
x264 [info]: frame I:127 Avg QP:18.98 size:129079
x264 [info]: frame P:2594 Avg QP:21.97 size: 29951
x264 [info]: frame B:9608 Avg QP:23.82 size: 10884
x264 [info]: consecutive B-frames: 1.8% 3.1% 6.2% 15.5% 15.7% 57.3% 0.3%
x264 [info]: mb I I16..4: 6.7% 82.1% 11.1%
x264 [info]: mb P I16..4: 3.3% 12.9% 0.7% P16..4: 53.2% 13.8% 8.1% 0.1% 0.0% skip: 7.9%
x264 [info]: mb B I16..4: 0.2% 1.8% 0.0% B16..8: 49.1% 4.7% 0.9% direct: 5.3% skip:38.0% L0:44.3% L1:50.6% BI: 5.0%
x264 [info]: 8x8 transform intra:80.6% inter:72.2%
x264 [info]: direct mvs spatial:99.9% temporal:0.1%
x264 [info]: coded y,uvDC,uvAC intra: 77.3% 78.0% 39.5% inter: 18.1% 31.0% 7.1%
x264 [info]: i16 v,h,dc,p: 38% 22% 15% 26%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 7% 9% 11% 10% 14% 12% 13% 10% 14%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 9% 13% 6% 8% 14% 12% 13% 10% 14%
x264 [info]: i8c dc,h,v,p: 51% 24% 16% 9%
x264 [info]: Weighted P-Frames: Y:2.6% UV:1.4%
x264 [info]: ref P L0: 53.0% 12.9% 14.0% 6.9% 5.8% 3.9% 2.2% 1.2% 0.1% 0.0%
x264 [info]: ref B L0: 78.0% 11.7% 5.7% 2.4% 1.3% 0.6% 0.2%
x264 [info]: ref B L1: 93.1% 6.9%
x264 [info]: kb/s:3222.65
encoded 12329 frames, 17.74 fps, 3222.65 kb/s

CRF22, preset --slower, (sync-lookahead modified to 150), bframes increased to 6, OpenCL ON:

x264.exe" --crf 22 --profile high --level 4.2 --ref 8 --keyint 250 --min-keyint 0 --scenecut 40 --bframes 6 --b-bias 0 --b-pyramid normal --direct auto --b-adapt 2 --lookahead-threads 2 --sync-lookahead 150 --cplxblur 20 --qcomp 0.6 --qblur 0.5 --mbtree --rc-lookahead 60 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --qpmin 0 --qpmax 69 --qpstep 4 --partitions all --8x8dct --no-dct-decimate --me umh --merange 16 --mvrange -1 --subme 9 --cabac --trellis 2 --psy-rd 1:0 --weightp 2 --aq-mode 1 --aq-strength 1 --vbv-maxrate 62500 --vbv-bufsize 78125 --nr 0 --deadzone-inter 21 --deadzone-intra 11 --cqm flat --threads auto --sar 1:1 --deblock 0:0 --colormatrix bt709 --fps 25000/1000 --input-res 1280x720 --opencl --opencl-clbin "..." --output "..." -
raw [info]: 1280x720p 1:1 @ 25/1 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSEMisalign LZCNT
x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce GTX 660
x264 [info]: Compiling OpenCL kernels...
x264 [info]: profile High, level 4.2
x264 [info]: frame I:127 Avg QP:19.12 size:126207
x264 [info]: frame P:2610 Avg QP:22.02 size: 29126
x264 [info]: frame B:9592 Avg QP:23.84 size: 10860
x264 [info]: consecutive B-frames: 1.9% 3.1% 6.6% 16.0% 14.6% 57.5% 0.3%
x264 [info]: mb I I16..4: 6.9% 81.9% 11.2%
x264 [info]: mb P I16..4: 3.4% 12.9% 0.7% P16..4: 53.4% 13.4% 8.0% 0.1% 0.0% skip: 8.1%
x264 [info]: mb B I16..4: 0.2% 1.8% 0.0% B16..8: 49.0% 4.7% 0.9% direct: 5.4% skip:38.0% L0:44.5% L1:50.6% BI: 4.9%
x264 [info]: 8x8 transform intra:80.3% inter:72.4%
x264 [info]: direct mvs spatial:99.9% temporal:0.1%
x264 [info]: coded y,uvDC,uvAC intra: 76.9% 77.7% 38.7% inter: 18.0% 30.8% 6.9%
x264 [info]: i16 v,h,dc,p: 38% 22% 15% 26%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 7% 9% 11% 10% 14% 12% 14% 10% 14%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 9% 13% 6% 8% 14% 12% 13% 10% 14%
x264 [info]: i8c dc,h,v,p: 50% 25% 16% 9%
x264 [info]: Weighted P-Frames: Y:2.5% UV:1.3%
x264 [info]: ref P L0: 52.7% 12.6% 14.6% 6.9% 5.7% 3.9% 2.3% 1.3% 0.1% 0.0%
x264 [info]: ref B L0: 77.8% 11.8% 5.7% 2.4% 1.4% 0.6% 0.2%
x264 [info]: ref B L1: 93.1% 6.9%
x264 [info]: kb/s:3182.99
encoded 12329 frames, 19.02 fps, 3182.99 kb/s

-> speed increase 7,2%

[mogobime]

I created some more OpenCL-lookahead/DGDecNV decoding benchmark-spreadsheets in the meantime.
They for example compare the performance of non-standard bframes values and show the performance of opencl-lookahead using the x264 presets:
http://forum.selur.de/post2766.html#p2766

[Dodgexander]

So currently there's no significant performance gain at all by changing b frames? At least for 1080p. Start to compare it to ffmpeg alone and you see an improvement:)

[mogobime]

There is only a significant performance gain improving bframes compared to the established cpu-based lookahead (you can see this at the diff. FPS % column).
Increasing bframes can improve quality at (almost) no speed cost.
For example for me preset --slower with reduced ref=6 and increased bframes=5 performs very good with OpenCL.

ffmpeg:
As you can see in the few tests here (http://forum.selur.de/post2750.html#p2750) posted directly in the thread (not the posted spreadsheets), ffmpeg was slower for me than mencoder, no matter if I used opencl or not.

[Dodgexander]

Thanks for testing this, the results are interesting. I hope for better open-cl support in the future:p

Sent from my Blade S using Tapatalk 2

[mogobime]

I created one more (probably the last) comparison. 1080p source encoded with all x264 presets that support lookahead and with lookahead-threads calculated by x264:
http://forum.selur.de/post2766.html#p2766

[CarlPig]

Where can i get a x264 64-Bit build with OpenCL Patch of just a x264 32-Bit build with OpenCL Patch??

[mogobime]

It has been posted a few posts before already :rolleyes:: http://tmod.nmm-hd.org/x264/test/

[CarlPig]

Thanks for the link.

I will try it out.

[plonk420]

anyone have any luck (or tips for working) with AMD? running 5870 with astrataro's build. using 12.10; supposedly i installed APP 2.7 (tho the DirectComputeBenchmark 0.45b says i'm running 2.5, even after an uninstall where i verified OpenCL stuffs appeared to be uninstalled and non-functional).

edit: with --opencl, the CLI freezes for a short bit, then driver crashes.

[mandarinka]

As a general precaution, try to use the newest possible driver.

[plonk420]

i went from the newest drivers (which crashed on my first attempts) to the most recent ones AMD said was compatible (at somewhat implied that they were unofficially certified) with APP 2.7 to no avail.

[Blue_MiSfit]

D:\VideoTests\Test Sources\Elemental_4k>c:\x264\x264 1080p24.avs --preset veryfa
st --bitrate 4000 --output test2.mkv --opencl
avs [info]: 1920x1080p 0:0 @ 24000/1001 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce GTX 460

x264 [info]: Compiling OpenCL kernels...
x264 [info]: profile High, level 4.0
x264 [error]: clEnqueueNDRangeKernel error '-4'
x264 [error]: OpenCL: CL_MEM_OBJECT_ALLOCATION_FAILURE error executing CL_COMMAN
D_NDRANGE_KERNEL on GeForce GTX 460 (Device 0).

x264 [error]: OpenCL: fatal error, aborting encode
x264 [error]: OpenCL: CL_MEM_OBJECT_ALLOCATION_FAILURE error executing CL_COMMAN
D_NDRANGE_KERNEL on GeForce GTX 460 (Device 0).

x264 [error]: OpenCL: fatal error, aborting encode
x264 [error]: clEnqueueNDRangeKernel error '-4'
x264 [error]: x264_encoder_encode failed
x264 [error]: clEnqueueNDRangeKernel error '-4'
x264 [error]: OpenCL: CL_MEM_OBJECT_ALLOCATION_FAILURE error executing CL_COMMAN
D_NDRANGE_KERNEL on GeForce GTX 460 (Device 0).

x264 [error]: OpenCL: fatal error, aborting encode
x264 [info]: final ratefactor: 19.54

aborted at input frame 21, output frame 0

D:\VideoTests\Test Sources\Elemental_4k>


Welp... not sure what's happening.

I'm using the latest nVidia WHQL drivers - 314.22 on Windows 7 x64 SP1.

This is x264 0.132.2309 3b1f1f7 - 8 bpc, 32 bit, from x264.nl

[plonk420]

mine just freezes after the last line (screen freezes for 5-7 seconds, goes black for a couple, then comes back with Driver Crashed)

x264 --opencl 3x01-lossless-clip.avs -o clip-default.mp4
avs [info]: 1280x720p 0:0 @ 25/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
x264 [info]: OpenCL acceleration enabled with Advanced Micro Devices, Inc. Cypress
x264 [info]: Compiling OpenCL kernels...
x264 [info]: profile High, level 3.1

until i Ctrl-C it a couple of times. x264.nl 32 bit version as well. GPU stuff *should* be working, as i've been mining bitcoin with cgminer the last month or so.

[mogobime]

@blue_misfits
To me it seems that you are running out of gpu memory. You should monitor gpu memory usage with gpu-z. Have a look at my benchmark-thread in the signature, it shows GPU mem usage with different settings.
Maybe you only have to close some windows/applications that eat too much GPU mem - otherwise try different settings.
With 2GB VRAM I didn't have much problems encoding with OpenCL.

[aegisofrime]

I'm wondering, has anyone done speed comparisons for OpenCL on a Trinity/Richland/Ivy Bridge/Haswell system, using the integrated GPU? I remember that Trinity got quite a large speedbump from running OpenCL.

[fabje]

Anyone build a new version biased on the newest x264 32bit version?

[the_weirdo]

Anyone build a new version biased on the newest x264 32bit version?

Latest x264 already has OpenCL lookahead feature. Is that what you asked for?

[fabje]

Latest x264 already has OpenCL lookahead feature. Is that what you asked for?
Ah didn't know the option --opencl was already in x264 :)

[Balling]

The author wants to remove OpenCL from x264. I am against it. https://code.videolan.org/videolan/x264/-/merge_requests/66

In particular giant work in ffmpeg will be gone for opencl integration.

[FranceBB]

The author wants to remove OpenCL from x264. I am against it.

I'm against removing it too!
Thanks for letting us know, you should comment in that thread too and let him know.
The more the better.

This is my reply:


I understand your point in the sense that you wanna introduce changes in the way lookahead works and you can't due to the opencl support, however I'm not really in favour of removing it. I know that it hasn't been maintained for years, but despite it being a proof of concept, it actually helps offloading the CPU and speeding things up a bit. I know that benchmarks sometimes showed little to no speed increase at all, but there are some use cases in which it does actually help. For instance, Here at Sky we have several servers re-encoding XDCAM-50 and XDCAM-85 masterfiles into low bitrate consumer H.264 files for the web and since the CPU is responsible not only of encoding the file but also of deinterlacing and resizing the chroma (yv16 to yv12) through Avisynth in an automated fashion, using --opencl in x264 and making use of the NVIDIA Quadro P4000 actually helped and I've gained 12 FPS on every encode (generally there are multiple encodes on a single server, up to 20). The cool thing about this is that even though using NVEnc would be faster, the NVIDIA hardware encoder ain't nearly as good as x264, especially at low consumer-tier bitrates, which is why I have always leaned towards x264. I don't think opencl support should be removed, if anything I'd like to see it implemented in x265 too! I guess we should have an online discussion about x264 and Opencl, though, and ask users whether they would like to keep it or not and see if people are actually really using it (and something tells me that lots of people are indeed using it).


https://code.videolan.org/videolan/x264/-/merge_requests/66

[Atak_Snajpera]

Is opencl still useful with current AMD (ZEN) APU/Intel iGPU like in the past?
http://images.anandtech.com/graphs/graph5835/46687.png

[nevcairiel]

This is my reply

If you want to make use of the GPU, you should make it do what its actually good at - and move said deinterlacing and chroma resizing to it, because per-pixel operations like that are the bread and butter of the GPU. That would give you a much better speedup then OpenCL in x264.

Otherwise, you could also fund development of that feature to make sure it doesn't block further advancement. Apparently you use it in a professional capacity, so that should be in a realm of possibility. "But I use that!" is rarely enough of an answer, if its not followed by "and I'll help to maintain it!"

[FranceBB]

If you want to make use of the GPU, you should make it do what its actually good at - and move said deinterlacing and chroma resizing to it, because per-pixel operations like that are the bread and butter of the GPU. That would give you a much better speedup then OpenCL in x264.

The problem with that is that hardware accelerated filtering is very limited in Avisynth. There are some cuda aware filters, but if you take like Donald Graft's deinterlacer via CUDA, it's 4:2:0 only and I found it to provide not so good results compared to BWDIF. Of course I'd love to see things like QTGMC, MVTools and the various resizing kernels all hardware accelerated and CUDA Aware, like a CUDA Aware Avsresize, but we're still far from it. We made some progress thanks to Grandmaster Ferenc merging code from Avisynth Neo, but there's still a lot to do and it will take years.


Otherwise, you could also fund development of that feature to make sure it doesn't block further advancement. Apparently you use it in a professional capacity, so that should be in a realm of possibility.

Throwing money at it isn't always an answer. I remember when I opened a ticket in the FFMpeg bug tracker asking for automatic DolbyE detection and decoding, literally providing Devs with the current workaround and asking them how much money they wanted to have automatic detection and decoding implemented for each DolbyE case/configuration and nobody replied, which led me to write around 413 lines of code in python using mediainfo to check the input and apply the right DolbyE decoding workaround according to the different audio configurations as FFprobe was "broken" and it was reporting bogus values.


"But I use that!" is rarely enough of an answer, if its not followed by "and I'll help to maintain it!"

The only issue with that is that I'm an Avisynth kind of guy, I can't maintain Opencl code. :(
Nonetheless I think that the public should be taken into account here: if there are enough people using it, I just don't think it should be removed and that's all.
I think we should have a democratic pool and let people vote and accept whatever the outcome of such a vote is going to be. If there are not enough people using it and the majority just don't care and would rather have it removed to get a new lookahead instead, then so be it, I would accept the result of the pool and that's it, but removing Opencl (or indeed keeping it) is not a decision we should take lightly.

That being said, Happy New Year! :D

[lvqcl]

I think we should have a democratic pool and let people vote and accept whatever the outcome of such a vote is going to be.

IIC there are parasites that control the behavior of their victims, but I don't think that it will end well.

[FranceBB]

IIC there are parasites that control the behavior of their victims, but I don't think that it will end well.

LOL
Users contribute a lot, calling users parasites is a bit harsh, isn't it?

That being said, Happy New Year, everyone!

[rwill]

IIC there are parasites that control the behavior of their victims, but I don't think that it will end well.

Well said.

Lookahead is how much CPU time ?
15% in the faster speed modes of total runtime ?
Insignificant runtime in veryslow and placebo ?
Most of it going into DRAM memory bandwidth ?

So OpenCL requires to copy the lowres frame to the GPU which is very slow. The GPU is also not made for what x264 is doing so that is inefficient also. Then the results have to be copied back to the host. Per Frame. It might even become a bottleneck due to Host - Device synchronizing. When OpenCL is faster than the CPU implementation this points to some other issue somewhere. I wont go into details because it would be just wasted.

Really if the maintainer says no one wants to touch it and it blocks things, keeping it makes no sense.

If you other people want to use your GPU get your filter stuff on the GPU. GPUs are great when they work on full pictures really, especially when one chains kernels and things are kept on the device. Not so much when working with little blocks and having to go back to the host each kernel call.

[Atak_Snajpera]

Before you remove anything I strongly recommend to perform some benchmarks if opencl lookahead still gives extra speed boost on AMD apu cpus! Those cpus use system RAM for iGPU so bottleneck should be less noticeable.

[nevcairiel]

I think we should have a democratic pool and let people vote and accept whatever the outcome of such a vote is going to be.

Ignoring the fact that democracy on the Internet means who can motivate the most trolls or bots to vote on their behalf..
I also don't believe it has any place in software development, open-source or otherwise. If an active developer wants to improve the software as a whole, and a somewhat-niche feature is blocking it - as well as noone is offering to maintain it to remove said block....

Even if the vote would be entirely fair, if we properly word it "do you want opencl, or do you want x264 to improve?", would you accept a simple majority on that?

[benwaggoner]

For modern hardware, I imagine using the GPU H.264 encoder itself for lookahead could provide a better speedup without much quality loss. x265 has a lot of analysis reuse features that can speed up encoding quite a lot. It can even use H.264 stream input to accelerate HEVC encoding. Perhaps that code could be backported to x264?

But in any case, if removing OpenCL support in x264 enables improvements in lookahead, I can easily imagine that'll provide a much more impactful net improvement for x264 users. Depending on the improvements in mind, perhaps some or all of the minor perf improvements of OpenCL can be gained in pure software.

[FranceBB]

Ignoring the fact that democracy on the Internet means who can motivate the most trolls or bots to vote on their behalf..


True, although I always found Doom9 to be a safe heaven with dedicated and respectful people, which is very hard to find anywhere else on the internet.


If an active developer wants to improve the software as a whole, and a somewhat-niche feature is blocking it - as well as no one is offering to maintain it to remove said block....


I get that...
I mean, going forward if the improvements on the lookahead are really worth and really no one is willing to maintain opencl support, then I wouldn't mind.

Depending on the improvements in mind, perhaps some or all of the minor perf improvements of OpenCL can be gained in pure software.

That would be nice and would solve the problem for everyone.
CPU Performance improvements that would match the little opencl speed-up we already have so that we can toss opencl support?
I'm all for it! Bring it on, I say eheheheheheh

[Balling]

I still use 4th generation Intel for my windows 11 PC. and 2080 Ti. Thinking about Alder Lake. So it is obviously good there, is not it? And anyway, you can always do a separate code path without opencl. Why remove it?

[benwaggoner]

And anyway, you can always do a separate code path without opencl. Why remove it?
This seems to be the most compelling justification:
Its presence prevents changes of general lookahead code because it should be changed in sync with OpenCL lookahead code which nobody wants to touch. And so, it harms development of core functionality.
Lots of stuff in x264 is tied together. Changes that aren't compatible with OpenCL require more of a fork than a separate path. People who really want to keep using OpenCL can keep on using current builds that don't have new incompatible features.

Lookahead code is really important stuff, and is something I could see yield material improvements in x264 output again after years of stagnation in compression efficiency.

[Ritsuka]

The question is, what was the last time anyone here used the OpenCL lookahead?

[Emulgator]

Seeing FranceBB's use case: +12fps looks very good.
I did use OpenCL lookahead because it was there, but will not suffer if its gone.

Listening to the few who actually put their effort into maintaining codebase
I can imagine the roadblock it would create if kept and who would be funding at all ?

Having just upgraded from 22nm 4th generation i7 to 14nm 11th generation i9
(and seeing 7nm Ryzens 60% ahead speedwise while consuming same or less power):

That bit offload CPU->GPU seems to be less noticeable and might not be worth it anymore,
but it takes more power users to chime in.

[FranceBB]

Seeing FranceBB's use case: +12fps looks very good.
I did use OpenCL lookahead because it was there, but will not suffer if its gone.


Yeah, the thing is that my use case is very different to the one of the average user. Generally, users encode 1 file at a time, with a peculiarly written AVS Script and things like --preset veryslow and have a consumer GPU. On my side, however, this is done by an HP Server with an Intel Xeon CPU (28c/56th) which would be overly used anyway as it encodes several files at the same time from high bitrate yv16 25i internal mezzanine files to consumer-tier H.264 yv12 25p (even as many as 30 files at the same time sometimes, on rare occasions) with --preset medium to deliver the result to the social networks (Facebook, Twitter, Instagram), to YouTube and to the train stations all over the country (The recap of the Italian version of Sky News is played on the monitors of train stations scattered across Italy). So, with an overly loaded CPU and a professional card like the NVIDIA Quadro P4000 sitting there doing absolutely nothing, it makes sense to offload some of the work, hence the speed bump (it goes from around 96fps to around 108fps).

[Atak_Snajpera]

Seeing FranceBB's use case: +12fps looks very good.
I did use OpenCL lookahead because it was there, but will not suffer if its gone.

Listening to the few who actually put their effort into maintaining codebase
I can imagine the roadblock it would create if kept and who would be funding at all ?

Having just upgraded from 22nm 4th generation i7 to 14nm 11th generation i9
(and seeing 7nm Ryzens 60% ahead speedwise while consuming same or less power):

That bit offload CPU->GPU seems to be less noticeable and might not be worth it anymore,
but it takes more power users to chime in.

Have you benchmarked opencl using integrated GPU? It would be stupid to remove something what could give you ~25% speed boost on CPU with iGPU! BTW. ZEN4 will also have iGPU so not so fast with that "delete old code" mentality.

[rwill]

So, with an overly loaded CPU and a professional card like the NVIDIA Quadro P4000 sitting there doing absolutely nothing, it makes sense to offload some of the work, hence the speed bump (it goes from around 96fps to around 108fps).

I would just buy another headless server. Might I suggest one with some EPYC CPU ?

[Emulgator]

Have you benchmarked opencl using integrated GPU?
Not yet, will go to your x264 FHD benchmark soon.
Hm, have difficulties finding it. Links are dead.
Found something... 1.0.1 still valid ? 178MB?
I see: x264 from 2011, I would have to swap x264 and generate a new commandline.
Now I guess it would be better to use Ripbot because uf selectable OpenCL device, isn't it ?

P.S. Went testing StaxRip, OpenCL on CPU Integrated Graphics:
I don't know how to activate that path on that system, it is not available as dropdown.

Using the available RTX3080 OpenCL accelerates a bit:
x264 superslow encode from 7,9..8.0fps to 8,2..8,5fps.

[Atak_Snajpera]

Not yet, will go to your benchmark soon.

Perform simple 1080p test without any filtering in avisynth. Use at least preset medium and preset veryslow

[ReinerSchweinlin]

Could it be an option to move motion estimation from OPENCL to DX12 (at least on windows)?

http://forum.doom9.org/showthread.php?t=183517&page=3

I used the OPENCL Acceleration quite often in the past. Just like others stated above, it can offload some of the CPU work to the GPU and free up ressources for filtering etc... Especially with not so powerfull CPUs in combination with small AMD GPUs (which are fast in OPENCL... GCN 2 and above), the combination of GPU/CPU offered a lot of performance for the invested money.....

In my tests, it seemed like fast transfers from CPU to GPU helped in this regard - I noticed significant drops in speeds with slower PCI-E connections.
For smaller resolutions, iGPUs and APUs were a good combination. Although the processing power isn´t that great on internal GPUs, the often fast connection between CPU and GPU seemed to help..

This whole topic reminds of an older thread where Hardware-Acceleration of x264 and x265 was discussed... One of the developers of x265 jumped in and mentioned that with x265 it wasn´t worth thinking about adding some GPU offloading, because the transfer speeds were too much of a bottleneck. Also, AVX Extensions could do a lot of what the OPENCL part was doing (I hope I remember correctly, can´t find the thread at the moment...).. Maybe - with faster PCIE Connections, the situation could be re-evaluated ?

[benwaggoner]

Could it be an option to move motion estimation from OPENCL to DX12 (at least on windows)?
Sure. It would be less portable of course, and I'm not sure there would be any benefit.

I used the OPENCL Acceleration quite often in the past. Just like others stated above, it can offload some of the CPU work to the GPU and free up ressources for filtering etc... Especially with not so powerfull CPUs in combination with small AMD GPUs (which are fast in OPENCL... GCN 2 and above), the combination of GPU/CPU offered a lot of performance for the invested money...
The value proposition was a lot higher back when the standard CPU had only a few cores. The limited parallelization in x264 itself means there are generally unused cores available on modern hardware. Which is the hardware that the groups who fund x264 development use.

In my tests, it seemed like fast transfers from CPU to GPU helped in this regard - I noticed significant drops in speeds with slower PCI-E connections.
For smaller resolutions, iGPUs and APUs were a good combination. Although the processing power isn´t that great on internal GPUs, the often fast connection between CPU and GPU seemed to help..
Latency is generally a bigger limitation than bandwidth for this scenario. And modern codecs have more and more ways to do things, which means more and more very branchy logic with lots of early exits and heuristics. CPU + SIMD does that very well. Even though GPU has more compute available, the round trip latency between CPU and GPU means the GPU is often idle waiting for the CPU to process GPU output to make new instructions for the GPU.

The OpenCL preview uses a very simplified x264, nothing like what's in a --preset veryslow. One strong possibility is that using built-in encoder output could provide a similar fidelity of data, but faster and much simpler.

This whole topic reminds of an older thread where Hardware-Acceleration of x264 and x265 was discussed... One of the developers of x265 jumped in and mentioned that with x265 it wasn´t worth thinking about adding some GPU offloading, because the transfer speeds were too much of a bottleneck. Also, AVX Extensions could do a lot of what the OPENCL part was doing (I hope I remember correctly, can´t find the thread at the moment...).. Maybe - with faster PCIE Connections, the situation could be re-evaluated ?
HEVC has a lot more modes than H.264, so there's way more little branchy decisions to make per frame. And the bottle neck is more latency than bandwidth. And yeah, AVX2 and other SIMD can do a lot of GPU-style operations in a shared L3 cache. Net compute is quite a bit lower, but having super low latency between complex logic and SIMD makes up the delta and more.

The relatively small gains of OpenCL is a reflection of how much better CPUs have gotten more than anything. If GPUs had evolved at current pace but CPU designs stayed where they were in 2013, OpenCL would have a much bigger per gain.

This is a broad industry trend. Broadcast encoders a decade ago were mainly ASIC or GPU based. Today, particularly with HEVC, the high end stuff is all CPU based, because CPU offers the best quality @ bitrate @ $$$. Even with H.264, software x264 was always a lot better than any GPU or ASIC implementation for < 1 Mbps. AV1 and VVC are even more CPU-friendly, so I doubt we'll see a fundamental change. GPU is great for source decode and filtering, and for mixed filtering/encoding workflows, Having everything but encoding happen on GPU leaving the CPU for compete is a much more beneficial optimization.

[DTL]

"Of course I'd love to see things like QTGMC, MVTools and the various resizing kernels all hardware accelerated and CUDA Aware, like a CUDA Aware Avsresize, but we're still far from it. "

I read your company uses some expensive CPUs like Xeons platinum with 12-ch memory. (Possible memory speed about 1 TB/s). But do you have or plan to use some good-performance data compute accelerators like NVIDIA A100 (memory speed about 2 TB/s) ? I see it priced close to that Xeons (about $15000) and have a bit more mem speed and possibly higher computational performance. Though it may be pure computational accelerator without any piece of ME engine. So require to develop full Compute-Shader/DirectCompute based MAnalyse. But it is expected to be much faster in compare with currently fixed-performance ME engine in available accelerators.

I also interesting in possibility of adding DX12_ME to x264 on windows hosts (though I read some window-less processing of DX12-based applications also possible with Linux ?). Currently at i5-9600K + GTX1060 with transcoding some FullHD footage with tr=25 degraining and x264 with placebo-like settings at about 6..7 fps and about 9 Mbit/s output MPEG speed I have about 50% of Video Encode load and 100% CPU load. So about 50% of ME-engine resources is still free. It can offload some ME-work from x264 if it good separated from other processing. I still not look into 264 program how it is perform ME - in more or less separated function or highly integrated with 'branching' and other stuff ? If it is enough separated - it can be easily routed outside x264 execution to accelerator and download back the ME-result. The upload and download speed via bus should not be any issue. Even if make it with separated pairs of src+ref frames. But if ME is highly integrated in the other MPEG-encoding parts and can not be separated as total frame processing stage - it is sad.

" is something I could see yield material improvements in x264 output again after years of stagnation in compression efficiency. "

The real significant addition to efficiency for natural optical camera based footages is combining of noise reduction with 'classic MPEG' encoding. Do developers of 'pure MPEG' encoders plan to put some work into this approach ? Currently 'in the field' users of x264 need to apply external multi-frame noise reduction that is based on the same algoriphms that MPEG uses (motion-compensated blocks averaging). So for real benefit the good 'motion pictures compression engine' need to combine and reuse the ME processing for both mult-frame noise reduction and other compression stages.

Currently we have separate ME (CPU or accelerator based) in denosie pre-processing stage and next in the MPEG-encoding stage. It is waste of computational and hardware resources. The most sad fun is visible with latest DX12-ME mod of mvtools - the 'standard' now in Windows10 and later ME operating system's service (accelerated by hardware MPEG encoder chip) is completely compatible with multi-frame denoiser and can gain the compression efficiency up to several times (depending on noise level in the input footage and crf-setting and scenes complexity).
And for natural camera-based footages the output MPEG-speed (actual total compression efficiency) is greatly based on amout of residual noise after denoise stage and crf-setting in the x264 encoder. Also x264 have some 'denoiser' built-in. But why it have so poor performance and possibly never used by anyone ?

"And modern codecs have more and more ways to do things, which means more and more very branchy logic with lots of early exits and heuristics. CPU + SIMD does that very well. "

With the progress of number of 'unuiversal compute cores' at accelerators I see the old 'video cards' greatly outperforms the 'CPU chips'. Shame on intel-architecture of PCs - it now stuck with both low logical cores and low host memory speed. Number of compute cores at accelerator may be easily to dozens and hundreds and each core may execute its logical thread at simple logical C-language written. With host CPU programmer is overloaded with attempt to fit in few numbers of avaialble 'universal logic hardware threads' and try to put data parallelization into very limited in logic and avaialble optimal data-placement patterns SIMD-coprocessor. Each program for SIMD-coprocessor is low-level hand-crafted (separately for each SIMD-generation) and still only more or less effective for some given dataset size (like block size only NxN, bitdepth only M, etc, etc).
With mvtools example - simple SAD computation 'onCPU' using ready to use ME-MVs data takes visible time and loads host memory significantly. Even with best-in-world SIMD optimizations fine tuned by decades (actually taken from x264 project as I see). With simple C-based compute shader at accelerator is still something inbetween 0 and 1% of 'GPU load' on the mid-201x year accelerator.

[ReinerSchweinlin]

@benwaggoner

Thanx for taking the time to respond in such a elaborate way, I apprecciate it :)