Hi Marco,

It seems that MlOpen has been supporting OpenCL for some time now, and there appear to be libraries that use it more or less successfully.

I know that supporting so many libraries is quite a burden for you, and you'd probably be cautious before adding the support for another one. OTOH, deep learning is very important right now, and having a cuDNN alternative in OpenCL for the AMD platform might give JOCL a much needed appreciation from Java community.

Of course, I would like to help with that as much as I can. Although the tools and the process to create the initial support are only available to you, the least I can do is create bindings to my Clojure libraries, test it, and dig out as many bugs as I can.

Is there a chance that you'd consider supporting MIOpen?

@gpu What do you do for code signing on mac
Not a jocl problem but (works just fine on my m1 mac) but jnr-ffi does not work
see jnr/jnr-ffi#257
Can you advise?

Hi,

With the maturity of Panama Foreign-Function and Memory API now official in java 22, are there future plans JOCL and of course JCUDA to utilise it? I've seen it eliminates the need of distributing native libraries in jars and encourages java modules, etc. with enhanced performance and safety. Additionally, I haven't tested the JExtract Tool yet to generate java bindings, but I saw someone succeed in developing Vulkan API (albeit tested for Mac only) using it with high degree of success.

Thanks for the amazing library. work flawlessly on desktop and android phones.
But this is not able to work on google pixel phones, these pixels have libOpenCL-pixel.so that needs to be loaded.

tnn also had some problems with pixel and this could be a reference issue for how to fix this issue
Tencent/TNN#398

According to the OpenCL specification for the clEnqueueMapBuffer function:

If the buffer object is created with CL_MEM_USE_HOST_PTR set in mem_flags, the following will be true:

• The host_ptr specified in clCreateBuffer is guaranteed to contain the latest bits in the region being mapped when the clEnqueueMapBuffer command has completed.
• The pointer value returned by clEnqueueMapBuffer will be derived from the host_ptr specified when the buffer object is created.

Although JOCL supports pointers to Java arrays (as far as reasonably possible), it is not clear whether this particular application pattern works as expected.

The goal of this issue is to

• Check whether it works
• If it does not work, make it work
• If it can not be made work, prevent it (e.g. by throwing an exception when CL_MEM_USE_HOST_PTR is used with a pointer to a Java array)

About a month ago, OpenCL 3.0 has been released: https://www.khronos.org/registry/OpenCL/

There should be a new release of JOCL for OpenCL 3.0.

_{Unfortunately, I cannot (yet) give a timeline for that, as there are several other pending tasks.}

3 element vectors are required since OpenCL 1.1.

This error has occurred to me while running various JOCL samples and my own code. I've deleted the lines that did the assertion, but the error still persisted afterwards. I have also restarted my computer after deleting the lines, and the same error occurred after restart. After uninstalling Visual Studio 2019 and thus all of the include files of MSCV including xtree, running the program causes this error. I wonder if the problem is somehow related to Eclipse? It is important to note that the kernel seems to run okay; its just this annoying error message pops up whenever I run the host program.

