Make blocking Level Zero calls GC-safe
Los mantenedores suelen responder en 1 día
Ya se ha fusionado un pull request relacionado.
- #704 de @maleadt — fusionado
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 55/100
Línea de trabajo
Start by comparing the plain @ccall wrappers in lib/level-zero/libze.jl with the @gcsafe_ccall usage in lib/level-zero/synchronization.jl, then find the generator in res/wrap.jl. Check the blocking callers in lib/level-zero/module.jl, fence.jl and event.jl. Done means the blocking Level Zero calls use GC-safe ccalls, the wrappers still load, and the existing test suite passes.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
The generated Level Zero wrappers in lib/level-zero/libze.jl all use a plain @ccall. While such a call runs, its thread is in a GC-unsafe state, so a garbage collection requested by any other thread waits until the call returns. That only matters for calls that can block for a long time:
zeModuleCreate(called fromZeModule,lib/level-zero/module.jl) runs the IGC compile. On an Iris Xe with a cold NEO cache (NEO_CACHE_PERSISTENT=0) it took 19–248 ms per kernel. That is the first launch of every kernel in a session whose driver cache doesn't have it yet.Base.wait(::ZeFence)andBase.wait(::ZeEvent)(lib/level-zero/fence.jl,event.jl) callzeFenceHostSynchronize/zeEventHostSynchronizewith atypemax(UInt64)timeout, i.e. block for as long as the GPU work takes.
The synchronization in lib/level-zero/synchronization.jl already uses @gcsafe_ccall for the same reason, and CUDA.jl's wrapper generator emits every driver call as @gcsafe_ccall (res/wrap/wrap.jl there), e.g. cuModuleLoadData and cuLinkComplete. Either approach works here: rewrite all calls in res/wrap.jl, or only the blocking ones above. Level Zero documents these functions as thread-safe.
- Lenguaje dominante
- Julia
- Estrellas
- 217
- Forks
- 37
- Merge medio
- 1 d 7 h
- PR fusionados (30 d)
- 45
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de JuliaGPU/oneAPI.jl
-
Dificultad 3/5 1-2 días Aptitud para principiantes 74/100
Los mantenedores suelen responder en 1 día
-
libraries upstream
Dificultad 4/5 1-2 días Aptitud para principiantes 22/100
JuliaGPU/oneAPI.jl#703 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 62/100
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
JuliaGPU/oneAPI.jl#663 · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
Los mantenedores suelen responder en 1 día
Todos los issues de JuliaGPU/oneAPI.jl
Issues similares
-
_fit_phylo_binomial_xlv: default start calls undefined logit (UndefVarError without beta_init)Abiertocode-review
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
JuliaNLSolvers/Optim.jl#1296 ·
-
OptimizationCUTEst jobs fail: gfortran not installed on the runnerPosiblemente ocupada @ChrisRackauckas-Claude la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
SciML/SciMLBenchmarks.jl#1946 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
JuliaSmoothOptimizers/NCL.jl#101 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 69/100