05-18-2012, 01:09 PM
- added with oclHashcat-plus-0.09b11
- added with oclHashcat-lite-0.10b45
The kernels are distributed in an "intermediate" format (aka IL). It cant be reversed to original C code but still its not a binary format that can be used for execution.
The JIT (just-in-time) compilers from both OpenCL and CUDA, which ship with the driver, compile the final byte-code out of the IL. This takes a few seconds per kernel but once its done the byte-code is cached (CUDA does it automatically, OpenCL not but we add a function to do the same as CUDA does).
This has some nice advantages:
- added with oclHashcat-lite-0.10b45
Code:
type: feature
file: kernels
desc: on AMD, switched from .kernel to .llvmir to reduce diskspace
type: feature
file: kernels
desc: on NV, switched from .cubin to .ptx to reduce diskspace
type: feature
file: kernels
desc: added kernel cache to avoid unnecessary recompilation
cred: m4tr1xThe kernels are distributed in an "intermediate" format (aka IL). It cant be reversed to original C code but still its not a binary format that can be used for execution.
The JIT (just-in-time) compilers from both OpenCL and CUDA, which ship with the driver, compile the final byte-code out of the IL. This takes a few seconds per kernel but once its done the byte-code is cached (CUDA does it automatically, OpenCL not but we add a function to do the same as CUDA does).
This has some nice advantages:
- Not 32/64 bit specific
- Less HDD space
- Smaller .7z
- Less problems with driver specific problems as we often see with Catalyst
- There is no more need to release a new oclHashcat-* in case a new driver optimization has been added. oclHashcat-* caches driver specific. If it recognizes a driver change it will rebuild thge byte-code from the IL, but using the new JIT from the new driver resulting in driver specific optimized byte-code.