dcompute
dcompute copied to clipboard
libmir
ndslice integration
Can we use library @nothrow @nogc generic code in kernels. For example Slice!(Contiguous, [1], GlobalPointer!T) and ndslice topology?
Definitely.
- types and type related operations can be used as is (keeping in mind that initialisers do not yet work).
- code however will require that the module of origin be marked
@compute(CompileFor.hostAndDevice)to work on both the host and device
code however will require that the module of origin be marked @compute(CompileFor.hostAndDevice) to work on both the host and device
Do you mean mir.ndslice should be marked?
yes. I think it would be good to have a module (probably in dcompute) that imports all the relevant dcompute symbols from ldc.attributes and ldc.dcomputetypes if version = LDC_DCompute and otherwise sets up proxies for the symbols so you can still compile without a dcompute enabled ldc.
yes. I think it would be good to have a module (probably in dcompute) that imports all the relevant dcompute symbols from ldc.attributes and ldc.dcomputetypes if version = LDC_DCompute and otherwise sets up proxies for the symbols so you can still compile without a dcompute enabled ldc.
@thewilsonator Why not to allow any generic code to be instantiated in a marked module?
?? Not sure what you mean. Any modules, regardless of its @compute'ness, can have templates. The section you quoted would be for enabling building with a non-dcompute enabled compiler (e.g. old LDC and DMD/GDC)
I mean that I do not understand why ndslice should be marked if it is completely generic. If we call a generic function from kernel function it can be automatically determinated that generic should be compiled for kernel
Actually that might work. I'm not quite sure how template instances end up in a given module's symbol table, but if it does because it is referenced by that module, then the code would suggest that that would work.
We would still need @compute modules that reference them, though.