Scanning dependencies of target JOCLCommon
[ 8%] Building CXX object JOCLCommon/CMakeFiles/JOCLCommon.dir/src/main/native/Logger.cpp.o
[ 16%] Building CXX object JOCLCommon/CMakeFiles/JOCLCommon.dir/src/main/native/CLJNIUtils.cpp.o
In file included from /home/linker/gits/JOCLCommon/src/main/include/CL/opencl.h:47:0,
from /home/linker/gits/JOCLCommon/src/main/native/JOCLCommon.hpp:45,
from /home/linker/gits/JOCLCommon/src/main/native/CLJNIUtils.hpp:31,
from /home/linker/gits/JOCLCommon/src/main/native/CLJNIUtils.cpp:31:
/home/linker/gits/JOCLCommon/src/main/include/CL/cl.h:1363:21: error: ‘CL_EXT_PREFIX__VERSION_1_2_DEPRECATED’ does not name a type
extern CL_API_ENTRY CL_EXT_PREFIX__VERSION_1_2_DEPRECATED cl_command_queue CL_API_CALL
^
/home/linker/gits/JOCLCommon/src/main/include/CL/cl.h:1370:21: error: ‘CL_EXT_PREFIX__VERSION_1_2_DEPRECATED’ does not name a type
extern CL_API_ENTRY CL_EXT_PREFIX__VERSION_1_2_DEPRECATED cl_sampler CL_API_CALL
^
/home/linker/gits/JOCLCommon/src/main/include/CL/cl.h:1377:21: error: ‘CL_EXT_PREFIX__VERSION_1_2_DEPRECATED’ does not name a type
extern CL_API_ENTRY CL_EXT_PREFIX__VERSION_1_2_DEPRECATED cl_int CL_API_CALL
^
JOCLCommon/CMakeFiles/JOCLCommon.dir/build.make:86: recipe for target 'JOCLCommon/CMakeFiles/JOCLCommon.dir/src/main/native/CLJNIUtils.cpp.o' failed
make[2]: *** [JOCLCommon/CMakeFiles/JOCLCommon.dir/src/main/native/CLJNIUtils.cpp.o] Error 1
CMakeFiles/Makefile2:122: recipe for target 'JOCLCommon/CMakeFiles/JOCLCommon.dir/all' failed
make[1]: *** [JOCLCommon/CMakeFiles/JOCLCommon.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

In my program i am calling org.jocl.CL.clEnquequeNDRangeKernelNative multiple times. JVM crashes after some number of iteration. As i said, after running for a while it crashes. It crashes with a EXCEPTION_ACCESS_VIOLATION.

Any ideas on how to debug this? At least i want to know what is thrown in native frame. Should i go for minidumps?

Now that the development is more open on github, and the library is quite important to other software that is based on it, it seems to me that the current version scheme could be improved.

I guess that Marco's idea is that minor JOCL versions follow OpenCL versions, so, for example JOCL 0.2.0 supports Opencl 2.0, 0.2.1 is targeted to OpenCL 2.1 etc.

The problem is that there might be (and indeed, ARE) minor bugfixes and development improvements, especially in the development phase, but also once the library is released. In the current scheme, this is solved by adding RC suffix, and then, on top of that, SNAPSHOT, which is not common. Usually, snapshot is for daily builds, and RC is for later stages, when the frozen release is finally tested in the wild.

I think that the major version should follow OpenCL, and then minor bugfix version can be used for incremental improvements.

In that scheme, JOCL 2.0.x would target OpenCL 2.0 standard, and could support much quicker bugfix releases. JOCL 2.1.x would target OpenCL 2.1 etc.

This might not be critical, but I think would enable much clearer development synchronization, and would enable seamless incremental bugfix releases even after the final JOCL release.

I have some scala code that puts the contents of an iterator into OpenCL device memory. If I do this in parallel on the Intel CPU OpenCL implementation it segfaults most of the time. I have reduced it down to the following code:

import org.jocl.CL._
import org.jocl._
import java.nio.ByteOrder
import java.nio.ByteBuffer

object OpenCL
{
  setExceptionsEnabled(true)
  val deviceType = CL_DEVICE_TYPE_CPU
  val devices = {
    val numPlatforms = Array(0)
    clGetPlatformIDs(0, null, numPlatforms)
    val platforms = new Array[cl_platform_id](numPlatforms(0))
    clGetPlatformIDs(platforms.length, platforms, null)
    platforms.flatMap(platform => {
      try {
        val contextProperties = new cl_context_properties
        contextProperties.addProperty(CL_CONTEXT_PLATFORM, platform)
        val numDevices = Array(0)
        clGetDeviceIDs(platform, deviceType, 0, null, numDevices)
        val devices = new Array[cl_device_id](numDevices(0))
        clGetDeviceIDs(platform, deviceType, numDevices(0), devices, null)
        devices.flatMap(device => {
          try{
            val vendorIdBuffer = new Array[Byte](1024)
            clGetDeviceInfo(device, CL_DEVICE_VENDOR, 1024, Pointer.to(vendorIdBuffer), null)
            val vendorId = new String(vendorIdBuffer, "UTF-8")
            if(!vendorId.matches(".*Intel.*")) {
              None
            } else {
              println(vendorId)
              val context = clCreateContext(contextProperties, 1, Array(device), null, null, null)
              val queue = clCreateCommandQueue(context, device, CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE | CL_QUEUE_PROFILING_ENABLE, null)
              Some(new OpenCLSession(context, queue, device))
            }
          } catch {
            case e: CLException => None
          }
        })
      } catch {
        case e: CLException => Nil
      }
    })
  }
  def main(args: Array[String]) : Unit = println((0 to 30).par.map(x => OpenCL.devices(0).stream((0 to 1024*1024*256).iterator.map(_.toDouble),1024*1024*256)))
}

class OpenCLSession (val context: cl_context, val queue: cl_command_queue, val device: cl_device_id)
{
  def stream(it: Iterator[Double], groupSize: Int = 1024*1024*256) : cl_mem = {
    var on_host : Option[cl_mem] = None
    try {
      on_host = Some(clCreateBuffer(context, CL_MEM_ALLOC_HOST_PTR, groupSize, null, null))
      val rawBuffer = clEnqueueMapBuffer(queue, on_host.get, true, CL_MAP_WRITE, 0, groupSize, 0, null, null, null)
      val buffer = rawBuffer.order(ByteOrder.nativeOrder).asDoubleBuffer
      var copied = 0
      while(copied < groupSize/Sizeof.cl_double && it.hasNext) {
        buffer.put(copied, it.next)
        copied += 1
      }
      clEnqueueUnmapMemObject(queue, on_host.get, rawBuffer, 0, null, null)
      clRetainMemObject(on_host.get)
      on_host.get
      } finally {
        on_host.foreach(clReleaseMemObject)
      }
  }

  override def finalize = {
    clReleaseCommandQueue(queue)
    clReleaseContext(context)
  }
}

I suspect it is some unfortunate interference between the jvm and the Intel OpenCL implementation. I would be glad for some expert judgment on this.

The build process with the current Vagrantfile and the description in the README does not work properly. There is something wrong with the Guest Additions and Folder Syncing.

I consider removing the Vagrantfile and VM build, because a manual build seems to be easier than setting up the VM properly.

I have install NVIDIA OpenCL sdk and have dll file, but I can not use it on IDEA

Scenarios:

1. some of the enqueueReleaseX methods is called twice on the same objects
2. an operation that needs valid context is called after the context has been released

Result: JVM crashes

This is expected behavior, but I am wondering whether there is a way to keep a flag in all NativePointerObject instances, that tracks whether the pointer is "valid"? This might result in exceptions, but at least the majority of JVM crashes could be avoided.

I also believe it could be backwards compatible, since the flag setting and checking would be an internal thing that does not have to be exposed to clients.

This issue is relevant to JCuda, too.

Im trying to get JOCL working on an Apple M1 Macbook.

Downloading version 2.0.4 appears to pick up the correct dylib for arm. but get the error function clCreateCommandQueueWithProperties is not supported, reardless what sample I attempt to run.

trying with Zulu java for arm64.
Its probably me not not knowing what I should do. But, help. :/

I've switched to arm64 to support Apple, and its awesome to see libJOCL_2_0_4-apple-arm64.dylib in the jar, but what about libJOCL_2_0_4-linux-arm64.so?

I need this to work on linux also, and I don't see why it wouldn't - save for this being missing.

I'm looking to reuse opencl code for a sobel filter that I got working with opencv.

I'm getting a CL_INVALID_WORK_GROUP_SIZE when using a local worksize of anything other than [1,1]. The project is here and I'm also asking on the clojurecl repo.

I'm hoping to figure out why this is happening.

---- Project (image-bench:1) ----

image-bench.sobel-test

 Failure  [sobel_test.clj:22]
    Info  "running a grayscale kernel at [345, 912] [13, 3]"
    Form  (gray/grayscale img [13 3])
   Check  java.awt.image.BufferedImage
  Actual  clojure.lang.ExceptionInfo: OpenCL error: CL_INVALID_WORK_GROUP_SIZE. {:name "CL_INVALID_WORK_GROUP_SIZE", :code -54, :type :opencl-error, :details "queue"}

 Failure  [sobel_test.clj:39]
    Info  "running a sobel kernel at [345, 912] [13, 3]"
    Form  (sobel/sobel-invalid-work-group-error img [13 3])
   Check  java.awt.image.BufferedImage
  Actual  clojure.lang.ExceptionInfo: OpenCL error: CL_INVALID_WORK_GROUP_SIZE. {:name "CL_INVALID_WORK_GROUP_SIZE", :code -54, :type :opencl-error, :details "queue"}

 Summary (1)
   Files  1
   Facts  4
  Checks  4
  Passed  2
  Thrown  0

 Failed  (2)

Can you please help me? when I enable the gpu plugin It crashes my mac after a few hours

here are my logs

jvm_crash_pid_71781.log
jvm_crash_pid_99320.log
jvm_crash_pid_7039.log
jvm_crash_pid_30251.log
jvm_crash_pid_56604.log
jvm_crash_pid_7992.log

(First time on GitHub, not really a coder, so please be gentle.)
Out of interest in running CLIJ (https://clij.github.io) which enables running ImageJ macros on GPU, I tried to compile JOCL on my M1 MacBook Pro (Big Sur 11.1, latest command line dev tools)
I installed native CMake (3.19.2)
Cloned JOCL and JOCLCommon, according to the build instructions
I then edited the CMakeLists.txt to add at line 60/61
elseif(CMAKE_OSX_ARCHITECTURES STREQUAL "arm64")
set(JOCL_TARGET_ARCH "arm64")
I'm running Zulu 15 JDK. In CMake I set the new Env variable
CMAKE_APPLE_SILICON_PROCESSOR to arm64
also set
CMAKE_OSX_ARCHITECTURES to arm64

make generated 5 warnings of 'weak-import' but finished:
[100%] Built target JOCL_2_0_1-apple-arm64

Adding the obtained dylib to Fiji along with CLIJ and CLIJ2 yielded functioning GPU processing.
Using benchmarks from CLIJ (https://clij.github.io/clij2-docs/md/benchmarking/):
the new binary enabled a ~60X speedup:
Native CPU: ~1200 ms, Native GPU: ~20 ms
(For reference, using a fully Rosetta Fiji: Rosetta CPU: ~1600 ms, Rosetta GPU: ~160 ms)

I can share the binary or edited CMakelists.txt
See also: twitter thread with maintainer of CLIJ @haesleinhuepf
https://twitter.com/psobolewskiPhD/status/1342494593082920960?s=20

Hi Marco!

Not sure if this might be appropriate to ask here, but I was more curious of native pointer address concept implementation in JOCL.

Since java might start using a safe api for foreign memory access (currently incubating in jdk 19, and proposed in JEP424), this might open doors to off-heap access of data (outside the jvm) and memory access might be a terabyte size depending on the physical memory available. Of-course native memory can be accessed through unconventional methods, such as the infamous Unsafe API (this API should have been made an official API aeons ago - but good thing the OpenJDK team is making strides to create and implement similar methods from Unsafe), and also through a direct buffer with a possibility of using a hack to get its pointer... public static long addressOfDirectBuffer(ByteBuffer buffer) {return ((DirectBuffer) buffer).address();} (caution, this is using sun.com code hence doesn't work in every java version), whereby the buffer parameter is a direct buffer. I'm aware that Direct ByteBuffer does use Unsafe, but unfortunately, the offheap data is still read into heap first, and still limited to the size of 2GB or 2^31.

Some great insights here

Based on the knowledge above, I was thinking of the possibility of implementing the "addressOfDirectBuffer", and use the long address and use it as an official pointer address as a way to experiment with native pointers and use of OpenCL USE_HOST_PTR. This is shown below.

package wrapper.core;

import org.jocl.NativePointerObject;
import org.jocl.Pointer;

/**
 *
 * @author user
 */
public class CPointer extends NativePointerObject{
    private final long pointer;
    
    public CPointer(long pointer)
    {
        super();
        this.pointer = pointer;
    }
    
    @Override
    protected long getNativePointer()
    {
        return pointer;
    }
    
    public Pointer getPointer()
    {
        return Pointer.to(this);
    }
    
    @Override
    public int hashCode()
    {
        int result = 227;
        int c = (int)(pointer ^ (pointer >>> 32));
        return 37 * result + c;
    }

    @Override
    public boolean equals(Object obj) {
        if (this == obj) {
            return true;
        }
        if (obj == null) {
            return false;
        }
        if (getClass() != obj.getClass()) {
            return false;
        }
        final CPointer other = (CPointer) obj;
        return this.pointer == other.pointer;
    }
}

Unfortunately, this approach doesn't work, and the data is corrupted in a way. Would you mind giving insights on how native pointers are implemented in jocl. For example, are the pointers accessed in jocl through JNI similar to maybe the hacks describe above? I know this might seem out of scope of what JOCL tries to provide (safe code), but I was a bit curious. There is a project I'm implementing that might require off-heap data only, due to out of memory heap issues.

You can play around with this project. Uses jdk 1.8 (use windows only - the file dialog explorer is quite custom), but good for debugging my other raytracing codes (like implementing new concepts rapidly).

Hello Marco,

I've come across an issue with memory consumption of my ray tracer , in which it implements a stream compaction as described here. This uses the prefix sum approach. For example, my intersection struct has like 10 variables with float4, float2, int, int4 and thus I result to implementing jocl experimental struct from jocl website.

Due to large memory consumption on a 4GB laptop, running the ray tracer is hectic. Needs to run in server mode jvm so as to go beyond 1200m Xmx in java8. Coz my intersection struct is an array of 480000 (800 x 600 screen space), that takes a lot of java memory together with temporary array for swapping same size when compacting intersection.

I did make a simple struct implementation that can utilize an array but only uses java primitives (int/float), only useful when you use one type of variable in a struct, and OpenCL loves that approach of forced struct data alignment. It has worked well in terms of loading large scenes (Wavefront OBJ), which everything is float4 hence array of floats. And it's the default implementation for scene data. Unlike a java class which stores extra data, hence resource consuming for large arrays of class objects, primitives do well in java. I discovered alternative approaches of struct implementation like Taleo-JUnion, which takes a similar approach. It allows use of different types of primitives and inner struct and lays that in bytebuffer. Works like a class but fast like a primitive in java. Unfortunately if I transfer by the bytebuffer to opencl using jocl, the values of a simple struct with different type variables doesn't work. Data results are jumbled up when assigned in a kernel. JUnion uses native order, but it seems you can configure the order of bytebuffer. If I could ask, how does jocl experimental Struct able to map data well to GPU?

By the way, I can make a simple example of prefix sum for use in your website since prefix sum is like the hello world of parallel programming, compatible with OpenCL 1.2.

Joe.

Hello there! The title gives the gist of the problem... a Java exception I get with JOCL 0.2.0 RC before anything really starts. What does this message mean?

BTW, I am porting JOCL (using the RC version to avoid Maven) to my language (JavaX). Main change to stock JOCL is that I load the native library dynamically. Testing on Peppermint 7 (64 Bit Linux), trying to calculate on an AMD Puma+ APU. libopencl from apt-get.

My ported source

Only change I made in JOCL sources is to remove the static initializer in CL.java.

Stack trace:

java.lang.UnsupportedOperationException: The function clGetPlatformIDs is not supported
at org.jocl.CL.clGetPlatformIDsNative(Native Method)
at org.jocl.CL.clGetPlatformIDs(CL.java:2152)
at main.main(main.java:86)

Please advise!!!! :-)

I have a device with 2 GPUs:

• Intel(R) HD Graphics 520
• NVIDIA GeForce 940MX
  GPU-Z shows that OpenCL is enabled and is working on both. I get 2 platforms when I obtain platform Ids using JOCL, but I don't know which device is in use! I wonder if I could know how can I get "device name" or its "vendor" using the platform Id?

I've tried to build JOCL on Ubuntu 18.04.

What I have done so far:

mkdir /home/<user>/JOCLRoot mkdir /home/<user>/JOCLRoot/JOCLBuild

cd /home/<user>/JOCLRoot

git clone https://github.com/gpu/JOCL.git git clone https://github.com/gpu/JOCLCommon.git

cmake-gui

cmake to /home/<user>/JOCLRoot/JOCLBuild

cd /home/<user>/JOCLRoot/JOCLBuild

make

cd /home/<user>/JOCLRoot/JOCL

mvn clean install

And on "mvn clean install" there are errors:

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3.259 s
[INFO] Finished at: 2020-12-30T09:57:34+01:00
[INFO] Final Memory: 15M/96M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test) on project jocl: There are test failures.
[ERROR] 
[ERROR] Please refer to /home/<user>/JOCLRoot/JOCL/target/surefire-reports for the individual test results.
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException

If I check the logs in /home//JOCLRoot/JOCL/target/target/surefire-reports the following error occurs:

-------------------------------------------------------------------------------
Test set: org.jocl.test.JOCLMinimalPlatformTest
-------------------------------------------------------------------------------
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.056 sec <<< FAILURE! - in org.jocl.test.JOCLMinimalPlatformTest
testGetPlatformIDs(org.jocl.test.JOCLMinimalPlatformTest)  Time elapsed: 0.055 sec  <<< ERROR!
java.lang.UnsatisfiedLinkError: Error while loading native library "JOCL_2_0_2-linux-x86_64"
Operating system name: Linux
Architecture         : amd64
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 JOCL_2_0_2-linux-x86_64 in java.library.path: [/home/<user>/JOCLRoot/JOCL/nativeLibraries]
	at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2670)
	at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:830)
	at java.base/java.lang.System.loadLibrary(System.java:1870)
	at org.jocl.LibUtils.loadLibrary(LibUtils.java:144)
	at org.jocl.CL.loadNativeLibrary(CL.java:65)
	at org.jocl.CL.<clinit>(CL.java:51)
	at org.jocl.test.JOCLMinimalPlatformTest.testGetPlatformIDs(JOCLMinimalPlatformTest.java:18)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
