Adds fetching of particle addresses API to OpenCL implementation #130
Conversation
…ptions via the generated cl.h file
- adds feature flags, pairs of key-value strings that can be translated into compiler options for the OpenCL runtime compiler - adds handling for the default compiler options stored in the Controller
…e new feature handling macros
… compile option handling - removes "enable/disable" beam-beam tracking boolean flag - this is now handled as a combination of the SIXTRL_TRACK_BEAMBEAM4D and SIXTRL_TRACK_BEAMBEAM6D feature flags - adds a skip beam-beam tracking setter - uses feature flags for all compiler option generation - properly uses the default compiler options - exposes the default compiler options to C99 api
…ed C99 methods Python
… to the ClController python implementation
…o opencl_kernel_info.py
…NCHED into TRACK_SPACECHARGE
… TRACK_SC_BUNCHED into TRACK_SPACECHARGE
…oblems during a merge
…NCHED into TRACK_SPACECHARGE
…CubData) - adds two functions to return the object type for these two elements - these are used to keep the object id's sync between the python and C/C++ implementation - adds two functions that return the offeset relative to the begin of the elements of the src and dest addresses for the assignment item. These will replace the hard-coded values in the Python implementation of tricub.py and hopefully make this more robust
…reciated NS(OpenCL_get_available_node_id_strs_detailed) API
…lNodeId to no longer rely on the depreciated NS(OpenCL_get_available_node_id_strs_detailed) API - Note: The conversion of a ptr to a NS(ComputeNodeId) to a node id str is now done once via a staticmethod in the ClNodeId class rather than duplicated throughout the code. this will have to be changed once the NS(NodeId) implemmentation is used for both CUDA and OpenCL!
…tation - uses the C API to set the type id and the src/dest addr offset for these two elements. this should hopefully make the whole thing more robust in case something changes and is a kind of test run on how to handle other address assignment items
… TRACK_SC_BUNCHED into TRACK_SPACECHARGE
…tring method for ClNodeId
Kparasch master
Kparasch master
-- Note: changed to use black -l 79 instead of autopep8 to be compatible with the linter script in pysixtrack
This reverts commit e72860a.
python/sixtracklib: fixes wrong calculated offset to TriCubData element
…thon - adds two helper functions to stcommon which encode and decode python (unicode) strings to bytes strings compatible with ctypes.c_char_p - Avoid explicit encoding / decoding in all parts of python/sixtracklib and use the helper functions instead - re-apply the linter after reformating and simplyfing the source code
…ure/pr130_opencl_particle_addr
…e address in test
|
merged PR #130 with PR #132 to allow integration once #132 lands. Passes all tests on my workstation. |
|
When compiling with CUDA support on, I get the following error upon import: import sixtracklib
File ".../sixtracklib/python/sixtracklib/__init__.py", line 12, in <module>
from .beam_elements import *
File ".../sixtracklib/python/sixtracklib/beam_elements.py", line 15, in <module>
from .stcommon import (
File ".../sixtracklib/python/sixtracklib/stcommon.py", line 8, in <module>
sixtracklib = ct.CDLL(stconf.SHARED_LIB)
File ".../anaconda3/envs/stl_pr130/lib/python3.7/ctypes/__init__.py", line 356, in __init__
self._handle = _dlopen(self._name, mode)
OSError: .../sixtracklib/python/sixtracklib/libsixtrack.so: undefined symbol: __cudaRegisterLinkedBinary_64_tmpxft_00023082_00000000_6_be_monitors_assign_out_buffer_cpp1_ii_54dd6e05 |
|
Besides the CUDA import thing, everything works for me -- both the full SIS100 setup with 'Bunched' and 'Interpolated' mode of space charge as well as the new feature of sharing memory addresses in an openCL trackjob and writing to them from the python level via numpy exposed buffers (just as in your new example mentioned above, just within the SIS100 setup)! |
|
Thanks for testing, I'm trying to reproduce the problem with the CUDA API |
…kJob by changing initialisation order
|
Fixed two minor issues that should however not be the cause for your problem. On my machine (CUDA 10.1), the symbol in question is indeed exported via Stupid question: have you re-run cmake .. before attempting to install? |
|
Indeed, issue #109 is the explanation -- I had a cmake v3.16.3 due to the host OS ubuntu 20.04! When explicitly installing cmake v3.14.4 via pip, the compilation and import in python works flawlessly. Thanks and sorry for the hassle from my side! |
- The flag CUDA_RESOLVE_DEVICE_SYMBOLS should be enabled by default on shared libraries like SixTrackLib. The property does not work on OBJECT libraries like sixtrack_cuda_device. It seems that starting with cmake 3.15, cmake did not pick up the property for the resulting compound SHARED library just by inferring the dependency on the CUDA device part. This fix attempts to rectify this by adding the property explicitly to the SHARED sixtracklib library if the sixtrack_cuda_device target is present. Tested on CMake 3.14, 3.16 und 3.18 -> seems to work - Note: this would fix issue SixTrack#109 but more investigation is required whether this solves all problems encountered therein
|
@aoeftiger Could you please verify whether the updated PR (especially after commit 1ce557c) would solve the issue with CMake newer than 3.14 for you as well? |
|
Very nice! 1ce557c does solve the issue, I can compile and import in python including the CUDA support without a problem using the system cmake v3.16.3!! Thanks @martinschwinzerl !! |
|
Merged into PR #132 ->close |
Adds API to the track job specialization for OpenCL to fetch the start address of the fields in the Particles instance and allows to directly interact with the data. Cf.
examples/python/opencl_cpu_particle_addr.pyfor an example of using this APINote: the example is currently only expected to work with CPU devices. There is currently no implementation available to setup pyopencl from the host side to share the particle data via this addresses. libraries implementing the data sharing on the device side in their own kernels would work, though.