Whether modern GPUs support full source-level debugging of OpenCL kernels, what tools provide it, and how GPU debuggers handle GPU-specific execution concepts such as wavefronts, warps, and work-items.
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 30/100
- Tipo de issue
- Documentación
- Claridad
- Necesita aclaración
- Estado de actividad
- Tranquilo
- Área
- devtools, documentation
Línea de trabajo
No se identifica ningún archivo ni prueba. Comienza investigando la compatibilidad con la depuración de GPU para AMD ROCm, Intel GPU runtimes, PoCL y otras implementaciones de OpenCL, incluidas las herramientas de los proveedores, las funcionalidades a nivel de código fuente y el modelo de ejecución de wavefront o warp. Se considera completado cuando se documentan las capacidades actuales, las limitaciones y las referencias relevantes de código abierto, comerciales o académicas.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
I am trying to understand the current state of source-level debugging for OpenCL kernels running on GPUs.
For CPU OpenCL implementations, source-level debugging is generally possible using standard debuggers. However, I am specifically interested in debugging OpenCL kernels executing on actual GPU hardware.
My questions are:
-
Is there currently a full-fledged debugger that supports source-level debugging of OpenCL kernels on GPUs?
-
Can such a debugger:
- Set breakpoints inside kernels?
- Single-step kernel instructions?
- Inspect kernel variables (private, local, and global memory)?
- Inspect work-item and work-group state?
- Switch between individual work-items and inspect each work-item's execution state independently?
- View call stacks and source line mappings?
-
Are there vendor-specific solutions (AMD, Intel, NVIDIA) that provide this functionality?
-
How is this typically implemented under the hood, given that GPU execution is based on wavefronts/warps rather than independently scheduled threads?
-
If true source-level debugging is not generally available, what are the main technical limitations that make it difficult?
I would also appreciate references to any open-source or commercial tools that support OpenCL kernel debugging, as well as any papers, documentation, or presentations describing the current state of GPU debugging.
My goal is to understand whether OpenCL kernel debugging on GPUs has reached a level comparable to CPU debugging with GDB/LLDB, or whether developers still primarily rely on printf-style debugging, simulators, and profiling tools.
For context, I am particularly interested in AMD ROCm, Intel GPU runtimes, PoCL, and other modern OpenCL implementations.
- Lenguaje dominante
- CMake
- Estrellas
- 715
- Forks
- 70
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
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 KhronosGroup/OpenCL-Guide
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 72/100
KhronosGroup/OpenCL-Guide#31 ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
KhronosGroup/OpenCL-Guide#42 · 1 comentario ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
KhronosGroup/OpenCL-Guide#41 ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 45/100
KhronosGroup/OpenCL-Guide#34 · 1 comentario ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
KhronosGroup/OpenCL-Guide#33 · 1 reacción ·
Todos los issues de KhronosGroup/OpenCL-Guide
Issues similares
-
[Feature]: [P3] engine-rs: the package source hash should ignore line endings and untracked filesAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
maniator/verticopolis#880 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
avl_automation: the generated control surface block isn't valid XML (typo in avl_out_parse.py)Posiblemente ocupada @brksol la tomó hoy. Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 92/100
PX4/PX4-gazebo-models#164 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
rr-debugger/rr#4111 ·
Los mantenedores suelen responder en 3 días