tests link to clfft
Issue #1
new
hi, because I couldn't get the example from the landing page to run (received segfault), I ran
$ ./build.sh --test=on
the cmake build of the tests stops because it can't find clFFT.h. This is under a rocm 1.1.1 kernel (4.4.0-kfd-compute-rocm-rel-1.1.1-10) with ubuntu 14.04.4 and a Fiji Nano. I was under the impression that this kernel does not support OpenCL! is that not true?
second, why do the tests contain a dependency to a package which is not listed here: http://hcfft.readthedocs.io/en/latest/Prerequisites.html
Best, Peter
Comments (10)
-
-
reporter
interesting, well at least that is one proof more that OpenCL will fly on ROCM in the near future ... which would be awesome (and a game changer from my perspective)!!
Until then, I recommend trying to use fftw if possible. I have used fftw for quite a while now and know that it's sometimes not easy to handle.
-
reporter
so how do you suggest to proceed? FWIW, if I download this library and see that there are tests, I will always run them. If they fail, I'm quite surprised and demotivated.
-
we are currently in the process of cleaning this up
-
reporter
is there any plan to drop the script interface as well? I had a look at clean.sh and build.sh, I am almost certain that most of this stuff can be done by cmake or code alone.
-
Cmake would be a good option. Since the target for HCC is solely linux, scripting is a good option too. If you suggest to move the cmake way, we could
-
reporter
I'd be strongly in favor of doing so. It'll make the package more accessible and thus more open for contributions. Further, it will encourage trust in good software engineering practices on your side. From personal experience, I am always a bit hesitant if I'm asked to install packages that have to be build with shell scripts. Also, it would help you to check automatically if you are on a system that actually has opencl/clfft installed. This would prevent you from having frustrated users that do not have OpenCL available on their ROCm platform as they are not affiliated to AMD.
-
Agreed !!. Will look into it
-
@psteinb One reason why we went ahead with shell script is due to the use of non native CC and CXX compiler viz clang++ For configuring later versions of cmake to change the default compiler, the only workable option I have experienced so far is to use
cmake -DCMAKE_CXX_COMPILER=<pathtoclang++> (But its a pain for the user right ?)
else leads to infinite looping . I am trying out the solution suggested at https://cmake.org/pipermail/cmake/2009-November/033133.html but in vain
do you have any ideas ?
-
reporter
I believe this is doable. I could invest 1-2 hours until ISC16 to help get this started. Unfortunately my fork of hcfft is a bit in an ill-posed state (my fault). If my PR could be merged, I'd refork and start with a cmake-only feature branch. as you currently know that you rely on the ROCm/ROCr infrastructure, the choice of compilers is rather limited. therefor, I'd simply set the C++ and C compilers to the correct ones under /opt/rocm inside the top CMakeLists.txt
- Log in to comment
We could still install clFFT over ROCM runtime. There is an internal tailor made opencl runtime which may not be released in public yet. Yeah got lot of things to clean up in Wiki
One way we tried aprroaching was to use FFTW to validate the unit tests but seems it was showing some hiccups