28 Commits (b71e06fca8ef172cc1e507635afcb8d925a25822)

Author	SHA1	Message	Date
jsteube	dad05d9f69	Testing: Workaround some AMD OpenCL runtime segmentation faults	6 years ago
Jens Steube	02a2495349	Switched array pointer types in function declarations in order to be compatible with OpenCL 2.0	6 years ago
Jens Steube	a15c165773	Revert the pos == 0 change due to some unexpected results on nvidia	6 years ago
jsteube	b626e7f61b	Optimize update functions in inc_hash_* helper files by testing for pos == 0	6 years ago
jsteube	5951207365	Get rid of some old volatiles	6 years ago
jsteube	3e08750900	OpenCL Kernels: Add general function declaration keyword (static inline)	6 years ago
jsteube	503f676cb0	Remove static keywords from OpenCL functions, they can cause old NV JiT compiler to fail	7 years ago
jsteube	51dd982b12	Bring back some volatile for AMD	7 years ago
jsteube	9125062ffc	Move volatiles for AMD closer to the problem	7 years ago
jsteube	40b57677cd	OpenCL Kernels: Reactivate Dalibors XOR optimization on MD5_H on all MD5 based algorithms	7 years ago
jsteube	938c281ee0	Resurrect some volatile variables in order to correctly compile pure kernels on AMD drivers	7 years ago
jsteube	967e96728d	Make all the OpenCL kernel function includes static	7 years ago
jsteube	5e34ec348e	Optimize kernels for ROCm 1.6 ... - Remove inline keywords - Remove volatile keywords where it causes ROCm to slow down - Replace DES functions (looks like bitselect somehow is no longer mapped to BFI_INT)	7 years ago
jsteube	eae9329761	Workaround some AMD JiT compiler segfault on complex kernels	7 years ago
jsteube	7205f450dd	Backport more HMAC functions in inc_hash_xxx.cl from global to private	7 years ago
jsteube	c4098e2230	Fix invalid use of a non-vector function from within a vector function	7 years ago
jsteube	4e0972ce3a	Add xxx_update_vector_swap(), xxx_update_vector_utf16le_swap() and xxx_update_vector_utf16beN() for later use	7 years ago
jsteube	9c6c21490f	Add *_hmac_init_swap for later use	7 years ago
jsteube	9c12459852	Add HMAC vector functions to inc_hash_*	7 years ago
jsteube	c512e0c01a	Add example -L kernel for algorithms with appended salt in utf16le	7 years ago
jsteube	9b6c6df53d	Add xxx_nit_vector_from_scalar() to all inc_hash_xxx.cl includes	7 years ago
jsteube	8a6e3a5275	Add support in HMAC for passwords larger than block size of the underlaying hash	7 years ago
jsteube	f619811b70	Remove PBKDF2-HMAC-MD5 includes password length limit	7 years ago
philsmd	03f4e2b3dc	minor typo fixed in comment for the new update() functions	7 years ago
Jens Steube	56dc8ae359	Add two functions md5_update_global_utf16le_swap() and md5_update_global_swap() for later use	7 years ago
jsteube	165380c454	Simplify WPA/WPA2 cracking kernel	7 years ago
jsteube	120cf1d1ba	Removed some unused functions, added -m 500 kernel with length 256 support but not activated because too slow	7 years ago
jsteube	71d4926afa	Converted -m 400 to password length 256 support ... 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.	7 years ago