RFE: opensource OpenCL support

[igor-raits]

Now we have support OpenCL for:

• CPU -> POCL
• Intel GPU -> Beignet
• AMD GPU -> mesa

Would be great to get opensource OpenCL support.

[jsteube]

Sorry, I don't understand what you mean, could you please rephrase?

[igor-raits]

Currently oclHashcat supports only AMD OpenCL SDK and CUDA, but we have OpenCL which is not part of those. I want to get support of it.

[jsteube]

I see, that is indeed interessting especially for the CPU part, but definitly a long-term suggestion.

[igor-raits]

I am not interested in CPU part, I'm mostly interested in beignet part, because it works on Intel GPUs which is mostly everywhere.

[epixoip]

Intel GPUs are not likely to be much if at all faster than CPU, which is one of the reasons we never bothered to support them.

[igor-raits]

It is faster (at least with beignet). https://01.org/beignet

[epixoip]

That link doesn't really say anything of value.

Let's look at it this way: current top-of-the-line Intel GPUs have up to 384 cores which run at up to 1100 Mhz, and lack instructions that help reduce instruction count for many hash functions (nothing similar to bitselect, bitalign, LOP3.LUT, etc.) So basically these will be almost identical in speed very low-end pre-Maxwell Nvidia GPUs.

For example, the Iris Pro 6200 would be about as fast as a GT 640, which yields a staggering 450 MH/s on raw MD5. And by "staggering," I mean that's 23 times slower than a GTX 970. And that's for their top of the line GPU, if you have something like an HD4200 then it would be more like 50 times slower than a GTX 970.

So this is why we've never cared about adding Intel GPU support. Even their fastest GPUs are about the same speed as high-end CPUs.

[magnumripper]

IMHO, regardless of Intel GPUs' current state there's really no reason for Hashcat not to "work" with just any OpenCL device. Instead you could just state that only AMD is actively "supported" and/or that the OpenCL code is optimized for AMD and YMMV.

So I think we should look into wrapping AMD-specific stuff (just guessing there is some) in #ifdef blocks and provide some alternative "generic" alternative. Once it builds and runs on nvidia (as an alternative to CUDA) it should also run fine on Iris or crappy AMD APU's - as well as on some really cool FPGA board with OpenCL abstraction layer...

I haven't looked much at the code base yet so I'm mostly assuming things here.

[jsteube]

You're right. Now that we're not forced any longer to ship binary kernels we could allow other platforms than AMD to run the OpenCL kernels. Sure, some of the optimizations wouldn't work. However I'm absolutely positive about this, especially as it would give us an easy start into support CPU as well. I'll look into this in some time, but would also would be happy on any help on it

[magnumripper]

In fact it might save you a lot of time and work if you (eventually) ditch all CUDA stuff and go all-in for OpenCL. Unless there are some clear cases where CUDA can be significantly faster?

[jsteube]

Yeah I'd like to do so, but the most important reason for using CUDA is that only with CUDA it's possible to cross-compile GPU code using nvcc's -arch option. So we'd have a strange situation in which we'd use OpenCL on Nvidia if the users chooses to use the JIT but for binary distribution we still need to use CUDA. That sounds very complicated. BTw, there was such an option back in earlier versions of NVidia OpenCL runtime, but it got dropped without any reason.

And yes there's also the reason with the performance:

a) While this is just speculation, it seems NV isn't really happy with OpenCL. It's obvious that they try to push CUDA instead of OpenCL, for business reasons.
b) I remember with driver change somewhere between 150.x and 200.x the speeds for the OpenCL began to drop by 15% without any reason or any change within the ptx. It's also speculation but I think they tried to artificially slow down OpenCL to make CUDA more interessting.

[jsteube]

It seems we have alot of good reasons to fully switch to OpenCL. I've tried that yesterday but it's more complicated than one would think in the first place. We need to get rid of all of our C++ code (which is mostly only overloaded functions) because NVidias OpenCL runtime does not support C++. But there's no way around, since so many other tasks depend on this change.

[magnumripper]

In JtR we use function-like macros for "overloading". Too bad the typeof keyword is not mandatory in OpenCL - that would have been perfect. Most drivers support it though (including AMD, nvidia and Apple) but Intel does not (well some of their drivers do).

[jsteube]

For those interessted in development: https://github.com/hashcat/oclHashcat/tree/GetRidOfCUDA