fix(engine): software renders reach SwiftShader when VK_DRIVER_FILES pins a GPU by diogochaves · Pull Request #5976 · heygen-com/hyperframes · GitHub
Skip to content

fix(engine): software renders reach SwiftShader when VK_DRIVER_FILES pins a GPU - #5976

Open
diogochaves wants to merge 1 commit into
heygen-com:mainfrom
diogochaves:fix/swiftshader-vk-driver-files
Open

diogochaves wants to merge 1 commit into
heygen-com:mainfrom
diogochaves:fix/swiftshader-vk-driver-files

Conversation

@diogochaves

Copy link
Copy Markdown

What

Software renders (--no-browser-gpu, or auto falling back to software) launch Chrome without VK_DRIVER_FILES, VK_LOADER_DRIVERS_SELECT and VK_LOADER_DRIVERS_DISABLE. Hardware launches, and environments that set none of them, are unchanged.

Why

On my Linux desktop the session pins Vulkan to the AMD iGPU with VK_DRIVER_FILES=/usr/share/vulkan/icd.d/radeon_icd.json (it has a second GPU). Every software render failed before the first frame:

[assertSwiftShader] Chrome reported a non-SwiftShader WebGL backend. ... Got vendor="Google Inc. (AMD)"
renderer="ANGLE (AMD, Vulkan 1.4.354 (AMD Ryzen 7 9800X3D 8-Core Processor (RADV RAPHAEL_MENDOCINO) (0x000013C0)), radv)"

The flags were right (--use-gl=angle --use-angle=swiftshader --enable-unsafe-swiftshader). ANGLE loads SwiftShader by pointing the Vulkan loader at its ICD through VK_ICD_FILENAMES, and the loader ignores VK_ICD_FILENAMES whenever VK_DRIVER_FILES is set (LoaderDriverInterface.md), so ANGLE gets the real GPU. VK_LOADER_DRIVERS_SELECT breaks it too: VK_LOADER_DRIVERS_SELECT='*radeon*' filters SwiftShader out and the check sees no WebGL at all.

Repro, any project: VK_DRIVER_FILES=<your GPU's ICD json> npx hyperframes render --no-browser-gpu. Fails on 0.8.179 and 0.8.181 with chrome-headless-shell 155.0.8059.84; works with env -u VK_DRIVER_FILES.

Related work

None that I found (searched issues and PRs for VK_DRIVER_FILES, VK_ICD_FILENAMES, assertSwiftShader, SwiftShader Vulkan). It sits next to the WAYLAND_DISPLAY launch env from #5591. The CLI's own browsers (check, snapshot) don't go through launchBrowser, so they still inherit the pin in software mode; nothing fails there, so I left them out.

How

launchBrowser now asks launchEnv(fingerprint) for its env: the WSL case as before, otherwise, when the args select SwiftShader (--use-angle=swiftshader or --use-vulkan=swiftshader) and one of the three variables is set, a copy of process.env without them. Otherwise undefined, so Puppeteer inherits as it does today.

Test plan

  • Unit tests added: browserManager-vulkanEnv.test.ts checks the launch env for software (pins dropped, rest kept), hardware (inherited) and an unpinned env (inherited). The first case fails on main.
  • Manual testing: the render above, built from this branch, with the pin set: renders, assertSwiftShader passes on worker 0. Same with VK_LOADER_DRIVERS_SELECT='*radeon*'. Default (hardware) render unchanged.
  • oxlint, oxfmt --check, engine typecheck, check-comment-citations.mjs, comment-ratchet.mjs. Engine suite: the 6 failures I get are the same on main (ffmpeg 9 dropped -vsync, and two WSL probe-timeout tests).
  • Comments follow CONTRIBUTING.md "Comments"

…pins a GPU

ANGLE (and Dawn) load SwiftShader by pointing the Vulkan loader at its ICD
through VK_ICD_FILENAMES. The loader ignores VK_ICD_FILENAMES while
VK_DRIVER_FILES is set, and still applies VK_LOADER_DRIVERS_SELECT/DISABLE,
so on a machine that pins its Vulkan driver that way a --no-browser-gpu
render gets ANGLE on the real GPU and assertSwiftShader refuses it.

Launch SwiftShader browsers without those three variables. Hardware
launches, and environments that set none of them, are unchanged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant