Switched HIP version check from driverVersion to runtimeVersion
Fixed syntax check of HAS_VPERM macro in several kernel includes causing invalid error message for AMD GPUs on Windows
Updated AMD driver requirements
Updated docs/changes.txt with missing changes from previous commits
Fixed invalid vector data type in Murmur Hash in -a 3 mode
Fixed uninitialized variable warning in src/hashes.c
Fixed broken support for --generate-rules-func-min
Fix context to thread management
Fix missing code in selftest.c, autotune.c, hashes.c, dispatch.c and backend.c
Use IS_HIP depending code makes it easier for future optimization related to inline assembly calls - instead of using IS_CUDA || IS_HIP
See TODO markers for more optimizations / next steps
If module_hash_binary_parse is completely unable to successfully parse out
any hashes, up until now the output has been
```
Hashfile 'foo': Success
```
which is less than helpful.
This patch allows (but does not require) m_h_binary_parse to report a useful
error response, by returning a negative value. Modules which continue to
return '0 hashes' will get the same less-than-useful behaviour they always
hace.
I've also modified the LUKS module to report a useful error, as a proof of
concept.
Further expansions on this could include:
* Applying similar behaviour to module_hash_binary_count, so it too can
report errors when trying to count hashes. This would require more
co-ordinated change, because m_h_binary_count already uses -1 to indicate
a system error.
* Allow and encourage modules to print their own errors and warnings during
parsing. This would allow for situations where a single hash in a
multi-hash file could be reported as malformed, without having to fail the
whole parse. However, implementing this would, I expect, require modules
to have access to `hashcat_ctx`, which... yeah. Not so straightforward.