OpenCL does not compile on Parallella but does on Intel

Moderator: dar

OpenCL does not compile on Parallella but does on Intel

Postby imrehg » Mon Jun 15, 2015 4:06 pm

Hi,

I'm trying to get some OpenCL code working on Parallella, and I'm a bit lost, with a lot of questions. I'll try to dump the story here, maybe someone has some pointers for me. There are so many strange parts, that I'm not exactly sure what's relevant to fix it.

The program: I'm trying to use the Epiphany to as an OpenCL ACCELERATOR to speed up calculation of a function, Bitmessage Proof-of-Work: concat a nonce with a hash, then do SHA512 twice, and cast the first 8 bytes into a number, repeat until that number is below a target value. My development code is here on github, organized as:

  • Python script that sets up a known case (python2 testcl.py)
  • a C program, compiled as a dynamic library, called from Python, and sets up the OpenCL kernel (bmpow.c)
  • the OpenCL code do to the nonce search with double SHA512, copied from another developer (bitmessage-pow-opencl.cl)

If I compile things things on an Intel CPU (with their OpenCL SDK), everything works like a charm! (to do that, I just need to switch the libraries the Makefile, and switch the device type to CPU in bmpow.c). I have presumed this means that my code should be correct.

On the Parallella: when I try to compile things on the parallella, I run into a bunch of issues:

1) CPU type sizes: using the CL_DEVICE_TYPE_CPU, I get a bunch of "warning: large integer implicitly truncated to unsigned type" and "warning: left shift count >= width of type" messages in the .cl kernel. The code uses a bunch of "ulong" variables, so I guess it means that while I presumed ulong is 64bit, with this device type it is actually not? Is that even possible to have different variable type sizes for the different devices?

2) ACCELERATOR segfault: if I compile with CL_DEVICE_TYPE_ACCELERATOR, then it breaks with a Segmentation Fault in clBuildProgram. Any idea what am I doing wrong there? (especially because on Intel it compiles just fine)

3) ACCELERATOR debug compile: If I do a "cldebug -t temp -- ./testcl.py" to run the program in debug mode, the output is in this gist. "Error number -46" and "Error number -48" is invalid kernel name and invalid kernel according to cl.h, but not sure where that issue would come from. Also, in line 144 the command seems to be wrong and fails accordingly: the command cd into the temp directory, but the subsequent command uses the full file path which is then incorrect (resulting in a cpp: fatal error: no input files, original code in computil_e32.h). Does this make any difference?

4) Library linking: It's not totally clear whether I should be linking to "-lcoprthr_opencl" or "-locl", which one is correct / better?

(btw, I'm using COPRTHR stable-1.6.2 from Git, and the "make quicktest" seem to pass just fine. Is that the version I should be using?)

Any help is greatly appreciated!
User avatar
imrehg
 
Posts: 14
Joined: Mon Dec 17, 2012 3:25 am
Location: Taipei, Taiwan

Re: OpenCL does not compile on Parallella but does on Intel

Postby imrehg » Tue Jun 16, 2015 2:10 am

1) CPU type sizes: using the CL_DEVICE_TYPE_CPU, I get a bunch of "warning: large integer implicitly truncated to unsigned type" and "warning: left shift count >= width of type" messages in the .cl kernel. The code uses a bunch of "ulong" variables, so I guess it means that while I presumed ulong is 64bit, with this device type it is actually not? Is that even possible to have different variable type sizes for the different devices?


At least regarding this it looks like there's an issue already reported by someoneone the COPRTHR issue tracker. Just there's no update on for more than a year, so not sure what to think.
User avatar
imrehg
 
Posts: 14
Joined: Mon Dec 17, 2012 3:25 am
Location: Taipei, Taiwan

Re: OpenCL does not compile on Parallella but does on Intel

Postby jlambrecht » Tue Jun 23, 2015 6:29 pm

I'm not sure what to say but contacting the people writing the CORPHTR library seems like a good idea :)

Based on the little experience i have with compiling stuff it seems like you might have to recompile some of the Python stuff and/or other more low level stuff for Epiphany ?
jlambrecht
 
Posts: 41
Joined: Wed Nov 13, 2013 7:57 pm

Re: OpenCL does not compile on Parallella but does on Intel

Postby imrehg » Wed Jun 24, 2015 2:50 am

Yeah, I've been working on the COPRTHR side of things, and start to understand a few things. From my original questions, the library linking should be "-locl" because it pulls in the relevant library anyways. For some of the compile errors were either bugs or lack of documentation (depending on one's point of view) and some has been fixed.

The issue is in the C code, though, not Python, and I kinda think it's a combination of OpenCL incompatibilities between the different implementations + my lack of C skills so far. Will probably start from scratch and build up from there, instead of the 'copy-paste-ohthatworks" approach before. Let's see how that will work out :)
User avatar
imrehg
 
Posts: 14
Joined: Mon Dec 17, 2012 3:25 am
Location: Taipei, Taiwan

Re: OpenCL does not compile on Parallella but does on Intel

Postby imrehg » Wed Jun 24, 2015 3:16 pm

Well, a bit of a breakthrough. Trying to build things up from scratch, the main "segmentation error" is possibly coming from the code using "__constant", while the COPRTHR Parallella Quick Start Guide says that it is unsupported. (duh!)

The code I'm trying to run is basically SHA512, which uses __constant in its current form, any recommendation how that might be circumvented? Is there any other pattern that I can use to effectively have a look-up table available for the rest of the algorithm, but not as such a __constant?
User avatar
imrehg
 
Posts: 14
Joined: Mon Dec 17, 2012 3:25 am
Location: Taipei, Taiwan

Re: OpenCL does not compile on Parallella but does on Intel

Postby jlambrecht » Tue Jun 30, 2015 5:53 pm

Hmmm, sorry to say i lack relevant experience and/or expertise.

https://duckduckgo.com/?q=%22__constant%22&t=canonical

You seem to be on to something though, maybe make sure you're using the latest version from git or other upstream sources ?
jlambrecht
 
Posts: 41
Joined: Wed Nov 13, 2013 7:57 pm


Return to OpenCL

Who is online

Users browsing this forum: No registered users and 3 guests

cron