ahayashi / chapel-gpu

GPUIterator for the Chapel language

Chapel-GPU: GPUIterator and GPUAPI module for Chapel

Documents

Detailed description of the modules can be found here.

License

The GPUIterator and GPUAPI modules are developed and released under the terms of the Apache 2.0 license. See the LICENSE file in this directory for details.

Further Readings

• "GPUIterator: Bridging the Gap between Chapel and GPU Platforms", Akihiro Hayashi, Sri Raj Paul, Vivek Sarkar, The ACM SIGPLAN 6th Annual Chapel Implementers and Users Workshop (CHIUW), June 2019. (co-located with PLDI2019/ACM FCRC2019). slides.
• "Exploring a multi-resolution GPU programming model for Chapel" Akihiro Hayashi, Sri Raj Paul, Vivek Sarkar, The 7th Annual Chapel Implementers and Users Workshop (CHIUW), May 2020.
• "GPUAPI: Multi-level Chapel Runtime API for GPUs" Akihiro Hayashi, Sri Raj Paul, Vivek Sarkar, The 8th Annual Chapel Implementers and Users Workshop (CHIUW), June 2021.
• "A Multi-Level Platform-Independent GPU API for High-Level Programming Models" Akihiro Hayashi, Sri Raj Paul, Vivek Sarkar, Workshop on HPC on Heterogeneous Hardware (H3), June 2022. (co-located with ISC2022) (Post-workshop proceedings will be available soon).
• "Accelerating CHAMPS on GPUs" Akihiro Hayashi, Sri Raj Paul, Vivek Sarkar, The 9th Annual Chapel Implementers and Users Workshop (CHIUW), June 2022.

chapel-gpu's Issues

GPUIterator and GPU Kernel Generation in Chapel via symbolic variables [Idea; Collaboration?]

Hello, developers of the GPUIterator!

I was thinking that perhaps this is a way to either provide as an idea or a potential point of collaboration for improving GPU support in Chapel. A while ago, I was working on a side-project that utilized symbolic variables to generate GPU kernels in Chapel, allowing users to write Chapel-idiomatic code that will run on the GPU: https://github.com/LouisJenkinsCS/ChapelCL

For example, I had envisioned that something like this...

var D = {1..N} dmapped Symbolic();
var dA : [D] real(32);
var dB : [D] real(32);
forall (a, b) in zip(dA, dB) {
   a = b;
}

Or even better

var D = {1..N} dmapped Symbolic();
var dA : [D] real(32);
var dB : [D] real(32);
dA = dB;

Which would generate the following...

// CUDA kernel for Vector Copy
__global__ void vc(float *dA, float *dB, int N) {
    int id = blockIdx.x * blockDim.x + threadIdx.x;
    if (id < N) {
	  dA[id] = dB[id];
    }
}

The Symbolic would correspond to the SymbolicDist, which would essentially create a distribution for an array that internally tracked the size of the array and returned a reference to a symbolic variable when iterated over or when indexed into that recorded certain actions, such as the operations +, -, *, /, etc.

My hope was that you could write something like the above to create a GPU kernel, but with your own GPUIterator, I'm thinking that this generated GPU kernel could be fed directly to your GPUIterator.

Unfortunately things like handling device-to-host and host-to-device transfers have not been implemented yet, but they were planned. Unfortunately I do not have the time to devote to do a solo project of this magnitude, despite how cool it sounds to me. Hopefully your research group will be interested in continuing the work or in collaboration?

Edit:

I should mention that the side-project is also mostly unfinished and only a basic proof-of-concept is working; I believe the last thing I did was create the AST (which gets generated based on operators applied to symbolic varialbes) and the SymbolicDist (symbolic array), but it showed that something like this can work in Chapel.

Compiler error

Hi,
Congratulations on the amazing work.
I am suffering some issues to compile an example:

CHPL_LOCALE_MODEL=gpu chpl --fast -M $CHPL_GPU_HOME/chapel-gpu/src vc.hybrid.chpl vc.gpu.o -lcudart -lcuda
error: Type 'chpl_localeID_t' must be defined in the Chapel internal modules.
error: Type 'chpl_comm_on_bundle_t' must be defined in the Chapel internal modules.
error: Type 'chpl_task_bundle_t' must be defined in the Chapel internal modules.

My chapel is:

chpl version 1.20.0
Copyright (c) 2004-2019, Cray Inc.  (See LICENSE file for more details)

nvcc is:

nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2017 NVIDIA Corporation
Built on Fri_Sep__1_21:08:03_CDT_2017
Cuda compilation tools, release 9.0, V9.0.176

I am using clang-3.9. I can compile Cuda 9 programs and works pretty well;

I am using ubuntu 18.04 LTS.
Can you give me some tips to solve such an issue?
Thanks.