Closed hughperkins closed 8 years ago
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:
kernel source
which makes compilation failGoing 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.
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 2.8
, 2.9
, and apply fixes to those, which are immediately merged to develop. No master required, and merge is always in direction [some relesae branch]
=> develop
. When you create the next release, you simply fork develop to eg 2.9
or 3.0
.
Edit: basically, I think your master
should be removed. Your develop
should be renamed to master
, and each release should have a release branch, as above.
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?