Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Build `@opencl` on top of `clcall`

Open
  • Is something wrong?
#575 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Refactor
Clarity
Mostly clear
Activity status
Active
Tech stack
julia
Domain
backend, devtools

Research direction

Read lib/cl/kernel.jl and src/compiler/execution.jl, then compare their conversion, locking, ownership, and launch paths with the cited CUDA.jl and Metal.jl implementations. Trace how clcall, launch_tuple, and KernelState pass arguments and kernel state. Done means @opencl uses a shared clcall_tuple conversion and ownership path, with kernel-specific exception handling retained and launch latency and host compile time unchanged.

Written by the indexing model from the issue text.

Description

In CUDA.jl and AMDGPU.jl, @cuda/@roc launches are built on the public low-level launch function: launch_converted prepends the KernelState and calls cudacall_tuple (roccall) with the kernel's compiled signature. Metal.jl is doing the same with its new metalcall (JuliaGPU/Metal.jl#1084). OpenCL.jl has two launch paths instead:

  • clcall (lib/cl/kernel.jl) converts its arguments with clconvert/unsafe_clconvert, locks the arrays through argument_lock, and calls cl.call;
  • @opencl (launch_tuple in src/compiler/execution.jl) converts with kernel_convert/KernelAdaptor, which collects the indirect memory and the Managed allocations, locks them with lock_managed, migrates their ownership with take_ownership!, and calls cl.call through launch_with_exception_mailbox.

So argument conversion, locking and the ownership of allocations are implemented twice, and they already differ: clcall only handles arrays passed as pointer arguments, converting everything else with Base.cconvert, so arrays nested in other arguments are neither converted to device arrays, nor locked, owned or registered as indirect memory (the caller has to pass indirect_memory itself). Building @opencl on clcall would leave one implementation of these, used and tested by every launch, and make clcall handle arguments like a launch from Julia code does.

That probably means:

  • adding a clcall_tuple that @opencl calls with Tuple{KernelState, F, TT...}, with Core.kwcall forwarding the arguments as a tuple, like cudacall does since JuliaGPU/CUDA.jl#3309 (clcall is a varargs method with keyword arguments, which splats them);
  • moving the KernelAdaptor conversion and the ownership transaction into clcall's conversion, so that non-pointer arguments are converted with it and their indirect memory and allocations are collected;
  • keeping the parts that only depend on the kernel object, like the exception mailbox, in the @opencl layer.

Launch latency and the host compile time of new kernel signatures should stay the same; for Metal.jl, the shared path didn't change either (JuliaGPU/Metal.jl#1085).

Dominant language
Julia
Stars
313
Forks
50
Avg merge
22h 18m
Merged PRs (30d)
40

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from JuliaGPU/OpenCL.jl

All issues in JuliaGPU/OpenCL.jl

Similar issues

More Julia issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.