Stack trace from the attempt to load the library as a resource:
java.io.IOException: No resource found with name '/lib/libJOCL_2_0_2-linux-x86_64.so'
	at org.jocl.LibUtils.writeResourceToFile(LibUtils.java:341)
	at org.jocl.LibUtils.loadLibraryResource(LibUtils.java:269)
	at org.jocl.LibUtils.loadLibrary(LibUtils.java:159)
	at org.jocl.CL.loadNativeLibrary(CL.java:65)
	at org.jocl.CL.<clinit>(CL.java:51)
	at org.jocl.test.JOCLMinimalPlatformTest.testGetPlatformIDs(JOCLMinimalPlatformTest.java:18)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
---(end of nested stack traces)---

	at org.jocl.LibUtils.loadLibrary(LibUtils.java:194)
	at org.jocl.CL.loadNativeLibrary(CL.java:65)
	at org.jocl.CL.<clinit>(CL.java:51)
	at org.jocl.test.JOCLMinimalPlatformTest.testGetPlatformIDs(JOCLMinimalPlatformTest.java:18)

I think this is the important one:
java.lang.UnsatisfiedLinkError: no JOCL_2_0_2-linux-x86_64 in java.library.path: [/home/<user>/JOCLRoot/JOCL/nativeLibraries]

