<div dir="ltr">Interesting use-case. Certainly seems like a feature that will be useful for folks who're looking to enable more threads than available CPUs.<div>I guess the --pools N will be a "special case" of --pools X,X where N can be > number of CPUs in the system. We can continue to clip the # threads in the case that pools are specified as X,X which is what your patch does.<br><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Pradeep.</div><div><br></div></div></div></div></div></div></div></div></div></div></div><div class="gmail_quote">On Tue, May 17, 2016 at 10:55 PM, Mateusz <span dir="ltr"><<a href="mailto:mateuszb@poczta.onet.pl" target="_blank">mateuszb@poczta.onet.pl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If I use '--pools 6144 -F16' option with this patch on i5
CPU, I get<br>
x265 [info]: Thread pool created using 64 threads<br>
x265 [info]: frame threads / pool features : 16 /
wpp(12 rows)<br>
<br>
Without this patch I get only 4 threads.</blockquote>
<div><br>
This is the problem that I feared - since the HW has only
4 threads, even though you specified 6144 as the # SW
threads you wanted to create, we should've spawned only 4
SW threads also. Using min CPUs across all NUMA nodes will
ensure that you only spawn 4 SW threads. You are currently
clipped at 64 threads because that is the max # threads in
on pool (limited by the fact that we use a 64-bit bit
vector for a mask and hence can only track 64 threads per
pool).</div>
</div>
</div>
</div>
</blockquote></span>
If user wants more threads than # CPUs, there is no reason to
prohibit that.<br>
Example: user has 2 CPUs system and wants to know if there will be
significant quality loss at encoding when he buy 16 CPUs system. He
can encode sample with 2 threads/1 frame thread option as default
for 2 CPUs system and the same sample with 16 threads/5 frame
threads option as default for 16 CPUs system:<br>
g:\speed\1.9+169>x265-611 --pools 2 -F1 -p slower --crf 17
../720p50_parkrun_ter.y4m w1.hevc<br>
y4m [info]: 1280x720 fps 50/1 i420p8 sar 1:1 frames 0 - 503 of 504<br>
raw [info]: output file: w1.hevc<br>
x265 [info]: HEVC encoder version 1.9+169-e5b5bdc3c154<br>
x265 [info]: build info [Windows][GCC 6.1.1][64 bit] 10bit+8bit<br>
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX<br>
x265 [info]: Main 10 profile, Level-4 (Main tier)<br>
x265 [info]: Thread pool created using 2 threads<br>
x265 [info]: frame threads / pool features : 1 / wpp(12 rows)<br>
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8<br>
x265 [info]: Residual QT: max TU size, max depth : 32 / 2 inter / 2
intra<br>
x265 [info]: ME / range / subpel / merge : star / 57 / 3 / 3<br>
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40<br>
x265 [info]: Lookahead / bframes / badapt : 30 / 8 / 2<br>
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1<br>
x265 [info]: References / ref-limit cu / depth : 4 / on / off<br>
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1<br>
x265 [info]: Rate Control / qCompress : CRF-17.0 / 0.60<br>
x265 [info]: tools: rect amp limit-modes rd=6 psy-rd=2.00 rdoq=2
psy-rdoq=1.00<br>
x265 [info]: tools: recursion-skip signhide tmvp b-intra
strong-intra-smoothing<br>
x265 [info]: tools: lslices=4 deblock sao<br>
x265 [info]: frame I: 4, Avg QP:18.57 kb/s: 92026.90<br>
x265 [info]: frame P: 105, Avg QP:22.85 kb/s: 83763.35<br>
x265 [info]: frame B: 395, Avg QP:28.82 kb/s: 14106.11<br>
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%<br>
x265 [info]: Weighted B-Frames: Y:0.0% UV:0.0%<br>
x265 [info]: consecutive B-frames: 3.7% 0.0% 7.3% 48.6% 16.5% 13.8%
6.4% 0.9% 2.8%<br>
<br>
encoded 504 frames in 854.67s (0.59 fps), 29236.45 kb/s, Avg
QP:27.50<br>
<br>
g:\speed\1.9+169>x265-611 --pools 16 -F5 -p slower --crf 17
../720p50_parkrun_ter.y4m w2.hevc<br>
y4m [info]: 1280x720 fps 50/1 i420p8 sar 1:1 frames 0 - 503 of 504<br>
raw [info]: output file: w2.hevc<br>
x265 [info]: HEVC encoder version 1.9+169-e5b5bdc3c154<br>
x265 [info]: build info [Windows][GCC 6.1.1][64 bit] 10bit+8bit<br>
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX<br>
x265 [info]: Main 10 profile, Level-4 (Main tier)<br>
x265 [info]: Thread pool created using 16 threads<br>
x265 [info]: frame threads / pool features : 5 / wpp(12 rows)<br>
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8<br>
x265 [info]: Residual QT: max TU size, max depth : 32 / 2 inter / 2
intra<br>
x265 [info]: ME / range / subpel / merge : star / 57 / 3 / 3<br>
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40<br>
x265 [info]: Lookahead / bframes / badapt : 30 / 8 / 2<br>
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1<br>
x265 [info]: References / ref-limit cu / depth : 4 / on / off<br>
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1<br>
x265 [info]: Rate Control / qCompress : CRF-17.0 / 0.60<br>
x265 [info]: tools: rect amp limit-modes rd=6 psy-rd=2.00 rdoq=2
psy-rdoq=1.00<br>
x265 [info]: tools: recursion-skip signhide tmvp b-intra
strong-intra-smoothing<br>
x265 [info]: tools: lslices=4 deblock sao<br>
x265 [info]: frame I: 4, Avg QP:18.56 kb/s: 92079.80<br>
x265 [info]: frame P: 106, Avg QP:22.87 kb/s: 82357.07<br>
x265 [info]: frame B: 394, Avg QP:28.84 kb/s: 14132.80<br>
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%<br>
x265 [info]: Weighted B-Frames: Y:0.0% UV:0.0%<br>
x265 [info]: consecutive B-frames: 5.5% 0.0% 6.4% 47.3% 17.3% 12.7%
7.3% 1.8% 1.8%<br>
<br>
encoded 504 frames in 407.48s (1.24 fps), 29100.19 kb/s, Avg
QP:27.50<br>
<br>
You can see that the output files differ and user can watch both
files and decide.<br>
</div>
<br>_______________________________________________<br>
x265-devel mailing list<br>
<a href="mailto:x265-devel@videolan.org">x265-devel@videolan.org</a><br>
<a href="https://mailman.videolan.org/listinfo/x265-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/listinfo/x265-devel</a><br>
<br></blockquote></div><br></div></div></div>