Establish GPU driver evidence and performance workloads #3

New Issue

2026-09-25T17:48:46Z

xavierk commented

2026-09-25 17:48:46 +00:00

Part of Find the way to Odin’s build-ready specification.

Question

How can Odin distinguish usable hardware acceleration, software rendering, missing/mismatched drivers, device access restrictions, and virtualization limits, and which portable workloads should be considered for GPU performance?

Cover Intel/AMD/NVIDIA and applicable ARM paths; kernel versus userspace drivers; Vulkan/OpenGL/compute capabilities; Mesa/software renderers; X11/Wayland/headless execution; multiple GPUs, containers/VMs and passthrough; non-root discovery, limits on saying a driver is correct, vendor-specific telemetry and missing data. Compare maintained benchmark candidates, licenses, runtime/dependency footprint, workload reproducibility, safety, and score comparability.

Deliver primary-source evidence and conditional options. Do not install/change drivers or execute GPU stress tests.

Part of [Find the way to Odin’s build-ready specification](https://git.bongbetic.com/xavierk/odin/issues/1).  ## Question How can Odin distinguish usable hardware acceleration, software rendering, missing/mismatched drivers, device access restrictions, and virtualization limits, and which portable workloads should be considered for GPU performance? Cover Intel/AMD/NVIDIA and applicable ARM paths; kernel versus userspace drivers; Vulkan/OpenGL/compute capabilities; Mesa/software renderers; X11/Wayland/headless execution; multiple GPUs, containers/VMs and passthrough; non-root discovery, limits on saying a driver is correct, vendor-specific telemetry and missing data. Compare maintained benchmark candidates, licenses, runtime/dependency footprint, workload reproducibility, safety, and score comparability. Deliver primary-source evidence and conditional options. Do not install/change drivers or execute GPU stress tests.

xavierk added the wayfinder:research label 2026-09-25 17:48:46 +00:00

xavierk added a new dependency 2026-09-25 17:49:48 +00:00

#8 Choose Odin’s workload suite and run profiles

xavierk added a new dependency 2026-09-25 17:49:55 +00:00

#11 Define health findings and the optimization advice rubric

xavierk self-assigned this 2026-09-25 18:01:30 +00:00

xavierk commented

2026-09-25 18:14:34 +00:00

Research resolution

A usable GPU path must be established per device and API through separate evidence stages: hardware/kernel discovery, userspace capability discovery, successful execution, known-output correctness where available, and presentation when requested. A loaded driver or successful enumeration alone cannot establish a universally “correct” driver.

Mesa or Zink is not automatically software rendering; identify the selected renderer/device and effective overrides. Software and virtual paths must not silently become hardware-GPU scores.
The report compares current clpeak, vkpeak, vkmark, and glmark2 releases, their licenses, measurements, controls, and dependencies. A qualified headless compute profile and API-specific graphics profiles are conditional options, not a universal score.
Surface-free compute, offscreen rendering, and desktop presentation are different capabilities. vkmark’s headless backend requires a specific extension; display or KMS fallbacks cannot be assumed harmless. Visible GPU windows remain an unresolved choice in the workload ticket.
Kernel/userspace drivers, device access, multi-GPU identity and selection, GPU generation, architecture, libc, display system, and VM/passthrough environment all affect interpretation. Proprietary NVIDIA on Void musl remains a real support limit.
Tool values require validated semantics: unsupported features and some failures can appear as numerical zero in a candidate. A throughput result does not automatically include a correctness check or useful frame-time distribution.
Runtime/memory bounds must include initialization and calibration; killing a client does not guarantee recovery from a kernel/driver hang. No automatic resets, driver changes, power-limit changes, or overclocking should be inferred from benchmarking.
Driver advice must identify the observed failure class and evidence; permission denial, missing API support, software rendering, and device loss are distinct findings.

Read the cited research report. Evidence is recorded at commit 7ff9d74e8f32 on research/gpu.

Still for the human decision tickets: selected workload/build and API floors; GPU presentation policy; device selection; correctness checks; virtual/software/unsupported score eligibility; resource budgets and exact validation matrix.

Evidence limits: no GPU execution, real-hardware qualification, driver installation, or target-matrix certification was performed. Project licenses were inspected, but redistribution still requires an inventory of the selected artifacts, assets, dependencies, and vendor terms.

## Research resolution A usable GPU path must be established per device and API through separate evidence stages: hardware/kernel discovery, userspace capability discovery, successful execution, known-output correctness where available, and presentation when requested. A loaded driver or successful enumeration alone cannot establish a universally “correct” driver. - Mesa or Zink is not automatically software rendering; identify the selected renderer/device and effective overrides. Software and virtual paths must not silently become hardware-GPU scores. - The report compares current clpeak, vkpeak, vkmark, and glmark2 releases, their licenses, measurements, controls, and dependencies. A qualified headless compute profile and API-specific graphics profiles are conditional options, not a universal score. - Surface-free compute, offscreen rendering, and desktop presentation are different capabilities. vkmark’s headless backend requires a specific extension; display or KMS fallbacks cannot be assumed harmless. Visible GPU windows remain an unresolved choice in the workload ticket. - Kernel/userspace drivers, device access, multi-GPU identity and selection, GPU generation, architecture, libc, display system, and VM/passthrough environment all affect interpretation. Proprietary NVIDIA on Void musl remains a real support limit. - Tool values require validated semantics: unsupported features and some failures can appear as numerical zero in a candidate. A throughput result does not automatically include a correctness check or useful frame-time distribution. - Runtime/memory bounds must include initialization and calibration; killing a client does not guarantee recovery from a kernel/driver hang. No automatic resets, driver changes, power-limit changes, or overclocking should be inferred from benchmarking. - Driver advice must identify the observed failure class and evidence; permission denial, missing API support, software rendering, and device loss are distinct findings. [Read the cited research report](https://git.bongbetic.com/xavierk/odin/src/commit/7ff9d74e8f32c35241ea1b7b11a28d2d0634665b/docs/research/gpu.md). Evidence is recorded at commit `7ff9d74e8f32` on `research/gpu`. **Still for the human decision tickets:** selected workload/build and API floors; GPU presentation policy; device selection; correctness checks; virtual/software/unsupported score eligibility; resource budgets and exact validation matrix. **Evidence limits:** no GPU execution, real-hardware qualification, driver installation, or target-matrix certification was performed. Project licenses were inspected, but redistribution still requires an inventory of the selected artifacts, assets, dependencies, and vendor terms.

xavierk closed this issue

2026-09-25 18:14:36 +00:00

xavierk referenced this issue

2026-09-25 18:14:37 +00:00

Find the way to Odin’s build-ready specification #1

xavierk referenced this issue

2026-09-25 18:47:14 +00:00

Choose Odin’s workload suite and run profiles #8

xavierk referenced this issue

2026-09-27 06:02:49 +00:00

Define health findings and the optimization advice rubric #11

Sign in to join this conversation.