In "/home//JOCLRoot/JOCL/nativeLibraries" I can only find the file "libJOCL_2_0_1-linux-x86_64.so"

So there is somehow a conflict between 2_0_2 and 2_0_1.

How can I fix that?

Thanks in advance for the help!

I add all android platform : arm,arm-v7a,arm64,mips,mips64,x86,x86_64. It just 1.9mb. and I import it to my android app, Us Android Studio . when the app installed, it can auto deploy the .so file to /data/app/xxx.xxx.xxx/lib/arm64 or /data/app/xxx.xxx.xxx/lib/arm and so on… I use two of your samples to test it. and found HistogramAMD.java line 87 maxWorkGroupSize should be "long" in android. And JOCLSample_1_2_KernelArgs.java line 173 clGetDeviceIDs(platform, deviceType, 0, null, numDevicesArray);
the deviceType can't be CL_DEVICE_TYPE_ALL but can be CL_DEVICE_TYPE_CPU/GPU/DEFAULT

Microsoft Windows [Version 10.0.18362.1016]
(c) 2019 Microsoft Corporation. All rights reserved.

C:\Users\tpave>cd C:\Users\tpave\Desktop\JOCLRoot

C:\Users\tpave\Desktop\JOCLRoot>git clone https://github.com/gpu/JOCL
Cloning into 'JOCL'...
remote: Enumerating objects: 53, done.
remote: Counting objects: 100% (53/53), done.
remote: Compressing objects: 100% (32/32), done.
remote: Total 971 (delta 15), reused 45 (delta 11), pack-reused 918
Receiving objects: 100% (971/971), 765.08 KiB | 1.69 MiB/s, done.
Resolving deltas: 100% (515/515), done.

