Something weird happend here, read on!
I've expected some performance drop because this algorithm is using the password data itself inside the iteration loop.
That is different to PBKDF2, which I've converted in mode 2100 before and which did not show any performance as expected.
So after I've finished converting this kernel and testing everything works using the unit test, I did some benchmarks to see how much the
performance drop is.
On my 750ti, the speed dropped (minimal) from 981kH/s -> 948kH/s, that's mostly because of the SIMD support i had to drop.
If I'd turn off the SIMD support in the original, the drop would be even less, that us 967kH/s -> 948kH/s which is a bit of a more reasable
comparison in case we just want to rate the drop that is actually caused by the code change itself.
The drop was acceptable for me, so I've decided to check on my GTX1080.Now the weird thing: The performance increased from 6619kH/s to
7134kH/s!!
When I gave it a second thought, it turned out that:
1. The GTX1080 is a scalar GPU so it wont suffer from the drop of the SIMD code as the 750ti did
2. There's a change in how the global data (password) is read into the registers, it reads only that amount of data it actually needs by using
the pw_len information
3. I've added a barrier for CLK_GLOBAL_MEM_FENCE as it turned out to increase the performance in the 750ti
Note that this kernel is now branched into password length < 40 and larger.
There's a large drop on performance where SIMD is really important, for example CPU.
We could workaround this issue by sticking to SIMD inside the length < 40 branch, but I don't know yet how this can be done efficiently.
- Dropped static declaration from functions in all kernel to achieve OpenCL 1.1 compatibility
- Added -cl-std=CL1.1 to all kernel build options
- Created environment variable to inform NVidia OpenCL runtime to not create its own kernel cache
- Created environment variable to inform pocl OpenCL runtime to not create its own kernel cache
1) SIMD code for all attack-mode
Macro vector_accessible() was not refactored and missing completely.
Had to rename variables rules_cnt, combs_cnt and bfs_cnt into il_cnt which was a good thing anyway as with new SIMD code they all act in the same way.
2) SIMD code for attack-mode 0
With new SIMD code, apply_rules_vect() has to return u32 not u32x.
This has massive impact on all *_a0 kernels.
I've rewritten most of them. Deep testing using test.sh is still required.
Some kernel need more fixes:
- Some are kind of completely incompatible like m10400 but they still use old check_* includes, we should get rid of them as they are no longer neccessary as we have simd.c
- Some have a chance but require additional effort like m11500. We can use commented out "#define NEW_SIMD_CODE" to find them
This change can have negative impact on -a0 performance for device that require vectorization. That is mostly CPU devices. New GPU's are all scalar, so they wont get hurt by this.
This change also proofes that there's no way to efficiently vectorize kernel rules with new SIMD code, but it enables the addition of the rule functions like @ that we were missing for some long time. This is a TODO.
- Some performance on low-end GPU may drop because of that, but only for a few hash-modes
- Dropped scalar code (aka warp) since we do not have any vector datatypes anymore
- Renamed C++ overloading functions memcat32_9 -> memcat_c32_w4x4_a3x4
- Still need to fix kernels to new function names, needs to be done manually
- Temperature Management needs to be rewritten partially because of conflicting datatypes names
- Added code to create different codepaths for NV on AMD in runtime in host (see data.vendor_id)
- Added code to create different codepaths for NV on AMD in runtime in kernels (see IS_NV and IS_AMD)
- First tests working for -m 0, for example
- Great performance increases in general for NV so far
- Tested amp_* and markov_* kernel
- Migrated special NV optimizations for rule processor
