browndeer / coprthr Goto Github PK

The current implementation seems to report a wrong line number for any error in a kernel. It looks like a constant offset: it is always the right line number +2.

The system libelf and "legacy" libelf conflict on compilation under Arch Linux. Forcing to compile with just legacy-libelf under 32-bit fails as legacy-libelf does not define Elf32_Xword -- saying in a source file that there is no such thing ({libelf_path}/src/lib/32.size.c). The system libelf on Arch (from elfutils) defines Elf32_Xword as uint64 (same as Elf64_Xword), and this is confirmed in the elf(5) manpage (http://man7.org/linux/man-pages/man5/elf.5.html).

From previous discussions here and looking at the source, it seems Android is currently the only platform that deviates from this definition (please correct me if I'm wrong).

Therefore, perhaps it'd be best to define Elf_Xword as Elf64_Xword for 64 and 32-bit platforms, and have Android cross-compilation typedef Elf64_Xword as Elf32_Word

Compiling an OpenCL kernel with epiphany sdk calls such as e_dma_copy causes an error because a call to e-gcc includes the -I switch with the argument "/opt/adapteva/esdk/tools/e-gnu/epiphany-elf/sys-include" rather than "/opt/adapteva/esdk/tools/e-gnu/epiphany-elf/include".

The output of cldebug -t includes the following line:

[4020] clmesg debug: computil_e32.h(560): execshell> cd /home/parallella/Work/mpi-epiphany/nbody/temp/xclXi1agR; e-gcc -O0 -g -Wall -c -fmessage-length=0 -ffast-math -ftree-vectorize -funroll-loops -Wunused-variable -ffp-contract=fast -mlong-calls -mfp-mode=round-nearest -w -fstack-usage -fno-exceptions -U_FORTIFY_SOURCE -fno-stack-protector -I/opt/adapteva/esdk/tools/e-gnu/epiphany-elf/sys-include -fpermissive -D__coprthr_device__ -DE32_DRAM_ZEROPAGE=0x8e100000 -I/usr/local/browndeer/include -D__xcl_kcall__ --include=e32pth_if_needham.h -c _kcall3_StLSBy.c -o e32_kcall3_StLSBy.o

Using version 1.6.2 with the 2015.1 build.

Full debug output is attached:
clDebugMinusT.txt

Running a simple OpenCL C++ example - works fine when libocl is configured to use ICD, but when configured to use RPC it segfaults in clGetPlatformInfo.

Any ideas?

Program received signal SIGSEGV, Segmentation fault.
clGetPlatformInfo (a0=0x7fed582ae10, a1=2305, a2=0, a3=0x0, a4=0x7fffffffdba0) at oclcall.c:192
192     void* oclent 
(gdb) bt
#0  clGetPlatformInfo (a0=0x7fed582ae10, a1=2305, a2=0, a3=0x0, a4=0x7fffffffdba0) at oclcall.c:192
#1  0x0000000000401847 in cl::detail::getPlatformVersion (platform=0x7fed582ae10)
    at /usr/include/CL/cl.hpp:1693
#2  0x00000000004018ef in cl::detail::getDevicePlatformVersion (device=0x60bfe0)
    at /usr/include/CL/cl.hpp:1703
#3  0x0000000000402200 in cl::detail::Wrapper<_cl_device_id*>::isReferenceCountable (device=0x60bfe0)
    at /usr/include/CL/cl.hpp:1794
...

Example program:

#include <CL/cl.hpp>
#include <cstdio>
#include <cstdlib>
#include <iostream>

 int
 main(void)
 {
    cl_int err = CL_SUCCESS;
    try {

      //get platform list 
      std::vector<cl::Platform> platforms;
      cl::Platform::get(&platforms);
      std::cout << "Platform size " << platforms.size() << std::endl;
      if (platforms.size() == 0) {
          return -1;
      }

      std::string platformVendor;
      platforms[0].getInfo((cl_platform_info)CL_PLATFORM_VENDOR, &platformVendor);
      std::cout << "Platform 0 is by: " << platformVendor << "\n";

      //get context for the first platform
      std::cout << "Platform 0: # " << platforms[0]() << std::endl;
      cl_context_properties properties[] = 
          { CL_CONTEXT_PLATFORM, (cl_context_properties)(platforms[0])(), 0};
      cl::Context context(CL_DEVICE_TYPE_ALL, properties); 

      //this line causes a seg fault at clGetPlatformInfo with RPC
      std::vector<cl::Device> devices = context.getInfo<CL_CONTEXT_DEVICES>();


      std::cout << "Done" << std::endl;
    }
    catch (cl::Error err) {
       std::cerr 
          << "ERROR: "
          << err.what()
          << "("
          << err.err()
          << ")"
          << std::endl;
    }

   return EXIT_SUCCESS;
 }

Compiling this (http://code.google.com/p/ocltoys/source/browse/mandelgpu/rendering_kernel_float4.cl) kernel on a Parallella board, I receive the following errors:

[OCLToy] Kernel compilation error:
aZx7wJ.cpp: In function ‘void mandelGPU(uint*, int, int, float, float, float, int)’:
aZx7wJ.cpp:48:33: error: no matching function for call to ‘_float4::_float4(const int&)’
aZx7wJ.cpp:48:33: note: candidates are:
In file included from :0:0:
/usr/local/browndeer/include/opencl_lift.h:442:3: note: _float4::_float4()
/usr/local/browndeer/include/opencl_lift.h:442:3: note: candidate expects 0 arguments, 1 provided
/usr/local/browndeer/include/opencl_lift.h:442:3: note: _float4::_float4(const _float4&)
/usr/local/browndeer/include/opencl_lift.h:442:3: note: no known conversion for argument 1 from ‘const int’ to ‘const _float4&’
aZx7wJ.cpp:49:36: error: conversion from ‘float’ to non-scalar type ‘const float4 {aka const _float4}’ requested
aZx7wJ.cpp:50:36: error: conversion from ‘float’ to non-scalar type ‘const float4 {aka const _float4}’ requested
aZx7wJ.cpp:52:62: error: no matching function for call to ‘_uint4::_uint4(int)’
aZx7wJ.cpp:52:62: note: candida
[OCLToy] OpenCL ERROR: clBuildProgram(CL_BUILD_PROGRAM_FAILURE)
[7133] clmesg info: cmdsched.c(193): cmdqx0: shutdown

It looks like COPRTHR is missing scalar-to-vector conversion functions.

The same kernel works fine on AMD, NVIDIA, Intel, Apple OpenCL.

If an application passes in OpenCL specific compiler flags when using libcoprthr_opencl (such as "-cl-strict-aliasing" or any of the ones listed here https://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/clBuildProgram.html), these will be passed straight to gcc/g++, which will throw an "unrecognized option" error and not output the needed program.

This seems to result in an empty elf file that causes elfcl_write to signal SIGABRT from malloc (at least from my cursory backtraces and stracing).

The prototype Parallella systems are distributed with SSD cards containing Linaro Ubuntu 12.03. It is based on Ubuntu 11.10 oneiric.

That OS ships with libconfig8. The newer libconfig9 is not available. Your test suite requires libconfig9.

Either you need to use 8 or Adapteva needs to ship a newer OS.

Are there currently any plans to implement some of the more standard extensions?

Specifically, I was wondering about cl_khr_fp64 (needed for some scientific kernels).

It appears that double2, double4, and double8 are implemented already, which means this is just missing double16. The only platform supported that does not have double precision is the Epiphany, I think, and in that case e-gcc does support soft emulation.

Try to use it in win32 under win7, the changes are mainly the "_WIN64" to "WIN32" and to move the declarations to the front part of each function to make it work in vs2010, seems fine untill coming to the "unresolved external symbol "__declspec(dllimport) struct _clcontext_ptr_struct * stdcpu" (_imp?stdcpu@@3PAU_clcontext_ptr_struct@@A)" (same for stdgpu...) in the hello_stdcl example, but the .lib has been successfully built under vs2010, any tip pls? has defined the "STDCPU" to 0 and "STDGPU_PLATFORM_NAME" to "nvidia" in environment setting in win7.

Hi,

I'm currently trying to get any kind of PRNG to compile via COPRTHR, but so far I am having absolutely no luck.

Specifically, I am trying to get this to work: http://cas.ee.ic.ac.uk/people/dt10/research/rngs-gpu-mwc64x.html
The problem I am facing at the moment is the following:

/mwc64x/mwc64x_rng.cl:23:33: error: ‘mad_hi’ was not declared in this scope
  uint Cn=mad_hi(MWC64X_A,X,carry);  

It appears that neither mad_hi nor mul_hi are defined when I try to compile this in an OpenCL kernel via clcc.

I would like to point out that identifiers like "__printcl_level" and "_VERSION_H" do eventually not fit to the expected naming convention of the C language standard.
Would you like to adjust your selection for unique names?

I've just tried to install the Parallella version of 1.5.0 from the tarball on your website. The install script expects a directory named "icd" in the distribution. That directory was not included.

I want to execute an OpenCL kernel multiple times. I modified hello-opencl example as follows:

for(i = 0; i < 5; i++){
      clEnqueueNDRangeKernel(cmdq,krn,1,0,gtdsz,ltdsz,0,0,&ev[0]);
      clEnqueueReadBuffer(cmdq,c_buf,CL_TRUE,0,c_sz,c,0,0,&ev[1]);
      err = clWaitForEvents(2,ev);
}

It sometimes works, sometimes the terminal freezes up somewhere within the code and the operating system crashes.

The reason may be that memory is not freed properly.

During running the loop, I get the following error after a while (sometimes also the operating system crashes):

hello-opencl.elf: e_alloc(): mmap failure.
hello-opencl.elf:
ERROR: Can't allocate external memory buffer!

[2931] clmesg WARNING: e32pth_engine_needham.c(360): hardcoded to devnum=0

I am currently trying to move existing OpenCL code to the Parallella.
The code includes a MWC pseudo-random number generator (http://cas.ee.ic.ac.uk/people/dt10/research/rngs-gpu-mwc64x.html).

The code compiles via clcc when targeting a generic Intel CPU platform, without warnings.
When compiling on the Parallella, I get a lot of warnings regarding truncation/overflow of integers. The problem is: those all refer to proper usage of ulong, which should be 64 bit, according to the OpenCL standard.

Is ulong 64bit on the Epiphany target?

I was trying out COPRTHR on Parallella and needed to debug some issues. If I run the debugger with a local directory to output its work progress like cldebug -t temp -- <programfilename>, I got quite a few errors along the line of cpp: fatal error: no input files. Looking at the commands the problem is that first the code cd into the work directory, but within there it executes the follow-up commands with the full relative file path (from before cd) instead of just the base file name. See for example this build log. An excerpt:

[16048] clmesg debug: computil_e32.h(560): execshell> cd temp/xcl6eUI59; cpp -x c++  -D__coprthr_device__  -I/usr/local/browndeer/include temp/xcl6eUI59/eman39.cl   | awk -v prog=\"temp/xcl6eUI59/eman39.cl\" 'BEGIN { pr=0; } {    if($0~/^#/ && $3==prog) pr=1;   else if ($0~/^#/) pr=0;   if ($0!~/^#/ && pr==1) print $0; }' | xclnm --kcall -d -c -o _kcall_eman39.c - 
cpp: error: temp/xcl6eUI59/eman39.cl: No such file or directory
cpp: warning: ‘-x c++’ after last input file has no effect
cpp: fatal error: no input files
compilation terminated.

As I check, temp/xcl6eUI59/eman39.cl exists, but at that point cpp should be looking for eman39.cl instead, because it just cd'd into temp/xcl6eUI59/ a moment earlier...

Any thoughts on this? I'm using the stable-1.6.2 branch.

Would you like to add the configuration script "AX_PTHREAD" to your build specification?

add support for creating stdcl buffers from gl textures.

I'm trying to get the library to compile under cygwin. I built the dependent libraries from source, and have all the lib*.a files (though it looks like the .so gets mangled by cygwin). I made a couple of small tweaks to get most of it to compile, but getting stuck with the error below. Any ideas?

$ make
make -C src/libocl
make[1]: Entering directory '/home/steve/coprthr/src/libocl'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/steve/coprthr/src/libocl'
make -C src/libclrpc
make[1]: Entering directory '/home/steve/coprthr/src/libclrpc'
cc -g -O2 -g -O2 -fPIC -o clrpcd clrpcd.o clrpc.gen.o   -lpthread -ldl -lrt  -L/usr/local/lib -levent -levent_pthreads -levent_pthreads -L/usr/local/lib -lconfig \
        -L../libocl -locl -L. -lclrpc
../libocl/libocl.a(libocl.o): In function `read_oclconf_info':
/home/steve/coprthr/src/libocl/libocl.c:654: undefined reference to `config_init'
/home/steve/coprthr/src/libocl/libocl.c:654:(.text+0x7f4): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `config_init'
...

Looks like libocl.a gets built fine, but for some reason the link with libconfig is failing?

Also, are you interested in providing cygwin compatibility in general? I'd be happy to send you a pull request for any changes when I'm done.

thanks
Steve

I'm using Coprthr SDK on Ubuntu 11.04 32bit (Ubuntustudio). all standard example works fine but when i try to bulid the Clete examples i encounter this issue:

g++ -O3 -fpermissive -I/usr/local/cuda/include -I/usr/local/browndeer/include -c clete_clvector_example.cpp
In file included from /usr/local/browndeer/include/clvector.h:101:0,
from clete_clvector_example.cpp:21:
/usr/local/browndeer/include/CLETE/clvector_CLETE.h: In function ‘void evaluate(clvector<T, Allocator>&, const Op&, const Expression&)’:
/usr/local/browndeer/include/CLETE/clvector_CLETE.h:392:13: warning: there are no arguments to ‘exit’ that depend on a template parameter, so a declaration of ‘exit’ must be available
clete_clvector_example.cpp: In function ‘int main()’:
clete_clvector_example.cpp:42:11: error: no match for ‘operator+’ in ‘a + b’
/usr/include/c++/4.5/bits/stl_bvector.h:264:3: note: candidates are: std::_Bit_iterator std::operator+(ptrdiff_t, const std::_Bit_iterator&)
/usr/include/c++/4.5/bits/stl_bvector.h:350:3: note: std::Bit_const_iterator std::operator+(ptrdiff_t, const std::Bit_const_iterator&)
clete_clvector_example.cpp:42:25: error: no match for ‘operator’ in ‘2.112e+3f * b’
clete_clvector_example.cpp:42:35: error: no matching function for call to ‘sqrt(clvector&)’
/usr/include/bits/mathcalls.h:157:1: note: candidates are: double sqrt(double)
/usr/include/c++/4.5/cmath:438:3: note: long double std::sqrt(long double)
/usr/include/c++/4.5/cmath:434:3: note: float std::sqrt(float)
clete_clvector_example.cpp:42:41: error: no match for ‘operator’ in ‘a * b’
clete_clvector_example.cpp:42:57: error: no matching function for call to ‘sqrt(clvector&)’
/usr/include/bits/mathcalls.h:157:1: note: candidates are: double sqrt(double)
/usr/include/c++/4.5/cmath:438:3: note: long double std::sqrt(long double)
/usr/include/c++/4.5/cmath:434:3: note: float std::sqrt(float)
clete_clvector_example.cpp:42:68: error: no matching function for call to ‘cos(clvector&)’
/usr/include/bits/mathcalls.h:64:1: note: candidates are: double cos(double)
/usr/include/c++/4.5/cmath:204:3: note: long double std::cos(long double)
/usr/include/c++/4.5/cmath:200:3: note: float std::cos(float)
clete_clvector_example.cpp:43:21: error: no matching function for call to ‘fabs(clvector&)’
/usr/include/bits/mathcalls.h:182:1: note: candidates are: double fabs(double)
/usr/include/c++/4.5/cmath:252:3: note: long double std::fabs(long double)
/usr/include/c++/4.5/cmath:248:3: note: float std::fabs(float)
make: *** [clete_clvector_example.o] Error 1

any idea? i have also installed clld and LLVM-ex and also all libraries suggested (libelf clang...)

Would you like to add more error handling for return values from functions like the following?

• malloc ⇒ __do_discover_devices_1
• pthread_mutex_init ⇒ __coprthr_init_event

COPRTHR returns the following string a result of CL_PLATFORM_VERSION:

coprthr-1.5.0-RC1 (Marathon)

This doesn't match OpenCL specs (http://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/clGetPlatformInfo.html) and can be the source of problems with code that decides what kernel to run based on platform OpenCL version.

The CL_DEVICE_VERSION seems also to return an empty string.

At compile time and run time the version number says "1.6.0 (Freewill)" or "coprthr-1.6.0 (Freewill)"

It would be useful if your install document for Parallella noted that you can't just type "gmake quicktest". You must first issue the following lines:

sudo ln -s /usr/bin/make /usr/bin/gmake
sudo apt-get install libelf1 libelfg0 libconfig9

In a separate issue I talk about the fact that the install of libconfig9 will fail.