sctincman / freeocl Goto Github PK
View Code? Open in Web Editor NEWOpenCL 1.2 implementation targeting CPUs, utilizing an external C++ compiler
License: GNU Lesser General Public License v3.0
OpenCL 1.2 implementation targeting CPUs, utilizing an external C++ compiler
License: GNU Lesser General Public License v3.0
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);
Original issue reported on code.google.com by [email protected]
on 22 Nov 2012 at 12:14
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.
Original issue reported on code.google.com by [email protected]
on 8 Aug 2014 at 8:45
Attachments:
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...
Original issue reported on code.google.com by [email protected]
on 11 Aug 2014 at 5:10
Attachments:
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.
Original issue reported on code.google.com by schnetter
on 5 May 2013 at 3:30
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 5 Oct 2011 at 10:06
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 1 Aug 2014 at 5:56
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 6 Nov 2012 at 12:07
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.
Original issue reported on code.google.com by [email protected]
on 5 Aug 2014 at 8:04
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)
Original issue reported on code.google.com by [email protected]
on 4 Feb 2014 at 12:36
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
Original issue reported on code.google.com by [email protected]
on 2 Dec 2013 at 5:13
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 21 May 2012 at 10:15
Attachments:
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
Original issue reported on code.google.com by [email protected]
on 29 Dec 2011 at 1:17
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).
Original issue reported on code.google.com by [email protected]
on 26 Dec 2011 at 3:08
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 7 Dec 2012 at 8:24
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? ;) )
Original issue reported on code.google.com by [email protected]
on 24 Aug 2013 at 6:17
Attachments:
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
}}}
Original issue reported on code.google.com by schnetter
on 5 May 2013 at 3:23
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 );
Original issue reported on code.google.com by [email protected]
on 6 Aug 2012 at 2:17
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
Original issue reported on code.google.com by [email protected]
on 18 Sep 2011 at 4:40
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.
Original issue reported on code.google.com by [email protected]
on 2 Mar 2015 at 5:14
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
Original issue reported on code.google.com by [email protected]
on 29 Dec 2011 at 1:14
Attachments:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.