OpenCL is the best.

Moderator: dar

Re: OpenCL is the best.

Postby Dade » Mon Dec 17, 2012 5:09 pm

jar wrote:Also included is a lightweight interface to OpenCL, called Standard Compute Layer (STDCL), that should ease the development of new codes and new programmers. For those of you that have written OpenCL codes, you know how verbose the API can be.


I agree, writting an OpenCL application in plain C is a slow and annoying process however I have used, for a long time, OpenCL C++ binddings and they do a good job in semplifying the work. OpenCL C++ binddings consist in just an header available directly from Khronos: http://www.khronos.org/registry/cl/api/1.2/cl.hpp

BTW, anyone has "clinfo" ouput of Epiphany OpenCL ?
User avatar
Dade
 
Posts: 26
Joined: Sun Dec 16, 2012 8:59 pm

Re: OpenCL is the best.

Postby Ariemeth » Mon Dec 17, 2012 5:56 pm

Dade wrote:I agree, writting an OpenCL application in plain C is a slow and annoying process however I have used, for a long time, OpenCL C++ binddings and they do a good job in semplifying the work. OpenCL C++ binddings consist in just an header available directly from Khronos: http://www.khronos.org/registry/cl/api/1.2/cl.hpp

I couldn't agree more. The C++ wrapper was weak the last time I looked at it about a year ago and I can only assume and hope it has improved. At the time it was a little verbose, though a little C++11 could have helped a lot.
Ariemeth
 
Posts: 6
Joined: Mon Dec 17, 2012 3:26 am

Re: OpenCL is the best.

Postby jar » Mon Dec 17, 2012 6:25 pm

Ariemeth wrote:The C++ wrapper was weak the last time I looked at it about a year ago and I can only assume and hope it has improved

Unfortunately, it hasn't. It's still basically a wrapper and doesn't seem to simplify code compared to the OpenCL C API.

Dade wrote:BTW, anyone has "clinfo" ouput of Epiphany OpenCL ?

If you look at the libcoprthr-e device code (line ~131), you'll get all the numbers that would appear from clinfo. It's just hard coded for the 16-core Epiphany chip. Obviously, this will have to change with newer architectures...

Code: Select all
   dtab[0].imp = (struct _imp_device){
      CL_DEVICE_TYPE_ACCELERATOR,
      0,            /* vendorid */
      1,            /* max_compute_units */
      3,            /* max_wi_dim */
      1024,1024,1024,0,   /* max_wi_sz[] */
      16,            /* max_wg_sz */
      4,2,1,8,1,8,   /* pref_char/short/int/long/float/double/n */
      0,            /* max_freq */
      32,         /* bits */
      1024*1024*1024,      /* max_mem_alloc_sz */
      CL_FALSE,   /* supp_img */
      0,0,          /* img_max_narg_r, img_max_narg_w */
      0,0,         /* img2d_max_width, img2d_max_height */
      0,0,0,      /*  img3d_max_width, img3d_max_height, img3d_max_depth */
      0,          /* max_samplers */
      256,          /* max_param_sz */
      64,          /* mem_align_bits */
      8,          /* datatype_align_sz */
      CL_FP_ROUND_TO_NEAREST|CL_FP_INF_NAN, /* single_fp_config */
      CL_NONE,    /* global_mem_cache_type */
      0,          /* global_mem_cacheline_sz */
      0,          /* global_mem_cache_sz */
      16777216-16384,       /* global_mem_sz */
      65536,       /* cl_ulong max_const_buffer_sz */
      8,          /* max_const_narg */
      CL_LOCAL,    /* local_mem_type */
      32768,          /* local_mem_sz */
      CL_FALSE,   /* supp_ec */
      0,          /* prof_timer_res */
      CL_TRUE,      /* endian_little */
      CL_FALSE,    /* avail */
      CL_TRUE,   /* compiler_avail */
      CL_EXEC_KERNEL,   /* supp_exec_cap */
      CL_QUEUE_PROFILING_ENABLE, /* cmdq_prop */
      (cl_platform_id)(-1),   /* platformid */
      0,    /* name */
      0,    /* vendor */
      0,    /* drv_version */
      0,    /* profile */
      0,    /* version */
      0,      /* extensions */
      0,0    /* dstrtab, dstrtab_sz */
   };
