OpenCL: Custom MaxDuration from john.conf isn't halved in initial GWS tuning, and seems to be limited to original value.

[magnumripper]

Normally when a kernel is autotuned with a max_duration of 200, that figured is halved for the initial GWS tune:

Benchmarking: Bitcoin-opencl, Bitcoin Core [SHA512 AES OpenCL]... Loaded 13 hashes with 13 different salts to test db from test vectors
(...)
Calculating best GWS for LWS=32; max. 100 ms single kernel invocation.
(...)
Calculating best LWS for GWS=65536
(...)
Calculating best GWS for LWS=256; max. 200 ms single kernel invocation.
(...)
LWS=256 GWS=34816 (136 blocks) DONE
Speed for cost 1 (iteration count) of 200460
Raw:    10582 c/s real, 10614 c/s virtual, Dev#2 util: 100%

Problem 1: If I decrease the default using Bitcoin_MaxDuration = 80 in john.conf, the figure will be honored but not halved for the initial one:

Benchmarking: Bitcoin-opencl, Bitcoin Core [SHA512 AES OpenCL]... Loaded 13 hashes with 13 different salts to test db from test vectors
(...)
Calculating best GWS for LWS=32; max. 80 ms single kernel invocation.
(...)
Calculating best LWS for GWS=65536
(...)
Calculating best GWS for LWS=256; max. 80 ms single kernel invocation.
(...)
LWS=256 GWS=34816 (136 blocks) DONE
Speed for cost 1 (iteration count) of 200460
Raw:    10614 c/s real, 10614 c/s virtual, Dev#2 util: 100%

Problem 2: If I increase the value instead using using Bitcoin_MaxDuration = 400, it seems to be limited to the original value and silently ignored:

Benchmarking: Bitcoin-opencl, Bitcoin Core [SHA512 AES OpenCL]... Loaded 13 hashes with 13 different salts to test db from test vectors
(...)
Calculating best GWS for LWS=32; max. 100 ms single kernel invocation.
(...)
Calculating best LWS for GWS=65536
(...)
Calculating best GWS for LWS=256; max. 200 ms single kernel invocation.
(...)

[magnumripper]

Tried this:

$ git diff
diff --git a/run/john.conf b/run/john.conf
index a8c286bd7..c1f1ed2f5 100644
--- a/run/john.conf
+++ b/run/john.conf
@@ -418,6 +418,8 @@ ResumeWS = N
 # kernel will perform optimally at 100-200 ms anyway.
 Global_MaxDuration =

+Bitcoin_MaxDuration = 400
+
 # Some formats vectorize their kernels in case the device says it's a good
 # idea. Some devices give "improper" hints which means we vectorize but get
 # a performance drop. If you have such a device, uncommenting the below
diff --git a/src/opencl_bitcoin_fmt_plug.c b/src/opencl_bitcoin_fmt_plug.c
index 58a1e9ef6..8a07e8454 100644
--- a/src/opencl_bitcoin_fmt_plug.c
+++ b/src/opencl_bitcoin_fmt_plug.c
@@ -240,7 +240,7 @@ static void reset(struct db_main *db)
                               sizeof(hash512_t), 0, db);

        // Auto tune execution from shared/included code, 200ms crypt_all() max.
-       autotune_run(self, 200460 /* first test vector's iteration count */, 0, 200);
+       autotune_run(self, 200460 /* first test vector's iteration count */, 0, 500);
 }

 static void done(void)

Interestingly enough, the initial tune now show half of format's default (of now 500) and the custom setting of 400 is honored in the final tune.

Benchmarking: Bitcoin-opencl, Bitcoin Core [SHA512 AES OpenCL]... Loaded 13 hashes with 13 different salts to test db from test vectors
(...)
Calculating best GWS for LWS=32; max. 250 ms single kernel invocation.
(...)
Calculating best LWS for GWS=262144
(...)
Calculating best GWS for LWS=32; max. 400 ms single kernel invocation.
(...)
LWS=32 GWS=278528 (8704 blocks) DONE
Speed for cost 1 (iteration count) of 200460
Raw:    10737 c/s real, 10737 c/s virtual, Dev#2 util: 100%

[magnumripper]

@claudioandre-br I have plenty on my to-do list so if you have the time, please bite on this

[claudioandre-br]

@claudioandre-br I have plenty on my to-do list so if you have the time, please bite on this

I'm going to add it to my christmas to-do list.