# Lightweight dependency for GPU programming

**URL:** <https://discourse.julialang.org/t/lightweight-dependency-for-gpu-programming/127386>\
**Category:** GPU\
**Tags:** gpu, kernelabstractions\
**Created:** [March 26, 2025, 3:11pm UTC](https://discourse.julialang.org/t/lightweight-dependency-for-gpu-programming/127386 "2025-03-26T15:11:30Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![juliohm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/juliohm/32/215266_2.png) [@juliohm](https://discourse.julialang.org/u/juliohm)\
**Post date:** [March 26, 2025, 3:11pm UTC](https://discourse.julialang.org/t/lightweight-dependency-for-gpu-programming/127386/1 "2025-03-26T15:11:30Z")

</div>

As a package author is it possible to define KernelAbstractions.jl in my package without adding heavy dependencies? I see that the package currently depends on

```julia
[deps]
Adapt = "79e6a3ab-5dfb-504d-930d-738a2a938a0e"
Atomix = "a9b6321e-bd34-4604-b9c9-b65b8de01458"
GPUCompiler = "61eb1bfa-7361-4325-ad38-22787b887f55"
InteractiveUtils = "b77e0a4c-d291-57a0-90e8-8db25a27a240"
LLVM = "929cbde3-209d-540e-8aea-75f648917ca0"
MacroTools = "1914dd2f-81c6-5fcd-8719-6d5c9610ff09"
OpenCL_jll = "6cb37087-e8b6-5417-8430-1f242f1e46e4"
PrecompileTools = "aea7be01-6a6a-4083-8856-8a6e6704d82a"
Printf = "de0858da-6303-5e67-8744-51eddeeeb8d7"
SPIRVIntrinsics = "71d1d633-e7e8-4a92-83a1-de8814b09ba8"
StaticArrays = "90137ffa-7385-5640-81b9-e52037218182"
UUIDs = "cf7118a7-6976-5b1a-9a39-7adc72f591a4"
pocl_jll = "627d6b7a-bbe6-5189-83e7-98cc0a5aeadd"

```

Could we get just the KA syntax, and leave the functionality to package extensions?

The workflow I have in mind starts with me writing a kernel inside my package:

```julia
module MyPkg
  using KernelAbstractions

  @kernel function f(...)
    # do something
  end
end

```

and users loading the desired device to run the function:

```julia
using MyPkg
using CUDA
using ScopedValues

with(device=CUDADevice()) do
  MyPkg.f(...)
end

```

I know this is probably not possible today, but I wonder what would be the best approximation currently?

---

<div class="post-metadata">

**Author:** ![maleadt](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/maleadt/32/10097_2.png) [@maleadt](https://discourse.julialang.org/u/maleadt)\
**Post date:** [March 27, 2025, 10:53am UTC](https://discourse.julialang.org/t/lightweight-dependency-for-gpu-programming/127386/2 "2025-03-27T10:53:17Z")

</div>

> [@juliohm](#):
>
> without adding heavy dependencies

Which of these dependencies are too heavy? They are all intended to be relatively lightweight packages, e.g., there’s no back-ends included. IIUC the next breaking release of KA.jl might also exclude the CPU back-end, further reducing the set of dependencies (excluding the OpenCL and pocl JLLs).

---

<div class="post-metadata">

**Author:** ![juliohm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/juliohm/32/215266_2.png) [@juliohm](https://discourse.julialang.org/u/juliohm)\
**Post date:** [March 27, 2025, 11:36am UTC](https://discourse.julialang.org/t/lightweight-dependency-for-gpu-programming/127386/3 "2025-03-27T11:36:52Z")

</div>

> [@maleadt](#):
>
> Which of these dependencies are too heavy?

This is subjective of course, but imagine a lightweight package that does one thing and one thing only, and does it very well in native Julia. This package can be ported to all sorts of exotic devices and platforms officially supported by the language.

I don’t want to increase compilation time downstream, nor I want to take the risk of an external binary that can fail to build on a given platform. That means that I usually don’t take JLLs as dependencies.

Ideally (and I know this is hard) we would have the core macros defined in KernelAbstractions.jl, and anything else related to implementations defined in extensions like `CUDAKernelAbstractionsExt.jl`, `OpenCLKernelAbstractionsExt.jl`.

That way users who don’t have any interest in OpenCL functionality wouldn’t be affected by potential compilation issues, etc.

---

<div class="post-metadata">

**Author:** ![maleadt](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/maleadt/32/10097_2.png) [@maleadt](https://discourse.julialang.org/u/maleadt)\
**Post date:** [March 27, 2025, 12:43pm UTC](https://discourse.julialang.org/t/lightweight-dependency-for-gpu-programming/127386/4 "2025-03-27T12:43:25Z")

</div>

> [@juliohm](#):
>
> anything else related to implementations defined in extensions like `CUDAKernelAbstractionsExt.jl`, `OpenCLKernelAbstractionsExt.jl`

That is literally how things work right now. The only reason OpenCL is a direct dep is that the CPU back-end used to be available by default, so moving it out is a breaking change which hasn’t happened yet.

---

<div class="post-metadata">

**Author:** ![juliohm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/juliohm/32/215266_2.png) [@juliohm](https://discourse.julialang.org/u/juliohm)\
**Post date:** [March 27, 2025, 12:59pm UTC](https://discourse.julialang.org/t/lightweight-dependency-for-gpu-programming/127386/5 "2025-03-27T12:59:39Z")

</div>

> [@maleadt](#):
>
> OpenCL is a direct dep is that the CPU back-end used to be available by default, so moving it out is a breaking change which hasn’t happened yet.

Would it be too hard to implement the CPU back-end in native Julia? I understand that it is the fallback when users want to dispatch their code on CPUs as usual.

---

<div class="post-metadata">

**Author:** ![maleadt](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/maleadt/32/10097_2.png) [@maleadt](https://discourse.julialang.org/u/maleadt)\
**Post date:** [March 27, 2025, 1:52pm UTC](https://discourse.julialang.org/t/lightweight-dependency-for-gpu-programming/127386/6 "2025-03-27T13:52:54Z")

</div>

Yes. It was previously implemented like that, and it is prohibitively hard to map GPU SPMD semantics onto Julia constructs without significant compiler analyses (and with the code performing well, of course). PoCL does that for us.

---

<div class="post-metadata">

**Author:** ![juliohm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/juliohm/32/215266_2.png) [@juliohm](https://discourse.julialang.org/u/juliohm)\
**Post date:** [March 27, 2025, 4:26pm UTC](https://discourse.julialang.org/t/lightweight-dependency-for-gpu-programming/127386/7 "2025-03-27T16:26:16Z")

</div>

> [@maleadt](#):
>
> Yes. It was previously implemented like that, and it is prohibitively hard to map GPU SPMD semantics onto Julia constructs without significant compiler analyses

Thank you for clarifying.

> [@maleadt](#):
>
> IIUC the next breaking release of [KA.jl](https://juliaregistries.github.io/General/packages/redirect_to_repo/KA) might also exclude the CPU back-end, further reducing the set of dependencies (excluding the OpenCL and pocl JLLs).

Do you mean that a next breaking release will also drop OpenCL\_jll?

---

<div class="post-metadata">

**Author:** ![maleadt](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/maleadt/32/10097_2.png) [@maleadt](https://discourse.julialang.org/u/maleadt)\
**Post date:** [March 27, 2025, 5:22pm UTC](https://discourse.julialang.org/t/lightweight-dependency-for-gpu-programming/127386/8 "2025-03-27T17:22:24Z")

</div>

> [@juliohm](#):
>
> Do you mean that a next breaking release will also drop OpenCL\_jll?

I think @vchuravy was considering this, yes. I’ll leave the confirmation to him.