Opened 5 weeks ago

Last modified 26 hours ago

#1131 assigned defect

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


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 (12)

comment:1 Changed 5 weeks ago by tcbennun

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:

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

Opening the Python shell from within SasView and trying import pyopencl results in the following error:

>>> import pyopencl
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "pyopencl\__init__.pyc", line 30, in <module>
  File "pyopencl\_cl.pyc", line 12, in <module>
  File "pyopencl\_cl.pyc", line 10, in __load
ImportError: DLL load failed: The specified module could not be found.

Whereas before copying OpenCL.dll to the program files, the result is the following:

>>> import pyopencl
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "pyopencl\__init__.pyc", line 30, in <module>
AttributeError: 'module' object has no attribute '_cl'
Last edited 4 weeks ago by butler (previous) (diff)

comment:2 Changed 5 weeks 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.

Last edited 4 weeks ago by butler (previous) (diff)

comment:3 Changed 5 weeks ago by tcbennun

(I should probably note I'm doing all of this on Windows 10.)

comment:4 Changed 4 weeks ago by butler

This may need Wojciech when he gets back from vacation to look at the build machines.

comment:5 Changed 2 weeks ago by butler

  • Owner set to wojciech
  • Status changed from new to assigned

comment:6 Changed 7 days 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?
Last edited 7 days ago by butler (previous) (diff)

comment:7 Changed 6 days 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 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 4 days 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 4 days 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.

Last edited 2 days ago by butler (previous) (diff)

comment:10 Changed 2 days 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 36 hours 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 26 hours ago by butler

In 388aefbfe7862efae1f1595105c7a8b53bb3e8e3/sasview:

Add warning to OpenCL dialog

Add note that "No OpenCL" will not run tests and put WARNING of it
taking a few minutes to run tests in red Addresses #1131

Note: See TracTickets for help on using tickets.