Page 1 of 1

Suggestions for COPRTHR-2

PostPosted: Mon May 02, 2016 3:14 pm
by CyberHiPriest
In some threads, I noticed some mentions of work being done on COPRTHR-2, an updated version of the SDK. So I thought I might tune in to give some suggestions to improve the OpenCL part.

General:
  • clcc option '-k' that keeps all intermediate files (.cpp, .S and .o files for each target seperatly) in the current working directory (instead of /tmp). This makes it easy to inspect generated code.
  • more OpenCL functions and variable support (float3, reflect, ... and many others); all OpenCL 1.2 functions/vars would be wonderful.
  • ability to pass my own CFLAGS/CXXFLAGS to the backend compiler for each target. Either adding to the flags with CFLAGS+="..." or completely replace them with CFLAGS="...". (where do those flags come from?)
  • a way to extend the opencl_lift.h file with my own C++ generic functions.

ARM specific:
  • a way to debug alignment traps that comes from the generated C++ code. (I don't know if its a bug or my faulty OpenCL code that is responsible)
  • Try to use the NEON engine for calculations

Epiphany specific:
  • Generate a warning when doubles are detected.
  • Generate a warning when 'common' code is generated; i.e. code that is run in the shared DRAM (=serious slowdown) like for example code that does calculations on doubles.
  • Instead of the standard math library used to implement sinf(), cosf() and many others, use the PAL functions (https://github.com/parallella/pal) or some other fast-appoximate version.
  • Support a clcc compile flag to indicate that the user wants COPRTHR to generate "precision" or "fast approximate" versions of functions. Precision could use the standard <cmath> library, Fast-approx could use the PAL one.
  • faster clforka(), when used in a loop. (I think it transfers the code to the Epiphany cores in every loop as well, needs only done once?)
  • profiling support?

Are these things doable? What do you guys think?

Re: Suggestions for COPRTHR-2

PostPosted: Tue May 03, 2016 1:29 am
by jar
OpenCL support is being deprecated in COPRTHR 2.0. It has been discussed at length on the forum why it is not a good programming model for the Epiphany architecture. I am not the developer but you csn always email him directly.

You might want to try out 2.0 since there are many good features. Many of the things you mentioned are already there. Others aren't so obvious. For example, you may want initialization code that is large but only called once to run out of shared DRAM. The tools for binary analysis are there and will enable you to control code placement better.

If you like having the OpenCL data types and functions, you can always pull in that header from 1.6 for a hybrid programming model. I do have a more complete version of it if I ever get around to releasing it. Many of the math functions could also be incorporated into the PAL library.

Re: Suggestions for COPRTHR-2

PostPosted: Tue May 03, 2016 3:39 am
by dar
Decision to deprecate OpenCL in COPRTHR-2.0 is not absolute. It is not a priority, will not be supported in the initial releases, and threaded MPI provides a much more efficient programming model. These suggestions are good and as JAR said many of these things have been addressed in COPRTHR-2.0.