undefined symbol: mem_fence about xrt

[zyom]

I forgot to mention that I'm working with the most recent sources from the git repository.

[kklmn]

Hello,
Please give the output of
...\tests\raycing\info_opencl.py
When it did work before, was it the same system?
Konstantin

[zyom]

Hello Konstantin,

I did not try opencel before because it was not required. But the powder sample necessarily needs opencl.

Here is the output of info_opencl.py

============================================================
OpenCL Platforms and Devices
============================================================
Platform - Name:  Portable Computing Language
Platform - Vendor:  The pocl project
Platform - Version:  OpenCL 2.0 pocl 0.13, LLVM 3.8.1
Platform - Extensions:  cl_khr_icd
Platform - Profile:  FULL_PROFILE
    --------------------------------------------------------
    Device - Name:  pthread-Intel(R) Xeon(R) CPU E3-1225 V2 @ 3.20GHz
    Device - Vendor:  GenuineIntel
    Device - Type:  3
    Device - Max Clock Speed:  3192 Mhz
    Device - Compute Units:  4
    Device - Local Memory:  3728352 KB
    Device - Constant Memory:  3728352 KB
    Device - Global Memory: 4 GB
    Device - FP:  6


<pyopencl.Context at 0x55ae66e3a0f0 on <pyopencl.Device 'pthread-Intel(R) Xeon(R) CPU E3-1225 V2 @ 3.20GHz' on 'Portable Computing Language' at 0x55ae66e39170>>

By the way I'm using the software inside a virtual machine because I was not able to get xrtGlow working on my windows machine. So I could also try to use another linux distribution if there is a preferred one.

Thanks for your assistance
Armin

[kklmn]

I've never worked with OpenCL in a virtual machine. I find it weird to seek for hardware acceleration in a virtualized solution. I don't even know if this should work.

As to the issue, I see your pocl is old. I see in their GitHub that mem_fence was implemented quite recently. You may have reasons to prefer pocl over Intel's CPU-only Runtime Packages but I would try the latter first.

As to the trouble with xrtGlow in Windows, please see one of the latest closed Issues. If in Anaconda, it's better to install pyopengl from the Gohlke's page. If in WinPython, you should install it by pip from it's standard pypi source. Don't know why this is so.

[yxrmz]

It is possible to run opencl applications in virtualbox, but you still have to install proper opencl driver. Download and install the Intel OpenCL runtime from https://software.intel.com/en-us/articles/opencl-drivers
The main advantage of opencl is low-level access to hardware, so don't expect good performance in virtual machine. It would be much better to run xrt in native environment, as Konstantin said, try the Gohlke opencl and opengl *.whl packages.
By the way, I had to update the XRD example versus recent changes in the automatic alignment and reflect procedures.

[zyom]

As to the issue, I see your pocl is old. I see in their GitHub that mem_fence was implemented quite recently. You may have reasons to prefer pocl over Intel's CPU-only Runtime Packages but I would try the latter first.

Yes the reason is lack of knowledge and that this is the default dependency for pyopencl in debian ;-). And I was not aware that there are different implementations of opencl. I have now installed the intel opencl drivers on my windows host and pyopencl from conda-forge. This way the xrd example works but is rather slow. It takes approximately 90s for one step to calculate. Can this be expected on my ~5 year old cpu or is there still something misconfigured.

Regarding xrtGlow on Windows I will try to use the Gohlke *.whl packages.

Thanks so far for your assistance

[yxrmz]

It takes approximately 90s for one step to calculate. Can this be expected on my ~5 year old cpu or is there still something misconfigured.

It's all about the double precision performance, the code calculates the reflectivities for each combination of HKL and takes the highest probable, so you could try to reduce the PowderSample.hkl for faster results (strictly speaking we should've used the Monte-Carlo discrimination here, but this would slow down the process dramatically. it's an easy fix after all, just let me know if you are interested in a bit more precise result for a price of overall performance).
For comparison, my numbers are the following: full tracing time 4.5s on Radeon R9 280x (1 TFLOPS FP64), 1.5s for powder diffraction only, 41s (38s) on i7-2600K, so 90 seconds look reasonable for an old CPU.

[mmnmjm]

I have implemented OpenCl as suggested in this issue.
Hardware of my PC: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz.
Software: Windows-7, Python 2.7.13, Qt 5.6.2, PyQt5 5.6, pyopencl 2018.1.1, OpenGL 3.1.1a1, xrt-git-23092018
I can run xrtQook and Glow. But if I select targetOpenCL=[1,0] or r"CPU" in my OE an additional beam is emitted from the source. The screen is shifted to this second beam and is completely off the beamline. Could it be that I have similar problems as `mentioned by yxrmz:

By the way, I had to update the XRD example versus recent changes in the automatic alignment and reflect procedures.

[yxrmz]

I can run xrtQook and Glow. But if I select targetOpenCL=[1,0] or r"CPU" in my OE an additional beam is emitted from the source. The screen is shifted to this second beam and is completely off the beamline.

Is this in the XRD example or it's something else?

[mmnmjm]

Meanwhile I have downloaded the last release xrt 1.3.2 and now it works.