User avatar
jar
 
Posts: 295
Joined: Mon Dec 17, 2012 3:27 am

Re: OpenCL is the best.

Postby Dade » Mon Dec 17, 2012 9:20 pm

jar wrote:
Dade wrote:BTW, anyone has "clinfo" ouput of Epiphany OpenCL ?

If you look at the libcoprthr-e device code (line ~131), you'll get all the numbers that would appear from clinfo. It's just hard coded for the 16-core Epiphany chip. Obviously, this will have to change with newer architectures...

Code: Select all
   dtab[0].imp = (struct _imp_device){
      CL_DEVICE_TYPE_ACCELERATOR,
      0,            /* vendorid */
      1,            /* max_compute_units */
      3,            /* max_wi_dim */
      1024,1024,1024,0,   /* max_wi_sz[] */
      16,            /* max_wg_sz */
      4,2,1,8,1,8,   /* pref_char/short/int/long/float/double/n */
      0,            /* max_freq */
      32,         /* bits */
      1024*1024*1024,      /* max_mem_alloc_sz */
      CL_FALSE,   /* supp_img */
      0,0,          /* img_max_narg_r, img_max_narg_w */
      0,0,         /* img2d_max_width, img2d_max_height */
      0,0,0,      /*  img3d_max_width, img3d_max_height, img3d_max_depth */
      0,          /* max_samplers */
      256,          /* max_param_sz */
      64,          /* mem_align_bits */
      8,          /* datatype_align_sz */
      CL_FP_ROUND_TO_NEAREST|CL_FP_INF_NAN, /* single_fp_config */
      CL_NONE,    /* global_mem_cache_type */
      0,          /* global_mem_cacheline_sz */
      0,          /* global_mem_cache_sz */
      16777216-16384,       /* global_mem_sz */
      65536,       /* cl_ulong max_const_buffer_sz */
      8,          /* max_const_narg */
      CL_LOCAL,    /* local_mem_type */
      32768,          /* local_mem_sz */
      CL_FALSE,   /* supp_ec */
      0,          /* prof_timer_res */
      CL_TRUE,      /* endian_little */
      CL_FALSE,    /* avail */
      CL_TRUE,   /* compiler_avail */
      CL_EXEC_KERNEL,   /* supp_exec_cap */
      CL_QUEUE_PROFILING_ENABLE, /* cmdq_prop */
      (cl_platform_id)(-1),   /* platformid */
      0,    /* name */
      0,    /* vendor */
      0,    /* drv_version */
      0,    /* profile */
      0,    /* version */
      0,      /* extensions */
      0,0    /* dstrtab, dstrtab_sz */
   };


Thank you, very interesting. It looks like Epiphany memory is shown like local memory (32k) while ARM memory is shown as global memory (1MB).
User avatar
Dade
 
Posts: 26
Joined: Sun Dec 16, 2012 8:59 pm

Re: OpenCL is the best.

Postby Gedece » Mon Dec 17, 2012 9:24 pm

I'm already looking into Python with OpenCL, so far PyOpenCL seems the way to go.
User avatar
Gedece
 
Posts: 23
Joined: Mon Dec 17, 2012 3:18 am
Location: Buenos Aires, Argentina

Re: OpenCL is the best.

Postby jar » Tue Dec 18, 2012 2:20 am

OpenCL is great and all, but it's really meant for GPUs. It has language within the standard that doesn't even apply to the Epiphany architecture or other multi-core CPUs.

