#1131 closed defect (fixed)
OpencCl dialog does not open
Reported by: | butler | Owned by: | wojciech |
---|---|---|---|
Priority: | blocker | Milestone: | SasView 4.2.0 |
Component: | SasView | Keywords: | |
Cc: | Work Package: | SasView Bug Fixing |
Description
Testing 4.2beta on windows revealed that the OpenCL dialog does not open. Clicking: Fitting → OpenCL Options does absolutely nothing. It does not however cause any problem nor does it through any error that shows up in the log file and the program continues to work as normal.
This does mean however that we are never using GPUs since the default has them off I believe
Change History (19)
comment:1 Changed 6 years ago by tcbennun
comment:2 Changed 6 years ago by tcbennun
Meanwhile, I have (almost) the exact same problem in the v4.1.2 release — the first time OpenCL Options is clicked, I get the dialog, but with no options; after that, the dialog stops appearing completely. And as for the SasView Python shell, I get the latter error from the comment above.
comment:3 Changed 6 years ago by tcbennun
(I should probably note I'm doing all of this on Windows 10.)
comment:4 Changed 6 years ago by butler
This may need Wojciech when he gets back from vacation to look at the build machines.
comment:5 Changed 6 years ago by butler
- Owner set to wojciech
- Status changed from new to assigned
comment:6 Changed 6 years ago by butler
testing the Pull requests yields one further piece of information (which may or may not be useful?) It seems in fact that the pop up DOES work for machines that do not have GPU support showing only the "No OpenCl" Option. However clicking on test does not work. If the machine does support GPUs then nothing happens when clicking OpenCl Options. this was true for both the master build for win64 and the PR build for win64.
Looking into the SasView log, the line mentioned above by Torin is logged in 'both' cases, mainly:
WARNING : sas.sasgui.perspectives.fitting.gpu_options (gpu_options.pyc:172) :: Unable to import the pyopencl package. It may not have been installed. If you wish to use OpenCL, try running pip install --user pyopencl
Further, As Torin points out as well, running the 4.1.2 installer version 'does' seem to bring the pop up in all cases, but in all cases it only shows the "No OpenCl" option. Again clicking on test in either case produces nothing. However, the log file no longer shows any errors.
Finally, version 4.1.0 Does work at least on a GPU enabled machine and shows the various OpenCl options AND test will generate a test result window even if the "No OpenCl" option is chosen.
- Clearly something happened in the builds between 4.1.0 and 4.1.2. Could that have something to do with the default being set to No OpenCl?
- It looks like on top of that pyopencl may be missing from the current build machines?
comment:7 Changed 6 years ago by piotr
So it seems py2exe combined with conda and pyopencl on 64 bit windows is a recipe for trouble.
Hopefully it is fixed now by minor modification to setup_exe.py and dirty hack in local pyopencl distribution.
(The pkg_resources module returns correct path on win32 but not on win64, and pyopencl tries to work around it by using the __file__ attribute to figure out local include paths. This however, is not working with py2exe/pyinstaller created archives, and we have to use argv[0] instead.)
comment:8 Changed 6 years ago by butler
I apparently did not use the proper incantation for the comments in the PR on this ticket to get captured so reproducing my comments here manually:
After some more testing, I think the behavior may be by design. Here are the behaviors depending on the type of windows machine:
- On machines with GPUs and OpenCl, no errors are thrown in the log file and three options are presented: OpenCl on GPU, !OpenCL on CPU, and No OpenCl
- On machines without GPU but with OpenCl drivers, no errors are thrown in the log file and two options are presented: OpenCl on CPU and No OpenCl
- On Machines without GPU and without OpenCl , the error noted previously in this ticket that states that pyopencl cannot be imported and suggesting it may not have been installed — a bit misleading but fair enough, and only one "option" is presented which is the No OpenCl option.
In all cases however, clicking on test when No OpenCl option is clicked does nothing. This may be confusing since it did pop up some test results in the past. However I suspect that what has changed is that the old No OpenCl was actually running the CPU tests? and that now there is a new option of OpenCl on CPUs so that there is nothing different to test with No OpenCl? In this case it would only be DLLs I guess which would be being tested against themselves?
If this is true we should document this new behavior in some way. If that is the case (and this is not a new bug) then we can merge this PR and create a new ticket for the documentation. If on the other hand this behavior is actually part of the "open Cl dialog not working" bug I think we should leave this open till it is fixed?
comment:9 Changed 6 years ago by butler
Another observation from this tests that in all cases tried so far, whether using OpenCl with GPUs or CPUs the test show 58 out of 133 failing. This seems like a lot and in fact makes using GPUs impractical I think. Need to understand this a bit more.
comment:10 Changed 6 years ago by butler
While need to test on at least one other machine that showed the 58 failures previously, the latest PR build is now passing all model on my CPU only but with OpenCl running machine. If it passes the GPU machine I will consider the errors to be a non-problem anymore unless someone else finds a problem.
comment:11 Changed 6 years ago by butler
Indeed, the latest fiddle to the build server seems to have done the trick. On a windows 7 enterprise with an Intell HD4000 graphics card, all 134 models pass successfully both the GPU and CPU OpenCL.
No OpenCL still does nothing. Not clear if this is intentional but seems reasonable. Suggest we add a line to the pop up where it gives the WARNING .. this will take a few minutes. Something like:
NOTE: No tests will be attempted if NO OpenCL is checked
We can then call this fixed
comment:12 Changed 6 years ago by butler
comment:13 Changed 6 years ago by wojciech
I've managed to debug "No OpenCL" case it seems that it causes runtime error in sasmodels
sasmodels/sasmodels/kernelcl.py", line 156, in environment raise RuntimeError("SAS_OPENCL=None in environment") RuntimeError: SAS_OPENCL=None in environment
I think it is ok to leave the note on the sasview end to handle this error.
comment:14 Changed 6 years ago by richardh
For what it's worth, I have been building from the ticket-1131 branch on my Win7 machine, but sasview still refuses to show that I have any gpu, which has worked previously, indeed still does in my 4.2 beta installation.
17:33:07 - WARNING : sas.sasgui.perspectives.fitting.gpu_options: 175: Unable to import the pyopencl package. It may not have been installed. If you wish to use OpenCL, try running pip install —user pyopencl
I even re-installed all the dependencies and tried the pip install —use pyopencl. No doubt I'm missing something here …
How do I find a sasview windows installer for that branch?
comment:15 follow-up: ↓ 19 Changed 6 years ago by wojciech
@richardh please try https://jenkins.esss.dk/sasview/job/SasView_Win7_64bit_PullRequest/42/
comment:16 Changed 6 years ago by butler
when you say it still works with your 4.2 beta installation do you mean the one you downloaded from the jenkins site? or what you have been building from the 4.2.0 beta branch? If the later that would be interesting but suspect it is the former — suggesting a problem with your development environment not too dissimilar from the problem on the build system?
comment:17 Changed 6 years ago by butler
Looking at line 156 that is in fact the essence of the environment function in kernelcl.py. Basically if the Global variable ENV (from the SAS_OPENCL environment variable?) is "none"then trying to run an openCL method should fail. I guess that the tests are calling kernelcl.py now? As I recall the test are not running unit tests but checking the output of the OpenCL call to the DLL version of the function? If so than indeed "no OpenCL" cannot run any tests as it would be testing against itself. Thus this seems like the catch that was placed in the code to prevent tests running when there are not so "behaving as expected?"
What I still don't understand is why the message does not show up in the log…
comment:18 Changed 6 years ago by GitHub <noreply@…>
- Resolution set to fixed
- Status changed from assigned to closed
comment:19 in reply to: ↑ 15 Changed 6 years ago by richardh
Replying to wojciech:
@richardh please try https://jenkins.esss.dk/sasview/job/SasView_Win7_64bit_PullRequest/42/
The installer version works on Win7 for me, so my developer environment must have an issue, thanks.
The dialog works fine if I build the beta and run it from the repository root directory, so something is wrong with the install procedure (that said, in the code I can't find any logical reason for the dialog to fail without any logs).
The installer copies relevant DLLs from the active Python installation (e.g. for numpy, Python itself, etc.) The Windows package for pyopencl contains OpenCL.dll, but this is never copied.
Copying OpenCL.dll to the installed SasView program files causes the dialog to appear, but the only option is "No OpenCL", and the following log appears:
Opening the Python shell from within SasView and trying import pyopencl results in the following error:
Whereas before copying OpenCL.dll to the program files, the result is the following: