www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - GPGPU work and Identifiers

reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
This thread is partly to announce that i will be adding to LDC 
the ability to generate code for GPUs through OpenCL, CUDA (and 
if i have time) Metal in my fork at 
https://github.com/thewilsonator/ldc and partly to request the 
reservation of the relevant Version identifiers. (Do I do this by 
a pull request?)

IIUC the version identifiers are based of the C #define's.
The OpenCL #define's are CL_VERSION_X_Y and __OPENCL_VERSION__ = 
XY0 (e.g. 220 for 2.2)
The cuda #define's are __CUDA__ and __CUDA_ARCH__ (similar to 
above but indicates the compute capability as opposed to the 
version)

BUT

That is sorta equivalent to the OS identifier. the arch 
identifier SPIR(V) and NVPTX and their 64bit counterparts are 
more indicative and useful to me earlier on (address space 
mapping and whatnot). So my question is what identifiers should i 
go with?
Jun 19 2016
parent reply Jakob Bornecrantz <wallbraker gmail.com> writes:
On Sunday, 19 June 2016 at 11:12:50 UTC, Nicholas Wilson wrote:

 This thread is partly to announce that i will be adding to LDC 
 the ability to generate code for GPUs through OpenCL, CUDA (and 
 if i have time) Metal in my fork at 
 https://github.com/thewilsonator/ldc and partly to request the 
 reservation of the relevant Version identifiers. (Do I do this 
 by a pull request?)


What is your current status?

Is that SPIR-V or SPIR? I tought that LLVM did not have a SPIR-V 
backend mainlined. Or are you using a out of tree one from 
Khronos?

Do you have any examples?

Cheers, Jakob.
Jun 19 2016
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Sunday, 19 June 2016 at 12:38:00 UTC, Jakob Bornecrantz wrote:

 On Sunday, 19 June 2016 at 11:12:50 UTC, Nicholas Wilson wrote:

 This thread is partly to announce that i will be adding to LDC 
 the ability to generate code for GPUs through OpenCL, CUDA 
 (and if i have time) Metal in my fork at 
 https://github.com/thewilsonator/ldc and partly to request the 
 reservation of the relevant Version identifiers. (Do I do this 
 by a pull request?)


 What is your current status?


Just starting. But I know what i need to do ( in terms of 
metadata)


 Is that SPIR-V or SPIR?


SPRI-V

 I tought that LLVM did not have a SPIR-V backend mainlined. Or 
 are you using a out of tree one from Khronos?


Yes


 Do you have any examples?


Not yet.

 Cheers, Jakob.
Jun 19 2016
parent reply Jakob Bornecrantz <wallbraker gmail.com> writes:
On Sunday, 19 June 2016 at 14:04:15 UTC, Nicholas Wilson wrote:

 On Sunday, 19 June 2016 at 12:38:00 UTC, Jakob Bornecrantz 
 wrote:

 On Sunday, 19 June 2016 at 11:12:50 UTC, Nicholas Wilson wrote:

 This thread is partly to announce that i will be adding to 
 LDC the ability to generate code for GPUs through OpenCL, 
 CUDA (and if i have time) Metal in my fork at 
 https://github.com/thewilsonator/ldc and partly to request 
 the reservation of the relevant Version identifiers. (Do I do 
 this by a pull request?)


 What is your current status?


 Just starting. But I know what i need to do ( in terms of 
 metadata)


Ah okay.


 Is that SPIR-V or SPIR?


 SPRI-V

 I tought that LLVM did not have a SPIR-V backend mainlined. Or 
 are you using a out of tree one from Khronos?


 Yes


That will be annoying, the LDC that works with SPIR-V wont be 
able to produce MSVC compatible exes. Lets hope they mainline it 
soon.

Thanks for the reply.

Cheers, Jakob.
Jun 19 2016
parent reply David Nadlinger <code klickverbot.at> writes:
On Sunday, 19 June 2016 at 18:23:06 UTC, Jakob Bornecrantz wrote:

 That will be annoying, the LDC that works with SPIR-V wont be 
 able to produce MSVC compatible exes. Lets hope they mainline 
 it soon.


One possible solution for this would be a thin driver executable 
that parses just enough of the command line to detect the target 
triple used, and then forwards to the correct "real" compiler 
executable.

Such a separate driver could then also be used as part of the 
regular distribution to improve the performance on 
memory-constrained all-at-once builds, by freeing all the 
frontend/LLVM memory (i.e., terminating the process) before 
invoking the linker, which can take a substantial amount of 
memory for huge binaries too.

  — David
Jun 19 2016
parent David Nadlinger <code klickverbot.at> writes:
On Sunday, 19 June 2016 at 20:20:38 UTC, David Nadlinger wrote:

 Such a separate driver could then also be used as part of the 
 regular distribution to improve the performance on 
 memory-constrained all-at-once builds, by freeing all the 
 frontend/LLVM memory (i.e., terminating the process) before 
 invoking the linker, which can take a substantial amount of 
 memory for huge binaries too.


(This is not likely to be worth the trouble on Windows, where – 
partly depending on the user's configuration – process creation 
can take ages. — David)
Jun 19 2016