For example, Epiphany doesn't have OpenCL Local Memory, Constant Memory, Caches, or multiple Compute Units. Instead there is a single Compute Unit built from many Processing Elements which each have a very large amount of Private Memory compared to GPUs. OpenCL also lacks a mechanism for moving data between Processing Elements' Private Memory. The term "Private Memory" is obviously a bit of a misnomer here when it is being shared between Processing Elements. See the overly simplified, cheesy diagram attachment below.

The Epiphany architecture has this Private Memory sharing capability in hardware and is used to extend the OpenCL specification with the memaddr/memcopy/memsync/memsend/memrecv routines found in e32_opencl_ext.h. Data moved between neighboring Processing Elements in the 2D grid or off-chip to the shared host memory (OpenCL Global Memory).

So the OpenCL model is used where it applies to using Epiphany as a coprocessor/accelerator. And OpenCL is extended where it is lacking obvious capabilities.

See the OpenCL Matrix Multiply example that uses Private Memory sharing routines.
Attachments
OpenCLvsEpiphany.png
OpenCLvsEpiphany.png (87.22 KiB) Viewed 16415 times
User avatar
jar
 
Posts: 295
Joined: Mon Dec 17, 2012 3:27 am

Re: OpenCL is the best.

Postby calufrax » Tue Dec 18, 2012 12:48 pm

The Hetereogeneous Parallel Programming course currently running on Coursera will apparently cover OpenCL... It's geared toward CUDA, but OpenCL is on the syllabus, and the general principles would still apply.

I'd love to see a MOOC course geared toward Epiphany, of course... That would be a way to promote the hardware, and get the impetus for software development...
calufrax
 
Posts: 1
Joined: Mon Dec 17, 2012 3:20 am

Re: OpenCL is the best.

Postby dar » Wed Dec 19, 2012 5:29 pm

Dade wrote:I'm looking forward to OpenCL support too :D

BTW, is there going to be an "official" OpenCL SDK for Parallella or the community is going to need a port of one of the open source version available ?


Parallella will be supported by the COPRTHR SDK as of thenext release (v1.5) that will be available before most people get their boards. Not sure what makes this "official" but for all practical purposes this will be the official OpenCL SDK. The SDK provides OpenCL support and also includes a long list of first and only features that we believe many in the community will find useful. And best of all, its open-source and free to the community.
dar
 
Posts: 90
Joined: Mon Dec 17, 2012 3:26 am

Re: OpenCL is the best.

Postby dar » Wed Dec 19, 2012 5:51 pm

Macros, C++ bindings, PyOpenCL, and "solving a problem that doesn't exist" ... where to begin.

First, regarding macro discussion, they are used in stdio.h. All serious code uses macros. Nots sure what the issue is there.

OpenCL is a really useful API. Its also not the best API for all programmers to use directly. (Its also a GPU API, not a multicore API, but that's another discussion.) If you are an OpenGL programmer you may very well not see the problem STDCL "solves". If you are a CUDA programmer its obvious. We (BDT) have received enough praise for developing libstdcl to know that we did some things right. Perhaps you want to use C++ bindings. Perhaps you want to use Python. Every programmer will have their own preferences. What makes the Parallella project exciting is that its completely open and the community will be able provide solutions to problems without vendor approval, or worst, waiting for a vendor to get around to providing a solution. We are looking forward to providing support for Parallella in our COPRTHR SDK. We have some very exciting features planned that we hope will contribute to the Parallella community.
dar
 
Posts: 90
Joined: Mon Dec 17, 2012 3:26 am

Re: OpenCL is the best.

Postby Ariemeth » Thu Dec 20, 2012 2:52 am

rethought
Last edited by Ariemeth on Thu Dec 20, 2012 1:57 pm, edited 1 time in total.
Ariemeth
 
Posts: 6
Joined: Mon Dec 17, 2012 3:26 am

PreviousNext

Return to OpenCL

Who is online

Users browsing this forum: No registered users and 1 guest

cron