C:\Users\tpave\Desktop\JOCLRoot>git clone https://github.com/gpu/JOCLCommon.git
Cloning into 'JOCLCommon'...
remote: Enumerating objects: 173, done.
Receiving objects: 59% 0), reused 0 (delta 0), pack-reused 173 eceiving objects: 58% (101/173)
Receiving objects: 100% (173/173), 81.65 KiB | 633.00 KiB/s, done.
Resolving deltas: 100% (88/88), done.

C:\Users\tpave\Desktop\JOCLRoot>cmake-gui

C:\Users\tpave\Desktop\JOCLRoot>cd JOCL

C:\Users\tpave\Desktop\JOCLRoot\JOCL>mvn clean install
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for org.jocl:jocl:jar:2.0.3-SNAPSHOT
[WARNING] Reporting configuration should be done in section, not in maven-site-plugin as reportPlugins parameter. @ line 181, column 40
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]
[INFO]
[INFO] ---------------------------< org.jocl:jocl >----------------------------
[INFO] Building JOCL 2.0.3-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ jocl ---
[INFO]
[INFO] --- maven-enforcer-plugin:1.2:enforce (enforce-maven) @ jocl ---
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ jocl ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory C:\Users\tpave\Desktop\JOCLRoot\JOCL\src\main\resources
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ jocl ---
[INFO] Compiling 33 source files to C:\Users\tpave\Desktop\JOCLRoot\JOCL\target\classes
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:testResources (default-testResources) @ jocl ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory C:\Users\tpave\Desktop\JOCLRoot\JOCL\src\test\resources
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @ jocl ---
[INFO] Compiling 5 source files to C:\Users\tpave\Desktop\JOCLRoot\JOCL\target\test-classes
[INFO]
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ jocl ---
[INFO] Surefire report directory: C:\Users\tpave\Desktop\JOCLRoot\JOCL\target\surefire-reports

