Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenCL instead of manual thread and sync managment #7

Closed
9il opened this issue Sep 22, 2016 · 7 comments
Closed

OpenCL instead of manual thread and sync managment #7

9il opened this issue Sep 22, 2016 · 7 comments
Labels

Comments

@9il
Copy link
Member

9il commented Sep 22, 2016

@thewilsonator The first GLAS release will be single thread. Current druntime is useless for GLAS because it is not nothrow @nogc.

  1. Will it be possible to use dcompute for CPU execution ?
  2. Can dot_reg_basic internal/gemm use llvm prefetch as openCL kernel?
  3. Do SIMD vectors supported?
@9il 9il added the question label Sep 22, 2016
@thewilsonator
Copy link
Collaborator

thewilsonator commented Sep 22, 2016

  1. yes, you can be both host and device at the same time.
  2. I think so. see "Async Copies and Prefetch" and "Vector Data Load/Store" sections of the OpenCL quick reference cards.
  3. yes the vectors in openCL are the same vectors as std.simd, i.e. llvm vectors.

With the caveat that the names are mangled with C++ mangling so will need to pragma mangle them.

@9il
Copy link
Member Author

9il commented Sep 22, 2016

Whoohooooo! When do you think dcompute be ready enough to start porting GLAS?

@thewilsonator
Copy link
Collaborator

I'll try to rebase my compiler fork over the weekend and get it into ldc ASAP. It's probably ready to START porting but some of the prototypes are missing (there is a table somewhere on khronos's github that has all the mangling), so I don't know how far you'll get.

But the driver API has a long way to go, in terms of easy use. Use should be able to use OpenCL 1.2 with the load binary if you

  1. compile with spirv using Khrono's 3.6 or 3.8 branch of llvm
  2. convert it back to llvm.bc and then run it through the 3.3(?) llvm-spriv tool

@9il
Copy link
Member Author

9il commented Sep 22, 2016

I'll try to rebase my compiler fork over the weekend and get it into ldc ASAP. It's probably ready to START porting but some of the prototypes are missing (there is a table somewhere on khronos's github that has all the mangling), so I don't know how far you'll get.

Would it be possible to compiler a kernel with the program itself in the future? (I remember that GPU kernels compiled runtime)

@9il
Copy link
Member Author

9il commented Sep 22, 2016

I think that dcompute has amazing opportunities and we can consider on LDC support only and drop DMD support https://github.com/ljubobratovicrelja/dcv/issues/52

@thewilsonator
Copy link
Collaborator

Would it be possible to compiler a kernel with the program itself in the future? (I remember that is GPU kernels compiled runtime)

Not quite sure what you mean. dcompute kernels are compiled with the rest of the program i.e. "offline", it's the OpenCL C compiler (.cl source files) that are compiled at runtime. You could if you really wanted to invoke the compiler at runtime and the load the resulting file.

Too tired, that is the default and only way to compile (except doing things as above).

@9il
Copy link
Member Author

9il commented Sep 22, 2016

dcompute kernels are compiled with the rest of the program i.e. "offline"

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants