Hardcoded float not working?

Well spotted, but library in /usr/lib is just a link to library in /usr/lib/fglrx:

root@pcmb:~/WindowsShared/Magistrska/opencl/test2# ls -al /usr/lib/libOpenCL.so
lrwxrwxrwx 1 root root 47 dec 23 13:16 /usr/lib/libOpenCL.so -> /etc/alternatives/x86_64-linux-gnu_libOpenCL.so
root@pcmb:~/WindowsShared/Magistrska/opencl/test2# ls -al /etc/alternatives/x86_64-linux-gnu_libOpenCL.so
lrwxrwxrwx 1 root root 27 dec 23 13:16 /etc/alternatives/x86_64-linux-gnu_libOpenCL.so -> /usr/lib/fglrx/libOpenCL.so
root@pcmb:~/WindowsShared/Magistrska/opencl/test2# ls -al /usr/lib/fglrx/libOpenCL.so
lrwxrwxrwx 1 root root 14 avg  6 15:32 /usr/lib/fglrx/libOpenCL.so -> libOpenCL.so.1

Also running with LD_DEBUG=all confirms that JOCL is using correct library, same one as working hello_world C++ binary:

mfur@pcmb:~/WindowsShared/Magistrska/jocl-test$ LD_DEBUG=all java -cp jogamp-all-platforms/jar/jocl.jar:jogamp-all-platforms/jar/gluegen-rt.jar:. OCLTest 2>&1 | grep -i libopencl | grep -i build
     21513: symbol=buildCB_mid;  lookup in file=/usr/lib/fglrx/libOpenCL.so.1 [0]
     21513: symbol=buildProgramCallback;  lookup in file=/usr/lib/fglrx/libOpenCL.so.1 [0]
     21513: symbol=clBuildProgram;  lookup in file=/usr/lib/fglrx/libOpenCL.so.1 [0]
     21513: binding file /usr/lib/fglrx/libOpenCL.so.1 [0] to /usr/lib/fglrx/libOpenCL.so.1 [0]: normal symbol `clBuildProgram'
     21513: symbol=clGetProgramBuildInfo;  lookup in file=/usr/lib/fglrx/libOpenCL.so.1 [0]
     21513: binding file /usr/lib/fglrx/libOpenCL.so.1 [0] to /usr/lib/fglrx/libOpenCL.so.1 [0]: normal symbol `clGetProgramBuildInfo'

I will test another java library tomorrow and if it works, it has to be a bug in JOCL or in specific combination of JOCL/driver, as mentioned before.

Maybe the language setting interferes with the way the decimal separator is interpreted.

Maybe all constants are truncated like in this bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694660

gouessej wrote

Maybe the language setting interferes with the way the decimal separator is interpreted.

A very intriguing possibility. Perhaps passing the kernel as a string literal in the code would tell us if this is happening. There's no way to pass a locale to Class.getResourceAsString(), but if you pass the kernel as a string literal to CLContext.createProgram() it should bypass any locale processing.

The OpenCL spec doesn't mention anything about locales, so they seem to be assuming everyone in the world writes "0.5f" :)

Same result using hardcoded kernel:
...
String testKernel = "kernel void fill(global float* a, const int size, const int value) {    int index = get_global_id(0);    if (index >= size) {        return;    } a[index] = 0.5f;}";
                CLProgram program = context.createProgram(testKernel);
....

Mentioned bug report (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694660) is describing same problem but I am experiencing it only from Java/JOCL+openCL, not directly (C++).

My sistem is configured as Slovenian (we use commas in numbers), but that shouldn't present any problems..

I ran a quick test using another java OpenCL library (http://www.jocl.org/ with modified sample from http://www.jocl.org/samples/JOCLSample.java).

Same truncated result. So it is not a bug in JOCL from JogAmp..

Also no difference when specifying locale at java runtime:
java  -Duser.language=en -Duser.country=US -Duser.variant=US -cp JOCL-0.1.9.jar:. JOCLSample

SOLVED!

Using java compiler from java-6-openjdk-amd64 produces expected result. Compiler from java-7-openjdk-amd64 does not.

Previously I wrote that I tested both java versions and it didn't work with either. I changed java environment using "update-alternatives --java", which changed only JRE and not compiler. Now I explicitly used java 6 compiler and it worked as it should!

Thank you for all your help!

Glad you fixed the problem, but I wish I knew for sure what was causing it  I can successfully use JOCL JARs (which are compiled with Java 6) from a Java 7 program when I use the Oracle JDK/JRE, so perhaps this has to do with native buffer handling differences between OpenJDK 6 and 7.

Wade Walker wrote

perhaps this has to do with native buffer handling differences between OpenJDK 6 and 7.

You can force the same page alignment than in Java 1.6 in Java 1.7 with -XX:+PageAlignDirectMemory:
http://docs.oracle.com/javase/7/docs/technotes/guides/io/enhancements.html#jdk7

Miha wrote

My sistem is configured as Slovenian (we use commas in numbers), but that shouldn't present any problems..

It may cause some troubles, change the LANG environment variable to check that.

Miha wrote

compiler somehow recognizes all hardcoded floats as integers.

for those who will find it (after driving nuts for a few days)

the problem is not in JOCL (I used JavaCL) nor in Java (although Java7 and Java6 behave differently).
It's definitely a bug in the AMD OpenCL compiler for Linux. It also appears under various circumstances:

bug in OpenCL parser depend on locale $LANG
Kernel fail with other than en_US locale
Floating Point Bug in OpenCL via ssh
CodeXL truncate float on when profiling openCL


To solve the issue set the environment variable LC_NUMERIC=C

You can also try your code in the clean environment: env -i java <args>

Thank you for the tip. LC_NUMERIC concerns the numeric formatting.