T E S T S

Running org.jocl.test.JOCLBasicTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.03 sec <<< FAILURE! - in org.jocl.test.JOCLBasicTest
basicTest(org.jocl.test.JOCLBasicTest) Time elapsed: 0.022 sec <<< ERROR!
java.lang.UnsatisfiedLinkError: Error while loading native library "JOCL_2_0_2-windows-x86_64"
Operating system name: Windows 10
Architecture : amd64
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 JOCL_2_0_2-windows-x86_64 in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1860)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
at java.lang.System.loadLibrary(System.java:1122)
at org.jocl.LibUtils.loadLibrary(LibUtils.java:144)
at org.jocl.CL.loadNativeLibrary(CL.java:65)
at org.jocl.CL.(CL.java:51)
at org.jocl.test.JOCLAbstractTest.initCL(JOCLAbstractTest.java:52)
at org.jocl.test.JOCLBasicTest.basicTest(JOCLBasicTest.java:30)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
Stack trace from the attempt to load the library as a resource:
java.io.IOException: No resource found with name '/lib/JOCL_2_0_2-windows-x86_64.dll'
at org.jocl.LibUtils.writeResourceToFile(LibUtils.java:341)
at org.jocl.LibUtils.loadLibraryResource(LibUtils.java:269)
at org.jocl.LibUtils.loadLibrary(LibUtils.java:159)
at org.jocl.CL.loadNativeLibrary(CL.java:65)
at org.jocl.CL.(CL.java:51)
at org.jocl.test.JOCLAbstractTest.initCL(JOCLAbstractTest.java:52)
at org.jocl.test.JOCLBasicTest.basicTest(JOCLBasicTest.java:30)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
---(end of nested stack traces)---
at org.jocl.LibUtils.loadLibrary(LibUtils.java:194)
at org.jocl.CL.loadNativeLibrary(CL.java:65)
at org.jocl.CL.(CL.java:51)
at org.jocl.test.JOCLAbstractTest.initCL(JOCLAbstractTest.java:52)
at org.jocl.test.JOCLBasicTest.basicTest(JOCLBasicTest.java:30)

