Vulkan software-renderer warnings don't self-identify their source; an agent misattributed them and reported it wrong

Summary

In a headless environment where vgpu falls back to the software renderer (llvmpipe/lavapipe), the Vulkan stack emits warnings on the same stream vgpu writes its own output to. Those warnings don't say what produced them, and in a real coding-agent session this led the agent to draw — and report to the user — the wrong conclusion about their source.

What happened

Running a real agent (claude-sonnet-5) through our agent-evals harness (apps/agent-evals, merged in #253) on a headless render task, the raw stderr from the render step included:

Warning: ../src/imagination/vulkan/pvr_instance.c:92: Failed to enumerate drm devices (errno 2: No such file or directory) (VK_ERROR_INITIALIZATION_FAILED)
Error: Loader Message: setup_loader_term_phys_devs: Call to 'vkEnumeratePhysicalDevices' in ICD /usr/lib/aarch64-linux-gnu/libvulkan_powervr_mesa.so failed with error code -3
[... repeated 4x ...]
Warning: maxDynamicUniformBuffersPerPipelineLayout artificially reduced from 500000 to 16 to fit dynamic offset allocation limit.
Warning: maxDynamicStorageBuffersPerPipelineLayout artificially reduced from 500000 to 16 to fit dynamic offset allocation limit.

The render itself succeeded (all correct: true). But the agent's final report to the user was:

"It ran successfully (the Vulkan warnings are just noise from the mock adapter falling back). The output verification confirms out.png is 64x64 with every pixel exactly R=255, G=0, B=0, A=255."

That attribution is wrong: the warnings are the Vulkan loader trying (and failing to init) the PowerVR hardware ICD before landing on the CPU software renderer — nothing to do with @vgpu/adapter-mock (which happened to be a sibling dependency in the project's package.json, likely why "mock adapter" came to mind). The agent had no signal in the warning text itself pointing at the real source, guessed, and then stated the guess as fact in its report.

Impact

Functionally harmless in this run (the render was correct either way), but this is exactly the kind of ambiguous diagnostic output that produces a confidently wrong causal claim in an agent's summary — the kind of claim a human reviewing the agent's report has no easy way to catch, since the actual pixels are fine.

Related

#242 (closed) flagged that these same Vulkan/software-renderer warnings read as fatal even though they're benign. This issue is a different angle on the same warnings: independent of severity, they don't self-identify their source, so a reader (human or agent) has to guess what produced them — and guessing is exactly what happened here.

Discussion (not proposing a specific fix — leaving the call to the doctor/runtime design)

A couple of directions that seem worth considering:

• Prefix/label these warnings with their real origin, e.g. [vgpu software renderer] or [Vulkan loader: PowerVR ICD probe], so they're attributable without cross-referencing source code.
• Document the expected warning shapes (loader ICD-probe failures, maxDynamic*ArrayDynamicIndexing/limit-reduction lines) in doctor's output or docs, so an agent has something authoritative to check against instead of pattern-matching against unrelated package names.

How we found this

From an agent-evals run (apps/agent-evals, harness merged in #253) — a real claude-sonnet-5 session performing a headless render task against vgpu@0.2.0, not a synthetic/scripted test.

Evidence

Full event transcript: apps/agent-evals/.eve/evals/<run>/evals/s1-clear-color.events.ndjson (from the harness in #253). Key events:

• action.result (stepIndex 5) — raw stderr with the PowerVR/Vulkan loader warnings quoted above, alongside stdout: "64 64\nall correct: true\n".
• message.completed (final) — the agent's exact "the Vulkan warnings are just noise from the mock adapter falling back" conclusion, quoted above verbatim.

Happy to share the full ndjson transcript if useful.