techniker / freeocl Goto Github PK

Purpose of code changes on this branch:
To enable serial execution of the CL kernels.
Optionally to exclude OpenMP dependency.
Debugging purposes.

When reviewing my code changes, please focus on:
Does it look correct?

After the review, I'll merge this branch into:
/trunk


Note: cldemo behaves strangely so I patched it this way and it works, but 
probably my serial patch is not quite correct.

What steps will reproduce the problem?
1. have an opencl kernel that has an #include anyheader.h

What is the expected output? What do you see instead?
I'd expect the header to be found instead the preprocessor log reads:

** preprocessor log:
/tmp/fileVl0WKf:8:27: fatal error: mandelbrot_cl.h: No such file or directory
compilation terminated.

What version of the product are you using? On what operating system?
svn trunk, r161 - opensuse 11.2/atom N270

What steps will reproduce the problem?
Use some comparisons with char values using single quotes, for example this 
kernel:

if (c<'A') {
  //some code
}

See the detailed log for more info.

What is the expected output? What do you see instead?

I'd expect this to work, instead it converts the char constants into variables. 
See detailed log. If I convert the character constants to their ascii values, 
the code runs fine.

What version of the product are you using? On what operating system?
svn trunk, r161 - opensuse 11.2/atom N270

I am using FreeOCL revision 313.

I have OpenCL source code that uses multi-line #define statements, where the 
argument list is spread over several lines. The following code demonstrates the 
problem:

{{{
#define m1(a,b) a

#define m2(a,b)                                 \
  a

#define m3(a,                                   \
           b) a

#define m4(a,                                   \
           b)                                   \
  a
}}}

FreeOCL reports an error

{{{
error <input>:28: #define m3(a,                                   \
                                                                 ^
                  expected identifier
}}}

I find that FreeOCL (revision 313) does not work on OSX out of the box. I had 
to make some changes (see patch) to make it build and run. In some cases, I 
tried to find a generic solution that is likely to work on other systems as 
well, in other, more complex cases I only made it work for OSX, and one still 
needs to integrate this with other platforms.

The patches do the following:

Configuring FreeOCL: cmake's CMAKE_THREAD_LIBS_INIT is not defined.

Compiling OpenCL code: The option -cl-strict-aliasing was not supported.

Startup: OSX uses a slightly different sysctl. I also added hiding errors 
(2>/dev/null). In general, I recommend hwloc to find out about 
memory/cache/cores etc.; this is a high-quality, very portable library from the 
OpenMPI developers.

src/kernel.cpp: Did not compile for me. Presumably, some "cl_" type prefixes 
were missing.

atomic operstions: I don't have atomic_ops.h. I'm using gcc builtins instead. 
The current code works for gcc 4.8.

clock: OSX doesn't have clock_gettime. Instead, there is a routine 
mach_absolute_time that one can call. The result is probably in cycles and 
needs to be converted to nanoseconds.