Running org.jocl.test.JOCLMinimalPlatformTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec <<< FAILURE! - in org.jocl.test.JOCLMinimalPlatformTest
testGetPlatformIDs(org.jocl.test.JOCLMinimalPlatformTest) Time elapsed: 0 sec <<< ERROR!
java.lang.NoClassDefFoundError: Could not initialize class org.jocl.CL
at org.jocl.test.JOCLMinimalPlatformTest.testGetPlatformIDs(JOCLMinimalPlatformTest.java:18)

Running org.jocl.test.SizeofTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec <<< FAILURE! - in org.jocl.test.SizeofTest
sizeofTest(org.jocl.test.SizeofTest) Time elapsed: 0 sec <<< ERROR!
java.lang.NoClassDefFoundError: Could not initialize class org.jocl.CL
at org.jocl.Sizeof.(Sizeof.java:48)
at org.jocl.test.SizeofTest.sizeofTest(SizeofTest.java:17)

Running org.jocl.test.TestNonBlockingConstraints
Tests run: 6, Failures: 0, Errors: 6, Skipped: 0, Time elapsed: 0 sec <<< FAILURE! - in org.jocl.test.TestNonBlockingConstraints
testNonBlockingReadWithJavaArrayThrows(org.jocl.test.TestNonBlockingConstraints) Time elapsed: 0 sec <<< ERROR!
java.lang.NoClassDefFoundError: Could not initialize class org.jocl.CL
at org.jocl.test.JOCLAbstractTest.initCL(JOCLAbstractTest.java:52)
at org.jocl.test.TestNonBlockingConstraints.testNonBlockingReadWithJavaArrayThrows(TestNonBlockingConstraints.java:37)

testNonBlockingReadWithBufferThrows(org.jocl.test.TestNonBlockingConstraints) Time elapsed: 0 sec <<< ERROR!
java.lang.NoClassDefFoundError: Could not initialize class org.jocl.CL
at org.jocl.test.JOCLAbstractTest.initCL(JOCLAbstractTest.java:52)
at org.jocl.test.TestNonBlockingConstraints.testNonBlockingReadWithBufferThrows(TestNonBlockingConstraints.java:55)

testNonBlockingWriteWithJavaArrayThrows(org.jocl.test.TestNonBlockingConstraints) Time elapsed: 0 sec <<< ERROR!
java.lang.NoClassDefFoundError: Could not initialize class org.jocl.CL
at org.jocl.test.JOCLAbstractTest.initCL(JOCLAbstractTest.java:52)
at org.jocl.test.TestNonBlockingConstraints.testNonBlockingWriteWithJavaArrayThrows(TestNonBlockingConstraints.java:92)

testNonBlockingWriteWithBufferThrows(org.jocl.test.TestNonBlockingConstraints) Time elapsed: 0 sec <<< ERROR!
java.lang.NoClassDefFoundError: Could not initialize class org.jocl.CL
at org.jocl.test.JOCLAbstractTest.initCL(JOCLAbstractTest.java:52)
at org.jocl.test.TestNonBlockingConstraints.testNonBlockingWriteWithBufferThrows(TestNonBlockingConstraints.java:110)

testNonBlockingReadWithDirectBuffer(org.jocl.test.TestNonBlockingConstraints) Time elapsed: 0 sec <<< ERROR!
java.lang.NoClassDefFoundError: Could not initialize class org.jocl.CL
at org.jocl.test.JOCLAbstractTest.initCL(JOCLAbstractTest.java:52)
at org.jocl.test.TestNonBlockingConstraints.testNonBlockingReadWithDirectBuffer(TestNonBlockingConstraints.java:73)

