Add a new GPU vendor driver backend
Suggested by the saved analysis. Some step paths were not captured or refer to generated or vendor files; only observed source files are linked.
- Update build.rs to compile vendor headers when feature flag enabled
ilya-zlobintsev / lact
Code
Understand ilya-zlobintsev/lact's source layout and find a starting point for your task using the saved repository evidence.
A
Architecture grade
score 100/100
0
Import cycles
lower is better
113
Modules parsed
43 edges
100%
Layeredness
clean-layer ratio
Measured from the parsed import graph, retained from the earlier analysis. Coupling, not a reading order.
How the code fits together
AI- User InterfacesEntry points for end-user interaction
- Client CommunicationAbstractions for connecting to daemon over TCP or Unix sockets
- Daemon & Core LogicGPU monitoring, configuration, and control logic
- GPU Driver HeadersVendored DRM and NVIDIA headers for direct driver interaction
- Packaging & DistributionConfiguration for multiple target platforms
Files at 705cc8e66706 · descriptions are AI-written.
The descriptions and the file list come from different revisions. Check responsibilities against source.
Where to start reading
- Repository root
- Repository root
- Runtime candidatename match
- Suggested starting pointAI
- Suggested starting pointAI
Find files for a task
AIAdd a new CLI command
Suggested by the saved analysis. Verify the proposed change against these source files.
- Define new subcommand in lact-cli/src/subcommands.rs matching existing enum pattern
- Call client connection methods to send command to daemon
- Route request through lact-client connection transport (TCP/Unix)
Add support for a new Linux distribution package
Suggested by the saved analysis. Verify the proposed change against these source files.
- Create Dockerfile in pkg/images/distro-version/ following existing Fedora/Debian patterns
- Define spec or recipe file in pkg/fedora-spec/ or pkg/recipes/ for distro package manager
- Add build matrix entry in pkg/bin/generate_spec.sh if automated spec generation is used
Change the public API
Start with possible export surfaces, then check their consumers and tests. These suggestions use file names, not verified execution paths.
- File-name match for this task.
- File-name match for this task.
- File-name match for this task.
Trace runtime behavior
Start with possible startup or request handlers, then follow the calls for your scenario. These suggestions use file names, not verified execution paths.
- File-name match for this task.
Add or update tests
Use a nearby test as a pattern. Read the root manifest or contribution guide for the correct test command. These suggestions use file names, not verified execution paths.
- File-name match for this task.
- File-name match for this task.
Change build or automation
Inspect the relevant configuration and the commands it runs before changing the workflow. These suggestions use file names, not verified execution paths.
- File-name match for this task.
- File-name match for this task.
- File-name match for this task.
File paths come from a snapshot of up to 500 captured paths; an omitted file may still exist.
- Public and runtime candidates are based on file names; their exports and execution paths still need checking in source.
- The file list was refreshed after the written analysis. Subsystem descriptions and suggested changes may describe an older revision.
- The import graph belongs to an older snapshot. Paths found only in that graph are omitted from this guide; their presence at the refreshed revision is unknown.
Import graph details
Modules (14)
Source directories grouped from the import graph. Each links to a per-module page with its files and how it couples to the rest.
- lact-schema/src8 files · 7 in-degree
- lact-daemon/src7 files · 6 in-degree
- lact-gui/src/app/pages7 files · 6 in-degree
- lact-gui/src/app/graphs_window/plot5 files · 5 in-degree
- lact-gui/src/app/pages/oc_page/power_states4 files · 3 in-degree
- lact-gui/src4 files · 3 in-degree
- lact-gui/src/app/graphs_window3 files · 3 in-degree
- lact-client/src3 files · 2 in-degree
Also: lact-gui/src/app/pages/oc_page/clocks_frame, lact-daemon/src/tests, lact-cli/src, lact-gui/src/app/components/oc_adjustment, lact-gui/src/app/pages/oc_page/performance_frame, lact-gui/src/app/pages/software_page/vulkan
Architecture and request flow
Critical modules — by import-graph evidence
A file is "critical" when lots of other files in the repo import it. The list is sorted by how many files import each one; the top of the list is the most load-bearing. A flame icon means the file is also one of the most-edited recently — when a critical file changes a lot, bugs there ripple wider, so it's where regressions are most likely.
How the A grade breaks down
List — top 12 most-imported files
Possibly-unused modules (15)
Nothing else in the repo imports these files, and they don't look like entry points — so they may be dead code. Verify before removing: dynamic imports, re-exports, and framework auto-loading (Next.js routes, plugin/DI registries) aren't tracked by the import graph.
isolatedlact-daemon/build.rs
Request flow
Technology choices
Rust
Memory-safe systems programming for GPU driver interaction without C pointer bugs; Tokio for async daemon communication.
amdgpu-sysfs + nvml-wrapper
Abstraction over direct DRM/NVAPI calls; reduces maintenance burden of vendored kernel headers.
Unix domain sockets + TCP
Dual transport enables local IPC efficiency and remote monitoring over network when needed.
Flatpak + RPM specs
Sandboxed distribution for security; native packaging for system integration and performance.
Build time and runtime
Build-time
- ▸C header compilation — lact-daemon/build.rs processes DRM and NVIDIA headers into Rust bindings
- ▸Clippy linting — clippy.toml governs strict Rust code quality gates
- ▸Multi-distro container builds — Docker images in pkg/images/ validate builds across Fedora, Ubuntu, Arch, openSUSE
Runtime
- ▸lact-daemon system service — Privileged background process reading/writing GPU state via /dev/dri and NVML
- ▸lact-cli unprivileged subprocess — User-facing command-line tool sending IPC requests to daemon
- ▸lact-gui (Flatpak) — Graphical frontend with sandbox access to daemon socket
- ▸Tokio async runtime — Handles concurrent socket connections and GPU telemetry updates
Design trade-offs
Vendored DRM/NVIDIA headers in lact-daemon/include/
Avoids runtime dependency on libdrm-dev and NVIDIA SDK; simplifies CI.
Headers must be manually updated when kernel or driver APIs change; licenses must be tracked.
Separate daemon and CLI processes communicating over sockets
Enables privileged daemon to run as service while unprivileged CLI remains low-risk.
Adds network round-trip latency; requires serialization overhead for each command.
Single workspace with six members (daemon, cli, gui, client, schema, main)
Code sharing for types and macros; atomic version bumps across components.
Monorepo coupling makes selective feature releases harder; CI must build unused members.
Non-goals
- ✗Supports only Linux (AMD/NVIDIA/Intel GPUs via DRM or NVML)
- ✗Does not provide kernel-level driver development; only user-space monitoring and control
- ✗Does not manage GPU memory allocation (application responsibility)
Code quality and hotspots
Quality Score: 90/100
Low RiskThis repo is in good health with CI, tests, and active maintenance.
Maintainability grade
How maintainable the code looks — from complexity, code issues, test presence, file size, and hotspot load. It grades the shape of the code, not defect risk, and doesn't replace review.
Configuration status
CI/CD Pipeline — configured
Provider: GitHub Actions
Test Suite — detected
4,228 test files detected
Stack: Rust test
Where: lact-daemon/src/tests/snapshots · lact-daemon/src/tests
Test Coverage — ~100%heuristic
4,228 test files / 176 source files. This is a file-count ratio, not real line coverage — set up Codecov for authoritative numbers.
Dependency Scanning — no config detected
No Dependabot / Renovate / Snyk / Trivy / CodeQL config found. Enable Dependabot or Renovate.
Live Signals
Real-time data from Codecov, GitHub Actions, GitHub Issues, deps.dev — not estimates.
Test coverage27.3%
from Codecov · authoritative, not estimated
CI pass rate84%
last 50 runs · median 11m
Stale-issue ratio19%
of 21 recent open issues are 30d+ old with no replies
Maintainer response7h
median first-reply across 14 recent issues · fast
Top hotspots
Files edited often AND hard to reason about. Churn = recent commit frequency, Complexity = branches and nesting, Risk = both combined. These are the highest-leverage targets for refactoring or testing.
src/app.rs
Churn: 100 (45 commits/180d)Complexity: 100Risk: 100
gpu_controller/nvidia.rs
Churn: 92 (23 commits/180d)Complexity: 100Risk: 92
All hotspots
Files that change often and are complex tend to accumulate more bugs
AI-suggested anti-patterns
Pattern-matches from the file structure and dependencies — useful as hypotheses, but not grounded in actual source. For real findings see Code Scanning above.
Vendored binary headers without version pinning
MediumNVIDIA SDK headers checked into git lack documentation of source version or update policy; risk of API drift.
lact-daemon/include/nvidia/
Monorepo with mandatory build of all members
CLI build pulls in GUI dependencies even if not needed; headless deployments build GUI code.
Cargo.toml workspace resolver
AI-suggested bottlenecks
Speculation from file structure, not profiling data. Validate against real metrics before acting on these.
I/O latency Bottleneck
Each CLI invocation creates new daemon connection; no connection pooling or persistent client.
lact-client socket transport
Concurrency Bottleneck
Sequential reads from amdgpu-sysfs and NVML block event loop if driver is slow; no read timeout.
lact-daemon GPU polling loop
Memory/bandwidth Bottleneck
Full state serialized on each query; no field-level filtering or delta compression.
JSON serialization of GPU telemetry
Code metrics
Static analysis on sampled source files (up to 15 files).