What steps will reproduce the problem?
1. Install and run piglit (http://people.freedesktop.org/~nh/piglit/) with 
all_cl tests

What is the expected output? What do you see instead?
Ideally, all tests pass should pass. More than half do, but a good portion 
fail, and a small handful crash. (11 crash, 144 fail, 220 pass).

What version of the product are you using? On what operating system?
freeocl-svn r340 on Arch Linux 


Please provide any additional information below.
Most of the failed tests seem to be edge cases on API conformance, or certain 
missing type/operator definitions. I've been slowly working through the list 
and I've attached patches for the failed tests I've fixed so far.

cmake with:

cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr ../freeocl

log of error:

/var/build/freeocl/src/utils/threadpool.cpp: In member function 'void 
FreeOCL::threadpool::wait_for_all()':
/var/build/freeocl/src/utils/threadpool.cpp:46:15: error: '_mm_pause' was not 
declared in this scope
make[2]: *** [src/CMakeFiles/FreeOCL.dir/utils/threadpool.cpp.o] Error 1
make[1]: *** [src/CMakeFiles/FreeOCL.dir/all] Error 2
make: *** [all] Error 2

using gcc (Debian 4.7.2-4) 4.7.2, on Debian sid x86_64 GNU/Linux kernel 
3.2.0-4-amd64.

In reference to bug #18, the integer builtins do not have full type coverage 
([u]char, [u]short, and some [u]long), along with the vector equivalents.

I've attached a patch that expands to [almost] fully cover the builtin 
functions and types (including vectors).

This is a rather larger patch, but was difficult to do incrementally.

vectors.h was expanded to cover [u]char, [u]short, and [u]long. The 
VECTOR_IMPLEMENTATION_FROM_SCALAR_IMPLEMENTATION#_[I/U](F) macro was abstracted 
to a VECTOR_IMPLEMENTATION_FROM_SCALAR_IMPLEMENTATION#_T(X, F) macro that 
accepts the type (Instead of using a separate macro for each type). This is 
accompanied by proper #undefs in opencl_c.h

integer.h is where the largest amount of changes happened.
1)Expansion of most functions to the full integer types (with certain functions 
requiring a different manual overload if function differs between types)
2) Custom VECTOR_IMPLEMENTATION_FROM_SCALAR macros for functions with weird 
type signatures (abs, abs_diff, upsample, and clamp). I could not for the life 
of me find a template that would work for these.

These changes required changes to the parser and image*.h (where abs is used).
1) The parser was generating extraneous type signatures for abs()/abs_diff(), 
such as "__char2 abs (__uchar2)", that was causing parser errors in certain 
cases.
2) The parser was also not generating the full vector type signatures for 
upsample (which has a weird type signature to begin with). As this is an 
exception, I just manually added all permutations for vector types.
3) image#d_*.h had assignment from abs() to a signed type. This was causing 
compile time errors for vector types, so this needed to be edited to manually 
cast/convert from unsigned to signed vector types.

The one exception I could not get working were a subset of the [u]long builtin 
functions (such as mul_hi, *_sat, mad_hi, hadd), which required casting to a 
higher type to avoid overflow (due to the lack of a 128-bit type :P). I'm not 
sure how to accomplish this...

 http://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/clSetCommandQueueProperty.html

Please add clSetCommandQueueProperty from opencl-1.0.

Patch attached (tested on gentoo/amd64).

Let me preface by saying that I'm not a lawyer, so this may not be applicable.  
However, I think that when freeocl is compiled such that it dynamically links 
against libgomp (as is the default, whenever libgomp is available), it is not 
license-able under LGPL (since everything linking against any GPL library must 
be GPL itself).  See the chart at 
http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility for details. 

This should be spelled out at the top of copying.lesser; that if freeocl is 
compiled with OpenMP support, it is subject to only the GPL and that the 
contents of the copying.lesser do not apply.  I would suggest in the main 
CMakeLists.txt provide the user an option whether to use libgomp that 
reiterates this point, e.g. in trunk/CMakeLists.txt, something like:
OPTION( FREEOCL_USE_OPENMP "Set to true to allow linking to libgomp.  Note that 
this makes the software subject only to the GPL license, without the LGPL 
exceptions!" OFF)
IF( FREEOCL_USE_OPENMP)
  include(FindOpenMP optional)
  if(OPENMP_FOUND)
       message(STATUS "OpenMP found.")
        set(FREEOCL_USE_OPENMP 1)
  else(OPENMP_FOUND)
        message(STATUS "OpenMP not found, won't be used.")
        set(FREEOCL_USE_OPENMP 0)
  endif(OPENMP_FOUND)
ENDIF( FREEOCL_USE_OPENMP)

1) Please, don't delete temporary files when compiled in debug mode.
Example:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xf4a6f940 (LWP 28859)]
fl_summ (neuronit=<optimized out>, cs1stc=<optimized out>, weights=<optimized 
out>) at /tmp/fileJ4cnyP:133
133     /tmp/fileJ4cnyP: No such file or directory

2) Freoocl uses gcc as cl compiler. Why do not to pass standard C flags to it? 
I got error when use "-g" in options.
clBuildProgram( program, 0, NULL, options, NULL, NULL );