testNonBlockingWriteWithDirectBuffer(org.jocl.test.TestNonBlockingConstraints) Time elapsed: 0 sec <<< ERROR!
java.lang.NoClassDefFoundError: Could not initialize class org.jocl.CL
at org.jocl.test.JOCLAbstractTest.initCL(JOCLAbstractTest.java:52)
at org.jocl.test.TestNonBlockingConstraints.testNonBlockingWriteWithDirectBuffer(TestNonBlockingConstraints.java:128)

Results :

Tests in error:
JOCLBasicTest.basicTest:30->JOCLAbstractTest.initCL:52 » UnsatisfiedLink Error...
JOCLMinimalPlatformTest.testGetPlatformIDs:18 NoClassDefFound Could not initia...
SizeofTest.sizeofTest:17 » NoClassDefFound Could not initialize class org.jocl...
TestNonBlockingConstraints.testNonBlockingReadWithBufferThrows:55->JOCLAbstractTest.initCL:52 » NoClassDefFound
TestNonBlockingConstraints.testNonBlockingReadWithDirectBuffer:73->JOCLAbstractTest.initCL:52 » NoClassDefFound
TestNonBlockingConstraints.testNonBlockingReadWithJavaArrayThrows:37->JOCLAbstractTest.initCL:52 » NoClassDefFound
TestNonBlockingConstraints.testNonBlockingWriteWithBufferThrows:110->JOCLAbstractTest.initCL:52 » NoClassDefFound
TestNonBlockingConstraints.testNonBlockingWriteWithDirectBuffer:128->JOCLAbstractTest.initCL:52 » NoClassDefFound
TestNonBlockingConstraints.testNonBlockingWriteWithJavaArrayThrows:92->JOCLAbstractTest.initCL:52 » NoClassDefFound

Tests run: 9, Failures: 0, Errors: 9, Skipped: 0

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 5.170 s
[INFO] Finished at: 2020-08-26T12:25:08-05:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test) on project jocl: There are test failures.
[ERROR]
[ERROR] Please refer to C:\Users\tpave\Desktop\JOCLRoot\JOCL\target\surefire-reports for the individual test results.
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException

C:\Users\tpave\Desktop\JOCLRoot\JOCL>

I have just built and installed JOCL on Arch Linux and discovered regressions with the newest android-related changes in Sizeof, when used in linux.

JOCL builds and tests fine, but when I tried it with a well testet ClojureCL, the built failed, with a messages related to the newly introduced Sizeof native method:

java.lang.UnsatisfiedLinkError: org.jocl.Sizeof.computePointerSizeNative()I

This happens with the latest commit 18d9a04

I did a checkout of last week's commit 862f2ab: JOCL gets built, AND the existing projects work.

Hi Thanks for the work.

I am trying to build latest JOCL on Mac OS X. I generated XCode builds.
However, it is failing with undefined references for nullptr.

/Users/abc/JOCLRoot/JOCLCommon/src/main/native/ConversionsCL.hpp:134:14: 
error: no member named 'memcpy' in namespace 'std'
        std::memcpy(nativeObject, primitiveArray, length * sizeof(JavaType));

Users/abc/JOCLRoot/JOCLCommon/src/main/native/ConversionsCL.hpp:138:20: error: use of undeclared identifier 'nullptr'
    nativeObject = nullptr;

Would it be possible to get Mac Build any time sooner ?

Needs some form of system-level dependency build script. Doesn't have to cover every end-user case, just better than google for everything.

In order to get a compute context from for CL-GL memory sharing on apple devices, they have their own flow

Relevant Apple Tech Note Listings 4 and 5

In particular, the components that I found necessary were the context property flag CL_CONTEXT_PROPERTY_USE_CGL_SHAREGROUP_APPLE = 268435456, and the method clGetGLContextInfoAPPLE along with its own parameter values. With just this one method, the rest of the typical CL-GL init flow can be used.

Are there any existing bindings for these/plans to add them?

I'm curious to know if there are any benchmarks for operations in jocl as compared to using c++.

I've done my own benchmarking with the opencv ocl library and jocl on a custom image algorithm and found that there is an order of an magnitude difference between jocl and native ocl:

jocl, 0250px: 2.467 ms
jocl, 0500px: 6.367 ms
jocl, 1000px: 24.060 ms
jocl, 2000px: 81.356 ms
jocl, 4000px: 287.928 ms
jocl, 8000px: 1031.693 ms

cv::ocl, 0250px: 0.475 ms
cv::ocl, 0500px: 0.783 ms
cv::ocl, 1000px: 1.632 ms
cv::ocl, 2000px: 4.555 ms
cv::ocl, 4000px: 15.846 ms
cv::ocl, 8000px: 121.899 ms

Is there any reason for this?