New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Successful compile doesn't work macosx-x86-64-opencl #50
Comments
I am forwarding this to the john-dev mailing list. To me it seems you magnum -------- Original Message -------- Downloaded from the OpenWall site and making the unsigned int / uint
which resuts in:
And if this helps here is the device list:
Reply to this email directly or view it on GitHub: |
modding the paths removed the errors about path, but still getting the 'results in:' stuff. so I'm guessing there are two unrelated issues. |
OK so the path issue is fixed and does not need fixing in our tree (I'm The "Error -54" is a bug: It should give you a human-readable error. The root cause has been known since April but no-one has apparently done Hopefully, it will be fixed before Jumbo-7 (within weeks). Thank you for magnum
|
Please try cloning the new branch "1.7.9-jumbo-6-fixes" and see if it solves your problems, and report back! Thanks, |
I didn't make any mods to the Makefile (not sure if you wanted me to), so this is straight from the pull (still had the path issues but it built):
|
Thank you. You are [currently] supposed to edit the Makefile so it reflects the OpenCL paths your system is using. magnum |
I suspect this format needs OpenCL 1.1 conformance (or at least support for byte_addressable_store) as of now, and it seems your GPU only supports OpenCL 1.0. If this is it, you will unfortunately have to wait longer for a fix. |
Claudio posted a fix. Please try latest commit from "1.7.9-jumbo-6-fixes", hopefully it will work better |
Definitely fixed for my CPU using OpenCL 1.1, I think I'm SOL for my GPU though (as you say wait longer for a fix) |
After Claudio's fixes I believe we can fix it sooner rather than later. Can you please do this:
|
Now I'm getting errors for both CPU and GPU :(
GPU:
I'm on the John-dev list now and will post this same reply there. |
Mubix - I have hit the same issue. OpenCL error (CL_INVALID_PROGRAM_EXECUTABLE) you're getting is probably because the build options are unsupported for your OpenCL setup. Because of the error in OpenCL error handling, you're getting wrong OpenCL error. I've managed to track my problem to the build options (both specified are unsupported on my platform). Take a look at the pull requests I've made (76 - fix error handling, 77 - fix build options): In any case, I would recommend trying out my fork (with these two fixed implemented): If it will not fix your problems, at least you will have more info about the error you're getting. So, pinpointing the problem would be easier. |
Here's the output:
|
As I thought. It was not problem in executing nt_kernel (CL_INVALID_PROGRAM_EXECUTABLE), but in the process of building nt_kernel.cl (CL_BUILD_PROGRAM_FAILURE). On the other hand, other part of the problem is not the same as mine. From what I see, your problem is in clBuildProgram call (build_kernel function in common-opencl.c). As I don't have same card as you it's hard for me to play with it. But, if you have some spare time. I would suggest following:
Hope it helps! |
trying some other opencl based formats (raw-md5-opencl, raw-sha1-opencl, ...) and reporting if you have same errors
removing comments from common-opencl.c in function include_source:
upgrading OpenCL implementation (CL_BUILD_PROGRAM_FAILURE with empty Compilation log usually means bug in CL compiler), i.e. try with MacOSX10.7.sdk if you have some older version currently
intelligently commenting out parts of nt_kernel.cl and finding out offending line/statement
|
Now, just please another output: CL_LOG_ERRORS=stderr ./john --test=3 --format=nt-opencl --device=1 |
|
Can you build any other GPU stuff? Like some kind of OpenCL hello-world? |
compiles and worked perfectly. would you like me to try another? |
No, that's fine. Just so we don't look in the wrong place for problems. I will likely get myself a Macbook Pro within weeks - with some luck this will help solving a number of OSX problems. Though normally I will likely run Linux on it. |
From my limited experience with OpenCL, we're down to the issue:
From my experience, there's lot of problems with double/float handling, but in given .cl files there's no such things. Maybe you can try commenting out various code in offending .cl file in order to find offending line or function. Sorry, I'm really out of ideas :-/ |
Wow. Just wow. I just tried all OpenCL formats under OSX 10.8.1. Not a single one works on GPU. Every single one fails just like the one discussed here. Apple's driver/framework apparently does not conform to the same ideas that the rest of the world. Using the CPU device, most or all seems fine. The good news is I will fix this sooner or later, now that I can see for myself! |
Welcome to the MacFanboy-nation |
Probably, it depends on graphic card. As I have been successful in running john opencl stuff on MacBook Pro with AMD Radeon HD 6750M. I guess, it is nvidia in question for both of you? |
Yes, nvidia. Like mubix, I can build and run a hello world opencl program just fine. I strongly suspect the problem is some peculiarity with Apple+nvidia that we need to take account for / work around in common-opencl.c. The question is what... |
Huh. Then, I can't help too much, as I don't have access to any nvidia based. BTW could be something stupid like this: https://github.com/kost/magnum-jumbo/commit/cd9856c2ae412e871a2aacc130b37e6ffb138a62 |
Problem partly solved. A bunch of fixes is committed. Also, on my laptop I need to run gfxCardStatus and force discrete GPU (that would be a bug in OSX). All CUDA formats and maybe half of the OpenCL ones work fine now. I'll try to fix the rest. |
@magnumripper where can I get said magic? |
I've tested it (bleeding jumbo) and it works with ATI. So, nothing broken on that side with those bunch of fixes. On other hand, what makes me worry is that opencl is usually slower (on Mac and Linux): $ run/john --format=nt-opencl --test $ run/john --format=nt --test $ run/john --format=nt-opencl --device=1 --test I get similar discrepancy for raw-md5 as well :-/ |
@mubix if you mean gfxCardStatus, it's here: http://codykrieger.com/gfxCardStatus. @kost this applies to the fast raw formats, where the JtR "api" has bottlenecks. Work in progress. Slow formats like phpass or rar are much faster on GPU. We have the same problem with OMP - the raw formats does not even support it because it does not make them faster. |
I have a very odd clue: Since NT and raw-MD4 are very similar, I tried swapping their kernels to see if the problem moved. It did not. So apparently the problem is not in the kernel code. But I can't see what it would be then. Not much happen in the formats before the kernel is built. |
Scrap that. I'm too tired. The problem did move. So the problems are in the kernels. |
Is there anything I can do to help or test? |
Yeah, complain to Apple :) Seriously, I tried commenting out a super-trivial no-magics part of the NT kernel, and then it compiles fine (although obviously fails to crack hashes). To me this proves there isn't anything we can do about it other than wait for Apple to fix their über-crappy OpenCL :( In the meantime, download CUDA for OSX and run a CUDA build of JtR. All CUDA formats works fine (as long as you do not rely on dynamic GPU switching). |
CUDA 5 fixes the problem with kernel hangs in dynamic mode. I'm closing this now. All is not fine but many things are better now. Please open new issues for specific problems (other than that "Error getting function data from server" which is clearly due to Apple bugs). |
Downloaded from the OpenWall site and making the unsigned int / uint changes I was able to compile with the following errors:
which resuts in:
And if this helps here is the device list:
The text was updated successfully, but these errors were encountered: