blueberry
commented
8 years ago Does the hello-world project from the example folder work on your machine?
Closed fonghou closed 8 years ago
blueberry
commented
8 years ago Does the hello-world project from the example folder work on your machine?
fonghou
commented
8 years ago Yes, hello-world example works.
copying those native libs to project root allow me to get pass the native LinkError. Now, trying to run an example,
(ns matrix.core (:require [uncomplicate.clojurecl.legacy :as gpu] [uncomplicate.commons.core :refer [with-release]] [uncomplicate.neanderthal [core :refer [asum dot axpy! mv! mm! transfer! copy]] [native :refer [sv sge]] [opencl :refer [with-default-engine clv clge]]] [criterium.core :refer [quick-bench with-progress-reporting]]))
(gpu/with-default-1 (with-default-engine (asum (sv 1 -2 3)))) ;; => 6.0. This works!
(gpu/with-default-1 (with-default-engine (with-release [gpu-x (transfer! (sv 1 -2 3) (clv 3))](asum gpu-x)))) ;; This doesn't work. Getting
CLBlast error: kKernellaunchError. {:name "kKernellaunchError", :code -2048, :type :clblast-error, :details "(enq-read-float queue res-buffer37983auto__)"}
core.clj: 4617 clojure.core/ex-info
core.clj: 4617 clojure.core/ex-info
clblast.clj: 60 uncomplicate.neanderthal.opencl.clblast/error
clblast.clj: -1 uncomplicate.neanderthal.opencl.clblast/error
clblast.clj: 58 uncomplicate.neanderthal.opencl.clblast.CLBlastSingleVectorEngine/asum
core.clj: 441 uncomplicate.neanderthal.core/asum
core.clj: 434 uncomplicate.neanderthal.core/asum
REPL: 17 matrix.core/eval38862
REPL: 14 matrix.core/eval38862
Compiler.java: 6927 clojure.lang.Compiler/eval
Compiler.java: 6890 clojure.lang.Compiler/eval
core.clj: 3105 clojure.core/eval
core.clj: 3101 clojure.core/eval
main.clj: 240 clojure.main/repl/read-eval-print/fn
main.clj: 240 clojure.main/repl/read-eval-print
main.clj: 258 clojure.main/repl/fn
main.clj: 258 clojure.main/repl
main.clj: 174 clojure.main/repl
RestFn.java: 1523 clojure.lang.RestFn/invoke
interruptible_eval.clj: 87 clojure.tools.nrepl.middleware.interruptible-eval/evaluate/fn
AFn.java: 152 clojure.lang.AFn/applyToHelper
AFn.java: 144 clojure.lang.AFn/applyTo
core.clj: 646 clojure.core/apply
core.clj: 1881 clojure.core/with-bindings*
core.clj: 1881 clojure.core/with-bindings*
RestFn.java: 425 clojure.lang.RestFn/invoke
interruptible_eval.clj: 85 clojure.tools.nrepl.middleware.interruptible-eval/evaluate
interruptible_eval.clj: 55 clojure.tools.nrepl.middleware.interruptible-eval/evaluate
interruptible_eval.clj: 222 clojure.tools.nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn
interruptible_eval.clj: 190 clojure.tools.nrepl.middleware.interruptible-eval/run-next/fn
AFn.java: 22 clojure.lang.AFn/runThreadPoolExecutor.java: 1142 java.util.concurrent.ThreadPoolExecutor/runWorker ThreadPoolExecutor.java: 617 java.util.concurrent.ThreadPoolExecutor$Worker/run Thread.java: 745 java.lang.Thread/run
blueberry
commented
8 years ago Can you please set up minimal project that does not work and put it on GitHub? That way I can try to reproduce the error on my machine, although I do not have a OpenCL enabled Mac, so I am not sure I'll succeed.
Before that, are you sure that your Mac supports OpenCL?
Can you try the following, and post the results here?
(use `uncomplicate.clojurecl.info)
(use `uncomplicate.clojurecl.core)
(map info (devices (first (platforms))))BTW, you seem to have made copy/paste error in the blue part of the code. It should be:
(with-release [gpu-x (transfer! (sv 1 -2 3) (clv 3))]
(asum gpu-x))or
(with-release [gpu-x (clv 1 -2 3]
(asum gpu-x))
amherag
commented
8 years ago Could this be a problem with the libraries I compiled?
El miércoles, 25 de mayo de 2016, Dragan Djuric notifications@github.com escribió:
BTW, you seem to have made copy/paste error in the blue part of the code. It should be:
(with-release [gpu-x (transfer! (sv 1 -2 3) (clv 3))](asum gpu-x))
or
(with-release [gpu-x (clv 1 -2 3](asum gpu-x))
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/uncomplicate/neanderthal/issues/15#issuecomment-221687052
fonghou
commented
8 years ago (map info (devices (first (platforms)))) output is very long. Here are snippets for each DeviceInfo (three objects). My Macbook System Info shows two graphic cards, Intel and NVIDIA. It seems Intel one shows up two times with different OpenCL driver-versions. All three DeviceInfo objects have lots CL_INVALID_VALUE entries.
(btw, [] in code was lost when copy/paste here. github markdown)
1) -----------------------------
2)-------------------------------------------------------
3)---------------------------------------------------------
blueberry
commented
8 years ago @amherag Can you please create a minimalistic OpenCL hello world project that works on mac and put it somewhere on github so @FongHou can try something that is tested on mac?
blueberry
commented
8 years ago Or, even better, I'll update examples/hello-world with a minimalistic OpenCL so @amherag can confirm it works, so it can be a starting point for you, @FongHou. Will be updated in a couple of minutes.
blueberry
commented
8 years ago @amherag @FongHou https://github.com/uncomplicate/neanderthal/tree/master/examples/hello-world now contains opencl1 and opencl2 examples that I tested on my AMD GPU. Please try this on mac and report the results here.
amherag
commented
8 years ago At core.clj
(def a (dge 2 3 [1 2 3 4 5 6]))
(def b (dge 3 2 [1 3 5 7 9 11]))
(mm a b)gives me:
#RealGeneralMatrix[double, ord:COL, mxn:2x2, ld:2]((35.0 44.0) (89.0 116.0))
so it works.
For opencl1.clj, I run:
(with-default-1 (with-default-engine (with-release [gpu-x (clv 1 -2 5)](asum gpu-x))))
and I get:
Unhandled clojure.lang.ExceptionInfo CLBlast error: kKernellaunchError. {:name "kKernellaunchError", :code -2048, :type :clblast-error, :details "(enq-read-float queue res-buffer28303auto__)"}
core.clj: 4617 clojure.core/ex-info
core.clj: 4617 clojure.core/ex-info
clblast.clj: 60 uncomplicate.neanderthal.opencl.clblast/error
clblast.clj: -1 uncomplicate.neanderthal.opencl.clblast/error
clblast.clj: 58 uncomplicate.neanderthal.opencl.clblast.CLBlastSingleVectorEngine/asum
core.clj: 441 uncomplicate.neanderthal.core/asum
core.clj: 434 uncomplicate.neanderthal.core/asum
REPL: 11 hello-world.opencl1/eval28480
REPL: 8 hello-world.opencl1/eval28480
Compiler.java: 6927 clojure.lang.Compiler/eval
Compiler.java: 6890 clojure.lang.Compiler/eval
core.clj: 3105 clojure.core/eval
core.clj: 3101 clojure.core/eval
main.clj: 240 clojure.main/repl/read-eval-print/fn
main.clj: 240 clojure.main/repl/read-eval-print
main.clj: 258 clojure.main/repl/fn
main.clj: 258 clojure.main/repl
main.clj: 174 clojure.main/repl
RestFn.java: 1523 clojure.lang.RestFn/invokeinterruptible_eval.clj: 87 clojure.tools.nrepl.middleware.interruptible-eval/evaluate/fn AFn.java: 152 clojure.lang.AFn/applyToHelper AFn.java: 144 clojure.lang.AFn/applyTo core.clj: 646 clojure.core/apply core.clj: 1881 clojure.core/with-bindings core.clj: 1881 clojure.core/with-bindings RestFn.java: 425 clojure.lang.RestFn/invoke interruptible_eval.clj: 85 clojure.tools.nrepl.middleware.interruptible-eval/evaluate interruptible_eval.clj: 55 clojure.tools.nrepl.middleware.interruptible-eval/evaluate interruptible_eval.clj: 222 clojure.tools.nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn interruptible_eval.clj: 190 clojure.tools.nrepl.middleware.interruptible-eval/run-next/fn AFn.java: 22 clojure.lang.AFn/run ThreadPoolExecutor.java: 1142 java.util.concurrent.ThreadPoolExecutor/runWorker ThreadPoolExecutor.java: 617 java.util.concurrent.ThreadPoolExecutor$Worker/run Thread.java: 745 java.lang.Thread/run
Okay! I remember getting the same yesterday, but I naïvely assumed that the problem was that I was trying to run something on the GPU, but with-default-1 was getting the first device, which is the CPU (I don't know if this is what happens, but when I inspect the first device, it lists my CPU). So, a quick hack I did was get the source code for with-default-1, change (first (devices)) to (second (devices)) for my Intel Iris, or (nth (devices) 2) for my Radeon. I end up with the following code:
(with-platform (first (platforms))
(let [dev# (second (devices))]
(with-context (context [dev#])
(with-queue (command-queue-1 dev#)
(with-default-engine
(with-release [gpu-x (clv 1 -2 5)]
(asum gpu-x)))))))And gives 8.0 as a result. Try running this @FongHou.
I hope this helps you all to find the problem.
blueberry
commented
8 years ago I'll change with-default-1 to try to get the best device in the next
version, in the same way that with-default does.
However, since the configuration might be different on each machine, with devices of different cappabilities, the best way is to explicitly choose the device you want to use, instead of using the defaults. There are plenty of such functions in ClojureCL and Neanderthal's opencl namespace.
For example, you can use with-default-1 as a quick template, but filtering only gpu devices:
(with-platform (first (platforms))
(let [dev (first (sort-by-cl-version (devices :gpu)))]
(with-context (context [dev])
(with-queue (command-queue-1 dev)
;; do your calculations here
)))))@FongHou I updated hello-world with the second example in opencl1
fonghou
commented
8 years ago @blueberry Thank you very much for setting an example for me!
I still had to copy native libs to project root, like this... (now I understood this is a seperate issue, either with lein, or jocl-blast jar).
Now this works.
(with-platform (first (platforms))
(let [dev (first (sort-by-cl-version (devices :gpu)))]
(with-context (context [dev])
(with-queue (command-queue-1 dev)
(with-default-engine
(with-release [gpu-x (clv 1 -2 5)]
(asum gpu-x))))))) ;; => 8.0As you suspected, this didn't.
(with-default-1
(with-default-engine
(with-release [gpu-x (clv 1 -2 5)]
(asum gpu-x))))Thanks again for the troubleshooting. Amazing library BTW.
Regards
fonghou
commented
8 years ago ls -l hello-world
~/d/g/n/e/hello-world ❯❯❯ ll master ◼ total 5288 -rw-r--r-- 1 houf staff 11K May 25 14:09 LICENSE -rw-r--r-- 1 houf staff 231B May 25 14:09 README.md -rw-r--r-- 1 houf staff 311K May 25 19:16 libJOCLBlast_0_7_1-apple-x86_64.dylib -rw-r--r-- 1 houf staff 176K May 25 19:16 libJOCL_2_0_0-apple-x86_64.dylib -rw-r--r-- 1 houf staff 2.1M May 25 19:16 libclblast.dylib -rw-r--r-- 1 houf staff 238B May 25 14:09 project.clj drwxr-xr-x 3 houf staff 102B May 25 14:09 src drwxr-xr-x 5 houf staff 170B May 25 19:23 target
blueberry
commented
8 years ago regarding native libraries: maybe with your initial trials you messed up something in the system. Please try to erase jocl libraries trom the tmp folder (i don't know where that is on mac), or simply reboot the machine for them to be cleaned up, clone a fresh, clean hello world, and then try again.
fonghou
commented
8 years ago Tried reboot a few times, even in safe mode, with no luck. leiningen native libraries handling seems known complicated.
https://github.com/technomancy/leiningen/issues/1961
Close the issue for now.
Thanks!
blueberry
commented
8 years ago @amherag Can you please try to remove libclblast.dylib from your machine (if you installed it as a part of clblast build process with sudo make install), and to delete it from the tmp folder (or reboot the machine), so we can be sure that it is properly packed in the jar and available to other users?
amherag
commented
8 years ago It fails.
blueberry
commented
8 years ago Hmmm. Can you try JOCL and JOCLBlast from Java and see whether it works? Then we'll know whether it's a leiningen issue or a JOCL/JOCLBlast issue.
blueberry
commented
8 years ago On Linux it works properly, even when I remove libclblast globally...
amherag
commented
8 years ago I loaded it in a Java source file. Can you give me an example to run?
blueberry
commented
8 years ago amherag
commented
8 years ago Library not loaded: libclblast.dylib
I'll recompile today and look for the problem.
blueberry
commented
8 years ago OK. Thanks. If it might be an issue with JOCLBlast's library loading (there was one previously on linux). Don't bang your head too much on it, just make sure you gather the right data and isolate the problem so we can open an issue in JOCLBlast and ask @gpu for help. Relevant JOCLBlast issue https://github.com/gpu/JOCLBlast/issues/3
gpu
commented
8 years ago Admittedly, I did not read this whole issue discussion (or rather: did not understand large parts of it, due to lack of background knowledge). But if I understood this correctly: The example that blueberry linked to causes an UnsatisfiedLinkError on Mac, where the core of the message is
Library not loaded: libclblast.dylib Referenced from: ... libJOCLBlast_0_7_1-apple-x86_64.dylib
Reason: image not foundThat's a new one for me. (I summarized different sorts of UnsatisfiedLinkErrors in the JCuda FAQ, but this is not one of them).
Websearches for "Library not loaded" "Reason: image not found" bring some results, but I just had a short look.
(And just to be sure, @amherag The JOCLBlast example also fails on your machine? So this is likely a general issue with the dependent library loading on Mac?)
amherag
commented
8 years ago Yes, the JOCLBlast example fails on my machine. I keep thinking that it's weird to store the library on apple/x86_64 (the apple/ part). This is correct, right? I place the libclblast.dylib in that directory, compile JOCLBlast, and it packages it, but Mac doesn't seem to load it.
gpu
commented
8 years ago I'm not sure what you mean by "weird" in this case. The intention is to have the possibility to disambiguate between the dependencies for different OSes and architectures. For example, the linux/x86_64 directory contains the libJOCLBlast.so. There may also be another OS (Solaris or whatever) where the library is also called libJOCLBlast.so, so they can't be in the same directory, and the linux/ (or solaris/) subdirectory allows looking up the right native library based on the OS.
However, although this may now in fact turn out to be an issue of JOCLBlast (and not neanderthal), I'm curious what's going wrong there. The following is a test that tweaks the logger of the LibUtils a bit (I'll have to make this more easily controllable), and which should cause some log messages about the library loading sequence to be printed:
import java.util.logging.ConsoleHandler;
import java.util.logging.Level;
import java.util.logging.Logger;
import org.jocl.blast.CLBlast;
public class LibTest {
public static void main(String[] args) {
Logger logger = Logger.getLogger("org.jocl.LibUtils");
logger.setLevel(Level.FINEST);
ConsoleHandler consoleHandler = new ConsoleHandler();
logger.addHandler(consoleHandler);
consoleHandler.setLevel(Level.FINEST);
CLBlast.setExceptionsEnabled(true);
System.out.println("Done");
}
}
It should indicate whether the libraries are loaded, and in which order they are loaded.
For example, the output (here, in my office, with a slightly out-dated version) is
Mai 30, 2016 12:33:11 PM org.jocl.LibUtils loadLibrary
FEIN: Loading library as a resource
Mai 30, 2016 12:33:11 PM org.jocl.LibUtils loadLibraryResource
FEIN: Library JOCLBlast_0_7_0-windows-x86_64 depends on clblast
Mai 30, 2016 12:33:11 PM org.jocl.LibUtils loadLibraryResource
FEIN: Loading library C:\...\Temp\JOCLBlast_0_7_0-windows-x86_64_dependents\windows\x86_64\clblast.dll
Mai 30, 2016 12:33:11 PM org.jocl.LibUtils loadLibraryResource
FEIN: Loading library C:\...\Temp\JOCLBlast_0_7_0-windows-x86_64_dependents\windows\x86_64\clblast.dll DONE
Mai 30, 2016 12:33:11 PM org.jocl.LibUtils loadLibraryResource
FEIN: Loading library C:\...\Temp\JOCLBlast_0_7_0-windows-x86_64.dll
Mai 30, 2016 12:33:11 PM org.jocl.LibUtils loadLibraryResource
FEIN: Loading library C:\...\Temp\JOCLBlast_0_7_0-windows-x86_64.dll DONE
Mai 30, 2016 12:33:11 PM org.jocl.LibUtils loadLibrary
FEIN: Loading library as a resource DONE
Doneshowing that it does first load the clblast.dll and then the JOCLBlast....dll. Similarly, it should load the libclblast.dylib on MacOS, before loading the JOCLBlast....dylib. (There may still things go wrong, this is only intended to figure out the root cause for the error...)
amherag
commented
8 years ago Ignore that thing I said. I'm ignorant regarding how the libraries are loaded. I was thinking something like maybe the directory name should be "osx", but then I thought that maybe you coded JOCLBlast to specifically read "apple/" when OS X was detected, and then I felt dumb. As I said, I'm a complete ignorant regarding this.
I'll run your logger tomorrow. I have to sleep now.
gpu
commented
8 years ago That's not dumb. I thought you wondered why the directory was there at all, as this is also not immediately obvious. But in fact, the string apple is indeed somewhat arbitrarily chosen - it could also have been "macos" or so. But the OS detection was based on a blog post (now only available in the web archive: https://web.archive.org/web/20090731124422/http://javablog.co.uk/2007/05/19/making-jni-cross-platform ) where it was called apple, and that's where this came from...
amherag
commented
8 years ago May 30, 2016 11:20:04 PM org.jocl.LibUtils loadLibrary
FINE: Loading library: JOCLBlast_0_7_1-apple-x86_64
May 30, 2016 11:20:04 PM org.jocl.LibUtils loadLibrary
FINE: Loading library as a file
May 30, 2016 11:20:04 PM org.jocl.LibUtils loadLibrary
FINE: Loading library as a file FAILED
May 30, 2016 11:20:04 PM org.jocl.LibUtils loadLibrary
FINE: Loading library as a resource
May 30, 2016 11:20:04 PM org.jocl.LibUtils loadLibraryResource
FINE: Library JOCLBlast_0_7_1-apple-x86_64 depends on clblast
May 30, 2016 11:20:04 PM org.jocl.LibUtils loadLibraryResource
FINE: Loading library /var/folders/vv/0tqwxzw520l6lbdvdfbvq1dm0000gn/T/JOCLBlast_0_7_1-apple-x86_64_dependents/apple/x86_64/libclblast.dylib
May 30, 2016 11:20:04 PM org.jocl.LibUtils loadLibraryResource
FINE: Loading library /var/folders/vv/0tqwxzw520l6lbdvdfbvq1dm0000gn/T/JOCLBlast_0_7_1-apple-x86_64_dependents/apple/x86_64/libclblast.dylib DONE
May 30, 2016 11:20:04 PM org.jocl.LibUtils loadLibraryResource
FINE: Loading library /var/folders/vv/0tqwxzw520l6lbdvdfbvq1dm0000gn/T/libJOCLBlast_0_7_1-apple-x86_64.dylib
May 30, 2016 11:20:04 PM org.jocl.LibUtils loadLibrary
FINE: Loading library as a resource FAILED
Exception in thread "main" java.lang.UnsatisfiedLinkError: Error while loading native library "JOCLBlast_0_7_1-apple-x86_64"
Operating system name: Mac OS X
Architecture : x86_64
Architecture bit size: 64
---(start of nested stack traces)---
Stack trace from the attempt to load the library as a file:
java.lang.UnsatisfiedLinkError: no JOCLBlast_0_7_1-apple-x86_64 in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1867)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
at java.lang.System.loadLibrary(System.java:1122)
at org.jocl.LibUtils.loadLibrary(LibUtils.java:136)
at org.jocl.blast.CLBlast.<clinit>(CLBlast.java:53)
at LibTest.main(LibTest.java:14)
Stack trace from the attempt to load the library as a resource:
java.lang.UnsatisfiedLinkError: /private/var/folders/vv/0tqwxzw520l6lbdvdfbvq1dm0000gn/T/libJOCLBlast_0_7_1-apple-x86_64.dylib: dlopen(/private/var/folders/vv/0tqwxzw520l6lbdvdfbvq1dm0000gn/T/libJOCLBlast_0_7_1-apple-x86_64.dylib, 1): Library not loaded: libclblast.dylib
Referenced from: /private/var/folders/vv/0tqwxzw520l6lbdvdfbvq1dm0000gn/T/libJOCLBlast_0_7_1-apple-x86_64.dylib
Reason: image not found
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1824)
at java.lang.Runtime.load0(Runtime.java:809)
at java.lang.System.load(System.java:1086)
at org.jocl.LibUtils.loadLibraryResource(LibUtils.java:269)
at org.jocl.LibUtils.loadLibrary(LibUtils.java:151)
at org.jocl.blast.CLBlast.<clinit>(CLBlast.java:53)
at LibTest.main(LibTest.java:14)
---(end of nested stack traces)---
at org.jocl.LibUtils.loadLibrary(LibUtils.java:185)
at org.jocl.blast.CLBlast.<clinit>(CLBlast.java:53)
at LibTest.main(LibTest.java:14)It loads the library that it depends on (obviously), but then has some obscure problem when trying to load the actual library. Websearch results like http://stackoverflow.com/questions/19776571/error-dlopen-library-not-loaded-reason-image-not-found don't seem to say more than "yeah, MacOS works in mysterious ways" - that's annoying, to say the least.
I have no idea how this could be solved. I could try to dig through things like http://log.zyxar.com/blog/2012/03/10/install-name-on-os-x/ (found via http://stackoverflow.com/questions/6711908/dlopen-error-image-not-found ), but since I have no idea what this "install path" stuff should be, and can't test it on a Mac, this won't be very constructive.
I guess the goal of writing a library that was easy to use on any platform may just have been too ambituous. There are simply too many c....y kludges out there, and one likely has to create kludges to be compatible with the rest of the world. So if everything else fails, I'll just link CLBlast statically. One more kludge won't harm ;-)
blueberry
commented
8 years ago @gpu May I suggest that you set the process to do statc complation on OS X but leave dynamic libraries on linux and windows?
gpu
commented
8 years ago It's probably not worth to add another condition/special case here. It would be easier and more straightforward to compile it the same way for all OSes (even though I consider the solution with static linking as less-than-ideal. I think It would be nicer to have the separate libraries (CLBlast and JOCLBlast) compiled separately. "On the surface" (for the user of the JAR), the difference will not be noticable at all, but it would be nicer from a "conceptual" point of view).
I'd also really like to know what went wrong here on Mac, and what this "install name" thing is all about. I hardly can imagine that it's not possible to ... simply load libraries on MacOS .... unless they are "installed" with a path that is stored in the library itself!? That just seems odd. From what I've read in http://log.zyxar.com/blog/2012/03/10/install-name-on-os-x/ and https://wincent.com/wiki/@executable_path,_@load_path_and_@rpath , playing with something like
SET(CMAKE_INSTALL_NAME_DIR @loader_path/apple/x86_64)might work (or at least, bring some insights), but I can't test this, and I'd like to avoid having another release that does not work properly on Mac....
blueberry
commented
8 years ago Hey, but in this case I think @amherag might help! If you make the necessary changes, he can build the snapshot library and try whether it loads after cleaning up clblast.
amherag
commented
8 years ago Just tell me what to do. I have free time today.
blueberry
commented
8 years ago @amherag I hope @gpu makes the changes today so you can test it, but we have to wait and see.
gpu
commented
8 years ago Unfortunately, I know too few details to really give targeted advice here, and I won't blindly commit changes to the CMake files of which I don't even have an idea of whether they might work. If I had a Mac here, I'd first have a look at what
otool -D libclblast.dyliband
otool -D libJOCLBlast_0_7_1-apple-x86_64.dylibsay about these "install names" of the dylib. Then I'd check whether
otool -L libJOCLBlast_0_7_1-apple-x86_64.dylibprints a dependency that resembles the path that was printed with the first otool call, for the libclblast.dylib.
Pragmatically, I would also just try out adding
set(CMAKE_INSTALL_NAME_DIR @loader_path)at the top of https://github.com/gpu/JOCLCommon/blob/master/CMakeLists.txt , as this was proposed as one possible solution. It might also have to be
set(CMAKE_INSTALL_NAME_DIR @loader_path/apple/x86_64)(Note that this would only be experiments, to try it out and see how it could be made working at all).
There are further resources that I (would) have to read, e.g. https://cmake.org/Wiki/CMake_RPATH_handling , but again: Without the possibility to try this out, all this involves a lot of guesswork....
BTW, @amherag : Did you run an
mvn clean installin the JOCL and JOCLBlast directories after building the natives (as described in the README of https://github.com/gpu/JOCL )? There is a "unit test" that should be run, and wonder why it didn't fail in your case. (It's not really a unit test - it just tests the basic bindings, to see whether the library can be found)
amherag
commented
8 years ago Results :
Tests in error:
JOCLBlastBasicBindingTest.testJOCLBlast:20 » UnsatisfiedLink Error while loadi...
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0It now fails. Maybe because I deleted /usr/local/lib/libclblast.dylib?
amherag
commented
8 years ago otool -D libclblast.dylib:
libclblast.dylib:
libclblast.dylibotool -D libJOCLBlast_0_7_1-apple-x86_64.dylib:
/Users/Amherag/Downloads/jocl-0.7.1/JOCLBlast-0.7.1-RC00/nativeLibraries/libJOCLBlast_0_7_1-apple-x86_64.dylib
I also tried adding set(CMAKE_INSTALL_NAME_DIR @loader_path) and set(CMAKE_INSTALL_NAME_DIR @loader_path/apple/x86_64) but in the end mvn clean install fails with the same error.
I can read the RPATH resource you mentioned and try some things.
gpu
commented
8 years ago That would be great. Again, I can only guess how this could be tackled.
And sorry: My "suggestion" about setting
set(CMAKE_INSTALL_NAME_DIR @loader_path/apple/x86_64)in the JOCL CMake does not make sense. It finds the JOCL library, but not the CLBlast library.
Referring to the information that you posted, I'm not sure how to interpret the fact that for libclblas.dylib, the otool call prints only the file name, whereas for the libJOCLBlast...dylib, it prints some whole path....
However, I just looked at https://github.com/CNugteren/CLBlast/blob/master/CMakeLists.txt#L31 and it contains the following settings:
# RPATH settings
set(CMAKE_SKIP_BUILD_RPATH false) # Use, i.e. don't skip the full RPATH for the build tree
set(CMAKE_BUILD_WITH_INSTALL_RPATH false) # When building, don't use the install RPATH already
set(CMAKE_INSTALL_RPATH "") # The RPATH to be used when installing
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH false) # Don't add the automatically determined partsOne has to assume that these may be relevant here, and could explain why for CLBlast, only the file name is printed. (Note that I don't know whether this is "correct" or not - it's only an observation until now...)
If I had a Mac (and some more time), I'd try to read more about these settings, maybe play around with them. I still have to figure out how the CMAKE_INSTALL_NAME_DIR and the CMAKE_INSTALL_RPATH are related, but wonder what effects it has to simply set everything to false or to the empty string "" here.
In doubt, it could be interesting to ask https://github.com/CNugteren/ about the intentions behind these settings. AFAIK he also does not really use a Mac, so maybe this was also only added to "get something running based on an issue report and related websearch results" (something that I certainly have been guilty of as well...)
(Some other related resource is https://www.semipol.de/2012/02/16/relative-rpath-settings-with-cmake.html , but I'm not sure how relevant it is - I still have to wrap my head around all this...)
gpu
commented
8 years ago One debugging step could also be to simply remove the "RPATH settings" from the CLBlast makefiles, and see whether the default behavior is OK. It is still not entirely clear (for me) what these lines should accomplish.
gpu
commented
8 years ago There has been an update for CLBlast regarding the RPATH settings: https://github.com/CNugteren/CLBlast/commit/7a7873d5527e7819249f80ba9abceb9d2d9c41cb - maybe @amherag can try out whether this helps to solve this issue?
blueberry
commented
8 years ago @amherag you can try this without waiting for new neanderthal. Just repack the newly build clblast binary into the existing JOCLBlast 0.7.1 jar and if it works, then we can build a new official version.
amherag
commented
8 years ago I will do it today. Sorry, I was busy, but now I have some free time.
El lunes, 6 de junio de 2016, Dragan Djuric notifications@github.com escribió:
@amherag https://github.com/amherag you can try this without waiting for new neanderthal. Just repack the newly build clblast binary into the existing JOCLBlast 0.7.1 jar and if it works, then we can build a new official version.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/uncomplicate/neanderthal/issues/15#issuecomment-223992143, or mute the thread https://github.com/notifications/unsubscribe/AAYq5wwGD4K8rw8GRpLeWx1j5AM6bPLGks5qJDsSgaJpZM4ImtEo .
amherag
commented
8 years ago Success! Well, kinda. I ran the example provided at https://forum.byte-welt.net/byte-welt-projekte-projects/jocl/18180-joclblas-java-bindings-clblas-2.html#post131422 and this is the output:
CL_DEVICE_NAME: Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz
Exception in thread "main" org.jocl.CLException: CL_INVALID_WORK_ITEM_SIZE
at org.jocl.blast.CLBlast.checkResult(CLBlast.java:98)
at org.jocl.blast.CLBlast.CLBlastSgemm(CLBlast.java:3919)
at JOCLBlastSample.main(JOCLBlastSample.java:82)I got an exception, but no Library not loaded: libclblast.dylib
I'm attaching the updated joclblast jar. Should I run more tests?
blueberry
commented
8 years ago Can you please choose other device, just to be sure? Just change the device from 0 to 1 or 2. As far as I can tell, this problem is solved. The archive you attached is probably not needed (the lib is 0.7.1, and for release, Marco will need 0.7.2), but I guess that the next release of CLBlast will come soon, so then we can release all three then.
In the meantime, a good idea would be to tune CLBlast for your Nvidia K80 and send it to Cedric so your server would work with the optimized binaries. I think it is not in the Cedric's tuning database yet.
blueberry
commented
8 years ago And, thanks a lot for help with this :)
amherag
commented
8 years ago I changed final int deviceIndex = 0; to final int deviceIndex = 2;, and I got this error:
CL_DEVICE_NAME: Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz
Exception in thread "main" org.jocl.CLException: CL_INVALID_DEVICE
at org.jocl.CL.checkResult(CL.java:808)
at org.jocl.CL.clCreateCommandQueue(CL.java:5005)
at JOCLBlastSample.defaultInitialization(JOCLBlastSample.java:168)
at JOCLBlastSample.main(JOCLBlastSample.java:29)The same happens with device 1.
Oh, and I will be tuning CLBlast with the Nvidia K80 for the next release.
gpu
commented
8 years ago @amherag Great - thanks for trying this out!
The remaining error messages are ... well, at least not related to this original issue.
It says that the device is an Intel CPU. Do you have a GPU (AMD or NVIDIA) installed as well? If so, you might have to change the platformIndex (and not the deviceIndex ) in the sample. In doubt, you could run http://jocl.org/samples/JOCLDeviceQuery.java : It will list all available platforms and devices.
blueberry
commented
8 years ago @gpu @amherag Now I remember that there was a bug in that Java sample. deviceIndex is used in a couple places, BUT at one or two places it is hardcoded as 0. You should change that hardcoded value too.
Hello,
First, sorry about the long post.
Here are my lein project.clj and a sample namespace. When loading it from lein repl, got a stacktrace list below.
(defproject matrix "0.1.0-SNAPSHOT" :dependencies [[org.clojure/clojure "1.8.0"] [com.taoensso/truss "1.2.0"] [uncomplicate/clojurecl "0.6.4"] [uncomplicate/fluokitten "0.5.0"] [uncomplicate/neanderthal "0.6.2"]]
:profiles {:dev {:dependencies [[criterium "0.4.4"]]} :uberjar {:aot :all}} )
(ns matrix.core (:require [uncomplicate.clojurecl.core :as cl] [uncomplicate.commons.core :refer [with-release]] [uncomplicate.neanderthal [core :refer [asum dot axpy! mv! mm! transfer! copy]] [native :refer [sv sge]] [opencl :refer [with-default-engine clv clge]]] [criterium.core :refer [quick-bench with-progress-reporting]]))
The interesting one is the nested cause:
Stack trace from the attempt to load the library as a resource: java.lang.UnsatisfiedLinkError: /private/var/folders/xm/vkg11d9n74ngq3zsbjlms04w0000gn/T/libJOCLBlast_0_7_1-apple-x86_64.dylib: dlopen(/private/var/folders/xm/vkg11d9n74ngq3zsbjlms04w0000gn/T/libJOCLBlast_0_7_1-apple-x86_64.dylib, 1): Library not loaded: libclblast.dylib Referenced from: /private/var/folders/xm/vkg11d9n74ngq3zsbjlms04w0000gn/T/libJOCLBlast_0_7_1-apple-x86_64.dylib
ls -lR that folder /private/var/... shows required dylib are there, but layout looks strange. Not sure this is leinignen issue or not.
/p/v/f/x/v/T ❯❯❯ ls -lR JOCL -rw-r--r-- 1 houf staff 318908 May 25 10:50 libJOCLBlast_0_7_1-apple-x86_64.dylib -rw-r--r-- 1 houf staff 180064 May 23 19:34 libJOCL_2_0_0-apple-x86_64.dylib
JOCLBlast_0_7_1-apple-x86_64_dependents: total 0 drwxr-xr-x 3 houf staff 102 May 25 10:50 apple
JOCLBlast_0_7_1-apple-x86_64_dependents/apple: total 0 drwxr-xr-x 3 houf staff 102 May 25 10:50 x86_64
JOCLBlast_0_7_1-apple-x86_64_dependents/apple/x86_64: total 4272 -rw-r--r-- 1 houf staff 2184612 May 25 10:50 libclblast.dylib
============Full Stacktrace ============== CompilerException java.lang.UnsatisfiedLinkError: Error while loading native library "JOCLBlast_0_7_1-apple-x86_64" Operating system name: Mac OS X Architecture : x86_64 Architecture bit size: 64 ---(start of nested stack traces)--- Stack trace from the attempt to load the library as a file: java.lang.UnsatisfiedLinkError: no JOCLBlast_0_7_1-apple-x86_64 in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1867) at java.lang.Runtime.loadLibrary0(Runtime.java:870) at java.lang.System.loadLibrary(System.java:1122) at org.jocl.LibUtils.loadLibrary(LibUtils.java:136) at org.jocl.blast.CLBlast.(CLBlast.java:53)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at clojure.lang.RT.classForName(RT.java:2168)
at clojure.lang.RT.classForName(RT.java:2177)
at clojure.lang.Compiler$HostExpr.maybeClass(Compiler.java:1030)
at clojure.lang.Compiler.macroexpand1(Compiler.java:6807)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6854)
at clojure.lang.Compiler.analyze(Compiler.java:6669)
at clojure.lang.Compiler.analyze(Compiler.java:6625)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:6001)
at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6319)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6868)
at clojure.lang.Compiler.analyze(Compiler.java:6669)
at clojure.lang.Compiler.analyze(Compiler.java:6625)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:6001)
at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5380)
at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3972)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6866)
at clojure.lang.Compiler.analyze(Compiler.java:6669)
at clojure.lang.Compiler.eval(Compiler.java:6924)
at clojure.lang.Compiler.load(Compiler.java:7379)
at clojure.lang.RT.loadResourceScript(RT.java:372)
at clojure.lang.RT.loadResourceScript(RT.java:363)
at clojure.lang.RT.load(RT.java:453)
at clojure.lang.RT.load(RT.java:419)
at clojure.core$load$fn5677.invoke(core.clj:5893)
at clojure.core$load.invokeStatic(core.clj:5892)
at clojure.core$load.doInvoke(core.clj:5876)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invokeStatic(core.clj:5697)
at clojure.core$load_one.invoke(core.clj:5692)
at clojure.core$load_lib$fn5626.invoke(core.clj:5737)
at clojure.core$load_lib.invokeStatic(core.clj:5736)
at clojure.core$load_lib.doInvoke(core.clj:5717)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invokeStatic(core.clj:648)
at clojure.core$load_libs.invokeStatic(core.clj:5778)
at clojure.core$load_libs.doInvoke(core.clj:5758)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invokeStatic(core.clj:648)
at clojure.core$require.invokeStatic(core.clj:5796)
at clojure.core$require.doInvoke(core.clj:5796)
at clojure.lang.RestFn.invoke(RestFn.java:482)
at uncomplicate.neanderthal.opencl$eval37781$loading5569auto__37782.invoke(opencl.clj:1)
at uncomplicate.neanderthal.opencl$eval37781.invokeStatic(opencl.clj:1)
at uncomplicate.neanderthal.opencl$eval37781.invoke(opencl.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:6927)
at clojure.lang.Compiler.eval(Compiler.java:6916)
at clojure.lang.Compiler.load(Compiler.java:7379)
at clojure.lang.RT.loadResourceScript(RT.java:372)
at clojure.lang.RT.loadResourceScript(RT.java:363)
at clojure.lang.RT.load(RT.java:453)
at clojure.lang.RT.load(RT.java:419)
at clojure.core$load$fn__5677.invoke(core.clj:5893)
at clojure.core$load.invokeStatic(core.clj:5892)
at clojure.core$load.doInvoke(core.clj:5876)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invokeStatic(core.clj:5697)
at clojure.core$load_one.invoke(core.clj:5692)
at clojure.core$load_lib$fn5626.invoke(core.clj:5737)
at clojure.core$load_lib.invokeStatic(core.clj:5736)
at clojure.core$load_lib.doInvoke(core.clj:5717)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invokeStatic(core.clj:648)
at clojure.core$load_libs.invokeStatic(core.clj:5778)
at clojure.core$load_libs.doInvoke(core.clj:5758)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invokeStatic(core.clj:648)
at clojure.core$require.invokeStatic(core.clj:5796)
at clojure.core$require.doInvoke(core.clj:5796)
at clojure.lang.RestFn.invoke(RestFn.java:457)
at matrix.core$eval20272$loading5569auto__20273.invoke(form-init3071421537802120931.clj:1)
at matrix.core$eval20272.invokeStatic(form-init3071421537802120931.clj:1)
at matrix.core$eval20272.invoke(form-init3071421537802120931.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:6927)
at clojure.lang.Compiler.eval(Compiler.java:6916)
at clojure.lang.Compiler.eval(Compiler.java:6890)
at clojure.core$eval.invokeStatic(core.clj:3105)
at clojure.core$eval.invoke(core.clj:3101)
at clojure.main$repl$read_eval_print7408$fn7411.invoke(main.clj:240)
at clojure.main$repl$read_eval_print7408.invoke(main.clj:240)
at clojure.main$repl$fn7417.invoke(main.clj:258)
at clojure.main$repl.invokeStatic(main.clj:258)
at clojure.main$repl.doInvoke(main.clj:174)
at clojure.lang.RestFn.invoke(RestFn.java:1523)
at clojure.tools.nrepl.middleware.interruptible_eval$evaluate$fn__941.invoke(interruptible_eval.clj:87)
at clojure.lang.AFn.applyToHelper(AFn.java:152)
at clojure.lang.AFn.applyTo(AFn.java:144)
at clojure.core$apply.invokeStatic(core.clj:646)
at clojure.core$with_bindingsSTAR.invokeStatic(core.clj:1881)
at clojure.core$with_bindingsSTAR.doInvoke(core.clj:1881)
at clojure.lang.RestFn.invoke(RestFn.java:425)
at clojure.tools.nrepl.middleware.interruptible_eval$evaluate.invokeStatic(interruptible_eval.clj:85)
at clojure.tools.nrepl.middleware.interruptible_eval$evaluate.invoke(interruptible_eval.clj:55)
at clojure.tools.nrepl.middleware.interruptible_eval$interruptible_eval$fn986$fn989.invoke(interruptible_eval.clj:222)
at clojure.tools.nrepl.middleware.interruptible_eval$run_next$fn__981.invoke(interruptible_eval.clj:190)
at clojure.lang.AFn.run(AFn.java:22)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Stack trace from the attempt to load the library as a resource:
java.lang.UnsatisfiedLinkError: /private/var/folders/xm/vkg11d9n74ngq3zsbjlms04w0000gn/T/libJOCLBlast_0_7_1-apple-x86_64.dylib: dlopen(/private/var/folders/xm/vkg11d9n74ngq3zsbjlms04w0000gn/T/libJOCLBlast_0_7_1-apple-x86_64.dylib, 1): Library not loaded: libclblast.dylib
Referenced from: /private/var/folders/xm/vkg11d9n74ngq3zsbjlms04w0000gn/T/libJOCLBlast_0_7_1-apple-x86_64.dylib
Reason: image not found
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1824)
at java.lang.Runtime.load0(Runtime.java:809)
at java.lang.System.load(System.java:1086)
at org.jocl.LibUtils.loadLibraryResource(LibUtils.java:269)
at org.jocl.LibUtils.loadLibrary(LibUtils.java:151)
at org.jocl.blast.CLBlast.(CLBlast.java:53)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at clojure.lang.RT.classForName(RT.java:2168)
at clojure.lang.RT.classForName(RT.java:2177)
at clojure.lang.Compiler$HostExpr.maybeClass(Compiler.java:1030)
at clojure.lang.Compiler.macroexpand1(Compiler.java:6807)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6854)
at clojure.lang.Compiler.analyze(Compiler.java:6669)
at clojure.lang.Compiler.analyze(Compiler.java:6625)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:6001)
at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6319)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6868)
at clojure.lang.Compiler.analyze(Compiler.java:6669)
at clojure.lang.Compiler.analyze(Compiler.java:6625)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:6001)
at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5380)
at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3972)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6866)
at clojure.lang.Compiler.analyze(Compiler.java:6669)
at clojure.lang.Compiler.eval(Compiler.java:6924)
at clojure.lang.Compiler.load(Compiler.java:7379)
at clojure.lang.RT.loadResourceScript(RT.java:372)
at clojure.lang.RT.loadResourceScript(RT.java:363)
at clojure.lang.RT.load(RT.java:453)
at clojure.lang.RT.load(RT.java:419)
at clojure.core$load$fn 5677.invoke(core.clj:5893)
at clojure.core$load.invokeStatic(core.clj:5892)
at clojure.core$load.doInvoke(core.clj:5876)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invokeStatic(core.clj:5697)
at clojure.core$load_one.invoke(core.clj:5692)
at clojure.core$load_lib$fn5626.invoke(core.clj:5737)
at clojure.core$load_lib.invokeStatic(core.clj:5736)
at clojure.core$load_lib.doInvoke(core.clj:5717)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invokeStatic(core.clj:648)
at clojure.core$load_libs.invokeStatic(core.clj:5778)
at clojure.core$load_libs.doInvoke(core.clj:5758)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invokeStatic(core.clj:648)
at clojure.core$require.invokeStatic(core.clj:5796)
at clojure.core$require.doInvoke(core.clj:5796)
at clojure.lang.RestFn.invoke(RestFn.java:482)
at uncomplicate.neanderthal.opencl$eval37781$loading5569auto__37782.invoke(opencl.clj:1)
at uncomplicate.neanderthal.opencl$eval37781.invokeStatic(opencl.clj:1)
at uncomplicate.neanderthal.opencl$eval37781.invoke(opencl.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:6927)
at clojure.lang.Compiler.eval(Compiler.java:6916)
at clojure.lang.Compiler.load(Compiler.java:7379)
at clojure.lang.RT.loadResourceScript(RT.java:372)
at clojure.lang.RT.loadResourceScript(RT.java:363)
at clojure.lang.RT.load(RT.java:453)
at clojure.lang.RT.load(RT.java:419)
at clojure.core$load$fn5677.invoke(core.clj:5893)
at clojure.core$load.invokeStatic(core.clj:5892)
at clojure.core$load.doInvoke(core.clj:5876)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invokeStatic(core.clj:5697)
at clojure.core$load_one.invoke(core.clj:5692)
at clojure.core$load_lib$fn5626.invoke(core.clj:5737)
at clojure.core$load_lib.invokeStatic(core.clj:5736)
at clojure.core$load_lib.doInvoke(core.clj:5717)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invokeStatic(core.clj:648)
at clojure.core$load_libs.invokeStatic(core.clj:5778)
at clojure.core$load_libs.doInvoke(core.clj:5758)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invokeStatic(core.clj:648)
at clojure.core$require.invokeStatic(core.clj:5796)
at clojure.core$require.doInvoke(core.clj:5796)
at clojure.lang.RestFn.invoke(RestFn.java:457)
at matrix.core$eval20272$loading5569auto__20273.invoke(form-init3071421537802120931.clj:1)
at matrix.core$eval20272.invokeStatic(form-init3071421537802120931.clj:1)
at matrix.core$eval20272.invoke(form-init3071421537802120931.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:6927)
at clojure.lang.Compiler.eval(Compiler.java:6916)
at clojure.lang.Compiler.eval(Compiler.java:6890)
at clojure.core$eval.invokeStatic(core.clj:3105)
at clojure.core$eval.invoke(core.clj:3101)
at clojure.main$repl$read_eval_print7408$fn7411.invoke(main.clj:240)
at clojure.main$repl$read_eval_print7408.invoke(main.clj:240)
at clojure.main$repl$fn7417.invoke(main.clj:258)
at clojure.main$repl.invokeStatic(main.clj:258)
at clojure.main$repl.doInvoke(main.clj:174)
at clojure.lang.RestFn.invoke(RestFn.java:1523)
at clojure.tools.nrepl.middleware.interruptible_eval$evaluate$fn941.invoke(interruptible_eval.clj:87)
at clojure.lang.AFn.applyToHelper(AFn.java:152)
at clojure.lang.AFn.applyTo(AFn.java:144)
at clojure.core$apply.invokeStatic(core.clj:646)
at clojure.core$with_bindingsSTAR.invokeStatic(core.clj:1881)
at clojure.core$with_bindingsSTAR.doInvoke(core.clj:1881)
at clojure.lang.RestFn.invoke(RestFn.java:425)
at clojure.tools.nrepl.middleware.interruptible_eval$evaluate.invokeStatic(interruptible_eval.clj:85)
at clojure.tools.nrepl.middleware.interruptible_eval$evaluate.invoke(interruptible_eval.clj:55)
at clojure.tools.nrepl.middleware.interruptible_eval$interruptible_eval$fn986$fn989.invoke(interruptible_eval.clj:222)
at clojure.tools.nrepl.middleware.interruptible_eval$run_next$fn__981.invoke(interruptible_eval.clj:190)
at clojure.lang.AFn.run(AFn.java:22)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
---(end of nested stack traces)---
, compiling:(uncomplicate/neanderthal/opencl/clblast.clj:461:3)