I was attempting to compile kernels that use:
#define X(x,y) x ## y

The build log shows expansions of "x ## y" as opposed to "xy" (and kernel 
compilation thus fails).

I am using revision r336, and judging from the source, it appears there is no 
support for parameter concatenation (nor stringification).

I've attached a quick patch that attempts to add it to the parameter 
substitution portion of the macro expander, and seems to do the job for these 
kernels.

What steps will reproduce the problem?
1. Use GCC4.7.0 or later
2. cmake -> make
3. error will occur

What is the expected output? What do you see instead?
Compilation successful

What version of the product are you using? On what operating system?
latest svn, Arch Linux 32bit with gcc 4.7.0

Please provide any additional information below.
Patch included fixes it.

What steps will reproduce the problem?
1. install freebsd
2. run anything that wants freeocl
3. bingo

What is the expected output? What do you see instead?
expected: nothing
what I get: "sysctl: unknown oid 'kernel.ostype'"

What version of the product are you using? On what operating system?
version: 0.3.6
OS: FreeBSD 9.2-prerelease

Please provide any additional information below.
sysctl has a quiet-mode (-q). in linux it seems to be default and the flag does 
nothing, in BSD is barks if you don't pass it.
I've attached a patch to fix the issue (only kern{,el}.ostype needs it, as 
that's the only one that seems faulty)

Another way would be to just flip the order so kern.ostype is first (so freebsd 
is happy) as linux doesn't mind.

(P.S. why do you support an OS that isn't tested? ;) )

What steps will reproduce the problem?
1. We want to use freeocl for our project to be able to distribute a 
libOpenCL.so for Linux and libOpenCL.dll for windows as well.
I understand that the project does currently not officially support windows, 
but I guess you are working on it. I managed to modify the sources, so that it 
can at least compile the libOpenCL.dll
for this, it is necessary to use the https://code.google.com/p/dlfcn-win32/ 
project, which provides a dlfcn implementation for windows
This needs to be compiled with the submitted patch:
https://code.google.com/p/dlfcn-win32/issues/detail?id=12
this exports the function declarations with C-naming, so that it can be linked
2.
cmake considers dll's as runtime, so the INSTALL directives need to be 
complemented by a "RUNTIME DESTINATION bin" or whatever is desired
3.
Now, using an mingw cross-compiler (created by mxe.cc) the project can be 
configured in the build directory:
cmake -DCMAKE_TOOLCHAIN_FILE=../i686-w64-mingw32.cmake 
-DCMAKE_BUILD_TYPE=Release -DCMAKE_INCLUDE_PATH=../dlfcn/ 
-DCMAKE_LIBRARY_PATH=../dlfcn/ ../
considereing that the attached patch is applied and dlfcn was compiled within 
the project folder, so that the dlfcn.h can be found and libdl.a can be found 
(using the included FindLibdl.cmake module).

What is the expected output? What do you see instead?
make OpenCL
will now complain about some small errors:
src/icd/icd_api.cpp:560:26: error: declaration of C function 'cl_int 
clEnqueueNativeKernel(cl_command_queue, void (*)(void*), void*, size_t, 
cl_uint, _cl_mem* const*, const void**, cl_uint, _cl_event* const*, 
_cl_event**)' conflicts with
           cl_event *event)
                          ^
In file included from src/dispatch.h:24:0,
                 from src/freeocl.h:26,
                 from src/icd/icd_api.cpp:18:
include/CL/cl.h:1132:1: error: previous declaration 'cl_int 
clEnqueueNativeKernel(cl_command_queue, void (__attribute__((__stdcall__)) 
*)(void*), void*, size_t, cl_uint, _cl_mem* const*, const void**, cl_uint, 
_cl_event* const*, _cl_event**)' here
 clEnqueueNativeKernel(cl_command_queue  /* command_queue */,

This is because the function declaration within the source is missing the 
"CL_CALLBACK" for the callback function pointer as it is actually defined in 
the cl.h (also corrected in the attached patch). Adding it to src/dispatch.h 
and src/icd/icd_api.cpp fixes it.

The last problem is the following:
In file included from src/icd/icd_api.cpp:25:0:
src/kernel.h:24:22: fatal error: ucontext.h: No such file or directory
 #include <ucontext.h>

This is because windows and mingw does not have a ucontext implementation (not 
POSIX?!) - there is an implementation available, it seems to compile:
http://www.codeproject.com/Articles/4225/Unix-ucontext_t-Operations-on-Windows-P
latforms
and can be used, but I am not sure if this is desired.

But I think for compiling the libOpenCL.dll it should not be necessary to have 
the kernel.h include a declaration for __FCL_setwg which uses the ucontext. But 
I am not familiar with the layout of the freeocl project, so I am not able to 
deconvolute the kernel.h - but the attached patch currently comments the 
ucontext.h include and the __FCL_setwg declaration, since it is not required by 
libOpenCL.dll

With that, libOpenCL.dll is compiling with the cross compiler. The Freeocl is 
another issue that can only be solved if the ucontext issue is adressed..

What version of the product are you using? On what operating system?
freeocl r319 on Ubuntu 12.04 using mxe mingw cross compiler gcc 4.8.1
dlfcn-win32 r19 with patch )as mentioned above)

Please provide any additional information below.
I am looking forward to your feedback

What steps will reproduce the problem?
1. Run luxmark 
2. Select "Mode->OpenCL CPUs-only"
3. "syntax error, '}' expected"

What is the expected output? What do you see instead?

Luxmark should succeed, but the parser errors out on the first struct that 
defines a union as a member.

This seems to be the offending struct (though there are more further down in 
the source):

typedef struct {
        TextureMapping2DType type;
        union {
                UVMappingParam uvMapping2D;
        };
} TextureMapping2D;

The struct parsing routine that is throwing the error seems to have trouble 
with the union definition, but I am having difficulty finding a way to amend 
the parser and/or confirm it is the union causing the syntax error.

If you install freeocl in another prefix using 
-DCMAKE_INSTALL_PREFIX=/opt/freeocl for example, then kernels will all fails to 
build because it doesn't go looking for the headers in /opt/freeocl/include.  
The install directory should be explicitely added to the include search parth 
IMHO.

cmake with:

cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_DIR=/usr/share/llvm/cmake/modules 
../freeocl

log of error:

/var/build/freeocl-llvm/src/parser/ast/var.cpp: In member function ‘void 
FreeOCL::var::allocate(FreeOCL::vm*) const’:
/var/build/freeocl-llvm/src/parser/ast/var.cpp:81:11: error: ‘class 
llvm::GlobalVariable’ has no member named ‘setThreadLocalMode’
/var/build/freeocl-llvm/src/parser/ast/var.cpp:81:30: error: 
‘GeneralDynamicTLSModel’ is not a member of ‘llvm::GlobalVariable’

using llvm 3.1, gcc 4.7.2, on Debian sid x86_64 GNU/Linux kernel 3.2.0-4-amd64.

What steps will reproduce the problem?
OpenCL mul24 has wrong number of operands

What is the expected output? What do you see instead?
It should have two, but it code it expects 3.

What version of the product are you using? On what operating system?
freeocl 309M, Ubuntu x64

Please provide any additional information below.
In file: src/parser/builtin.cpp
In line: 307
REGISTER_OVERLOADED("gentype mul24(gentype,gentype,gentype)", gentype_integers);

Should be:
REGISTER_OVERLOADED("gentype mul24(gentype,gentype)", gentype_integers);

In order to reproduce the problem:
1. go to AMD's SDK sample folder
2. run "./FFT -p id --device cpu" where id is FreeOCL platform id

The expected output should be 2 series of random looking numbers, instead we 
get 2 series terminated with zeros:

Output real
470.366 169.35 -131.651 168.41 0 0 0 0 0 0 


Output img
1.79946 -115.327 -0.570963 116 0 0 0 0 0 0