Batched Cholesky stats reduction bypassed on Metal without a diagnosis (_serial_cholesky_stats / _host_reduce_cholesky_info)
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 18/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- julia
- Domain
- performance
Research direction
Start in src/numeric/factorize.jl at cholesky_stats!, where the 256-work-item _cholesky_stats_kernel! is bypassed for batched runs by _cholesky_stats_serial_kernel!, and at _numeric_info!, which copies N.info to the host. Run the batched test with SDS_TEST_ONLY=test_ubatch on Metal with both hooks disabled and record the failure. Done means either a fixed barrier race in the shared-memory reduction or a named Metal compiler limit, with one hook kept.
Written by the indexing model from the issue text.
Description
Found while working on: T31 (PR #136)
What: for uniform batches (nbatch > 1) on Metal, cholesky_stats! (src/numeric/factorize.jl) replaces the 256-work-item _cholesky_stats_kernel! reduction with a one-work-item-per-member serial kernel (_cholesky_stats_serial_kernel!), and _numeric_info! additionally copies all of N.info to the host and recomputes info[ns + 1] per member. The PR does not record why. If the shared @localmem reduction gives a wrong info[ns + 1] on Metal, it may be a latent kernel bug (e.g. a missing barrier hidden by CUDA/AMD warp execution) that affects other backends too; if it is a Metal compiler limit, it should be named. Both hooks may not be needed (the serial kernel already writes info[ns + 1]). The host reduction also copies (ns + 1) * nb Int32 per info read on Metal.
Why it is out of scope: needs Metal hardware to reproduce; no task in TASKS.md owns it.
Suggested fix or plan change: run the batched stats kernel on Metal with SDS_TEST_ONLY=test_ubatch and both hooks off, record the failure; fix the kernel if it is a race, otherwise keep one hook and name the limit.
- Dominant language
- Julia
- Stars
- 3
- Forks
- 0
- Avg merge
- 4h 1m
- Merged PRs (30d)
- 73
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from exanauts/SparseDirectSolver.jl
-
found-by-agent
Difficulty 4/5 3-5 days Newbie friendliness 18/100
exanauts/SparseDirectSolver.jl#137 ·
Maintainers usually reply within 1 day
-
T31 — oneAPI and Metal extensions, allocation-free KA dense fallbacks (issues #112, #53)Possibly taken @dmaldona claimed this 2 days ago. Opentask
Difficulty 5/5 Over a week Newbie friendliness 12/100
exanauts/SparseDirectSolver.jl#118 ·
Maintainers usually reply within 1 day
-
task
Difficulty 4/5 3-5 days Newbie friendliness 20/100
exanauts/SparseDirectSolver.jl#117 ·
Maintainers usually reply within 1 day
-
task
Difficulty 5/5 Over a week Newbie friendliness 8/100
exanauts/SparseDirectSolver.jl#116 ·
Maintainers usually reply within 1 day
-
task
Difficulty 5/5 Over a week Newbie friendliness 8/100
exanauts/SparseDirectSolver.jl#115 ·
Maintainers usually reply within 1 day
All issues in exanauts/SparseDirectSolver.jl
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
JuliaGPU/KernelAbstractions.jl#897 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
oscar-system/GAP.jl#1455 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
JuliaAI/MLJTransforms.jl#85 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
SciML/OrdinaryDiffEq.jl#4875 ·
Maintainers usually reply within 4 days