Repository navigation
Conversation
Rows gathered from an F16 table and a matrix product run on the device and are checked against their known sum. A device that initialises but fails its first kernel - a CUDA driver older than the toolkit, a broken Vulkan driver - stops ace-server at startup with the reason, instead of failing the first request; the processor is not tested.
|
No actionable comments were generated in the recent review.
 |
| Layer / File(s) | Summary |
|---|---|
Backend initialization and self-test src/backend.h |
The backend check initializes the selected or best available backend. It skips the kernel self-test for CPU and checks a gather-and-matrix-product result for other backends. |
Server startup gate tools/ace-server.cpp |
The server exits with status 1 if the backend check fails. Otherwise, it continues to model scanning. |
Priority:
Estimated code review effort: 2 (Simple) | ~10 minutes
Change: Feature
Suggested reviewers: serveurpersocom
Merge Risk: 
b6be6
-
No actionable startup issue is established; the change is mergeable after normal checks.
Pre-merge checks: 
-
Check name Status Explanation Resolution Docstring Coverage Docstring coverage is 75.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 4 functions across 2 files. Write docstrings for the functions missing them to satisfy the coverage threshold. -
Check name Status Explanation Description Check Check skipped - CodeRabbit’s high-level summary is enabled. Title check The title clearly and concisely describes the main change: adding a backend self-test on the selected device during server startup. Linked Issues check Check skipped because no linked issues were found for this pull request. Out of Scope Changes check Check skipped because no linked issues were found for this pull request.
-
Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Comment @coderabbitai help to get the list of available commands.
A device can initialise and still fail its first kernel: a CUDA driver older than the toolkit rejects the PTX ("the provided PTX was compiled with an unsupported toolchain"), or a broken Vulkan driver faults. Today the server starts, listens, and the first request fails deep in the LM or the DiT.
backend.hgetsbackend_self_test(): rows gathered from an F16 table and a matrix product, the kernels every model starts with, run on the device and are checked against their known sum (132). It logs[Load] Self-test on CUDA0: ok (137.1 ms)or[Load] FATAL: self-test on X failed (status, result, expected 132).backend_check_device()runs it on the device laterbackend_initcalls will use (the one named by--device, or the best available) and frees it again. The processor is not tested.ace-servercalls it once at startup, after the log capture is set up. A device that fails stops the server with exit code 1 before it listens, so a launcher can fall back to another device instead of failing the first song.Checked on Windows with an RTX 4090:
--device CUDA0printsSelf-test on CUDA0: ok (137.1 ms)and the server starts;--device CPUstarts without the test. The same test has run in two other forks of this engine family since September.Summary by CodeRabbit