-
Notifications
You must be signed in to change notification settings - Fork 238
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
"OpenCL error -11 on line 164 of /home/user/git/clBLAS/src/library/blas/xgemm.cc" #172
Comments
thanks Hugh! This makes sense. I assume clBLAS was built with "OPENCL_VERSION=1.2" since you are running on a nvidia system. We did most of our test setting OPENCL_VERSION=2.0 (since it has better performance on AMD card) and thus let this bug through. I can probably make a fix for this. |
Alright. By the way, note that fixing this hides some other bugs:
Going through these bit by bit. Will submit a pull request once working. |
Actually, seems the superfluous kernel source is an artifact in my debugging somehow. However, the initializers do need to be fixed, in order to compiler on NVIDIA. |
I noticed you made a few pull requests to master branch. In the future when you make pull requests can you make them to develop branch? |
Well... I guess I'm thinking that 'master' branch represents 2.8.0, and 'develop' represents new features? Is that actually incorrect, and develop contains only bug fixes? I'd prefer to use a stable versoin of clBLAS in my own projects, ideally. |
we actually only "accept" pull requests to develop branch. Once a while the develop branch will be merged to master branch. It is just a work flow we like to follow. |
Please confirm that develop branch contains no new or original work or features, and contains only bug fixes. |
The opencl math library projects follow the 'git flow' scheme, in which all 'new' code should be committed into 'develop'. For critical bug-fixes, a we can cherry-pick commits and push out a new 'patch' (like 2.8.1) release. When making your commits into 'develop', it would help us if you isolate each bug fix into a single commit, so that we can cleanly cherry-pick each fix into 'master'. If your fork has many commits as you worked on bug-fixes, you can squash the commits into a minimal set first before you issue a PR with git rebase --interactive The problem with accepting code into 'master' branch is that code from 'master' never flows into 'develop' (it's a one-way valve). We risk losing changes the next time 'develop' merges into 'master', because if the merge is done carelessly the changes to 'master' will be overwritten by 'develop' which never had the fix. |
Well, you can create release branches, eg Edit: basically, I think your |
can we close this issue? |
Thanks! |
OpenCL error -11 on line 164 of /home/user/git/clBLAS/src/library/blas/xgemm.cc
Following test program, adapted from xgemm.cc sample, running on NVIDIA 940M:
Compile, and run, like this:
Expected output:
Actual output:
Note that there are some additional debugging lines here, most important of which are:
printf("special case 664\n");
printf("sourceBuildOptions %s\n", sourceBuildOptions);
It seems plausible that this problem is caused by the compile options for AutoGemmUserKernels being hard-coded as
-cl-std=2.0
, ie in file UserGemmKernelSourceIncludes.h , lines 12-13Probable future of this issue?
The text was updated successfully, but these errors were encountered: