marfrit/panvk-bifrost
1
0
Fork 1
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

brave-vulkan complaining about missing implementations #2

New Issue
Closed
opened 2026-05-23 03:36:39 +00:00 by marfrit · 2 comments
marfrit commented 2026-05-23 03:36:39 +00:00
Owner
Copy Link
Copy Source

WARNING: panvk is not a conformant Vulkan implementation, testing use only.
Warning: Vulkan fragmentStoresAndAtomics feature required.

  • While initializing adapter (backend=BackendType::Vulkan)
    at InitializeImpl (../../third_party/dawn/src/dawn/native/vulkan/PhysicalDeviceVk.cpp:250)

Warning: Couldn't get proc eglChooseConfig

  • While trying to discover a BackendType::OpenGL adapter.
    at LoadClientProcs (../../third_party/dawn/src/dawn/native/opengl/EGLFunctions.cpp:119)

Warning: Couldn't get proc eglChooseConfig

  • While trying to discover a BackendType::OpenGLES adapter.
    at LoadClientProcs (../../third_party/dawn/src/dawn/native/opengl/EGLFunctions.cpp:119)

[10698:10698:0523/042454.465617:ERROR:services/video_capture/video_capture_service_impl.cc:200] Bind context provider failed.
[10431:10431:0523/042503.595671:ERROR:ui/gfx/x/atom_cache.cc:234] Add application/vnd.portal.filetransfer to kAtomsToCache
[10431:10431:0523/042503.595917:ERROR:ui/gfx/x/atom_cache.cc:234] Add application/vnd.portal.files to kAtomsToCache
[10431:10500:0523/042507.088087:ERROR:content/browser/browser_main_loop.cc:274] GLib: g_main_context_pop_thread_default: assertion 'stack != NULL' failed
[10431:10499:0523/042507.088105:ERROR:content/browser/browser_main_loop.cc:274] GLib: g_main_context_pop_thread_default: assertion 'stack != NULL' failed
[10431:10501:0523/042507.088578:ERROR:content/browser/browser_main_loop.cc:274] GLib: g_main_context_pop_thread_default: assertion 'stack != NULL' failed
[10431:10431:0523/050438.428486:ERROR:mojo/public/cpp/bindings/lib/interface_endpoint_client.cc:748] Message 1 rejected by interface blink.mojom.WidgetHost
[10431:10431:0523/050451.101779:ERROR:components/dbus/xdg/request.cc:169] Request cancelled by user.
[10467:10475:0523/052540.458234:ERROR:net/socket/ssl_client_socket_impl.cc:924] handshake failed; returned -1, SSL error code 1, net_error -101
[10467:10475:0523/052607.606506:ERROR:net/socket/ssl_client_socket_impl.cc:924] handshake failed; returned -1, SSL error code 1, net_error -100

WARNING: panvk is not a conformant Vulkan implementation, testing use only. Warning: Vulkan fragmentStoresAndAtomics feature required. - While initializing adapter (backend=BackendType::Vulkan) at InitializeImpl (../../third_party/dawn/src/dawn/native/vulkan/PhysicalDeviceVk.cpp:250) Warning: Couldn't get proc eglChooseConfig - While trying to discover a BackendType::OpenGL adapter. at LoadClientProcs (../../third_party/dawn/src/dawn/native/opengl/EGLFunctions.cpp:119) Warning: Couldn't get proc eglChooseConfig - While trying to discover a BackendType::OpenGLES adapter. at LoadClientProcs (../../third_party/dawn/src/dawn/native/opengl/EGLFunctions.cpp:119) [10698:10698:0523/042454.465617:ERROR:services/video_capture/video_capture_service_impl.cc:200] Bind context provider failed. [10431:10431:0523/042503.595671:ERROR:ui/gfx/x/atom_cache.cc:234] Add application/vnd.portal.filetransfer to kAtomsToCache [10431:10431:0523/042503.595917:ERROR:ui/gfx/x/atom_cache.cc:234] Add application/vnd.portal.files to kAtomsToCache [10431:10500:0523/042507.088087:ERROR:content/browser/browser_main_loop.cc:274] GLib: g_main_context_pop_thread_default: assertion 'stack != NULL' failed [10431:10499:0523/042507.088105:ERROR:content/browser/browser_main_loop.cc:274] GLib: g_main_context_pop_thread_default: assertion 'stack != NULL' failed [10431:10501:0523/042507.088578:ERROR:content/browser/browser_main_loop.cc:274] GLib: g_main_context_pop_thread_default: assertion 'stack != NULL' failed [10431:10431:0523/050438.428486:ERROR:mojo/public/cpp/bindings/lib/interface_endpoint_client.cc:748] Message 1 rejected by interface blink.mojom.WidgetHost [10431:10431:0523/050451.101779:ERROR:components/dbus/xdg/request.cc:169] Request cancelled by user. [10467:10475:0523/052540.458234:ERROR:net/socket/ssl_client_socket_impl.cc:924] handshake failed; returned -1, SSL error code 1, net_error -101 [10467:10475:0523/052607.606506:ERROR:net/socket/ssl_client_socket_impl.cc:924] handshake failed; returned -1, SSL error code 1, net_error -100
claude-noether commented 2026-05-23 11:38:41 +00:00
Contributor
Copy Link
Copy Source

Investigation log (2026-05-23)

What was confirmed

The cited Dawn warning fires because panvk-bifrost on Mesa 26.0.6 reports fragmentStoresAndAtomics = false for Bifrost (PAN_ARCH 7). Sources:

  • mesa-26.0.6/src/panfrost/vulkan/panvk_vX_physical_device.c: .fragmentStoresAndAtomics = (PAN_ARCH >= 10) || instance->force_enable_shader_atomics
  • Mesa main (snapshot 617da94, 2026-05-06): flipped to = true unconditional — but Mesa main also explicitly considers panvk-on-Bifrost non-conformant.

What the workaround does

Mesa 26.0.6 ships a DRI option pan_force_enable_shader_atomics (driconf panvk). Drop in ~/.drirc:

<driconf>
    <device driver="panvk">
        <application name="Default">
            <option name="pan_force_enable_shader_atomics" value="true"/>
        </application>
    </device>
</driconf>

After this, vulkaninfo reports both fragmentStoresAndAtomics and vertexPipelineStoresAndAtomics as true, and the cited "feature required" warning disappears from brave-vulkan stderr.

What the workaround did not fix

Dawn still falls back to SwiftShader Device (LLVM 10.0.0) for WebGPU. fragmentStoresAndAtomics was the first feature Dawn's PhysicalDeviceVk init checks; with that fixed, Dawn rejects the panvk adapter silently at some subsequent check (no stderr warning emitted). Need to read third_party/dawn/src/dawn/native/vulkan/PhysicalDeviceVk.cpp:InitializeImpl to enumerate the full requirement list — Dawn checks features in sequence and only logs the first failure.

Side observation: GPU compositing flapping

Independent of the Dawn issue, brave's high-level gpu_compositing state on this device is brittle:

  • Earlier today (~04:20 UTC, after environment.d + Plasma .desktop override + systemctl --user import-environment), chrome://gpu reported Compositing: Hardware accelerated, WebGL/WebGPU clean.
  • After repeated kill/restart cycles during the drirc experiment (and ohm reboot), chrome://gpu now reports Compositing: Software only with gpu_compositing explicitly disabled, even with no drirc, fresh boot, and identical brave-vulkan flags.
  • Brave's Local State gpu block is empty ({}) and exited_cleanly: True — so the persistent-state-poison hypothesis is wrong.
  • The disable message says "either via blocklist, about:flags or the command line." --ignore-gpu-blocklist is set; --flag-switches-begin --flag-switches-end is empty; cmdline has no --disable-gpu* flags. Source is therefore neither — possibly an early Vulkan init failure that doesn't surface to stderr.
  • Verbose logging (--enable-logging=stderr --v=1 --vmodule=*gpu*=2,*vulkan*=2) on this brave build doesn't emit detail from the gpu-process — likely chromium source-file renames since those vmodule patterns were canonical.

Recommended next iterations

  1. Phase 0 / Phase 3 deeper: read PhysicalDeviceVk.cpp source for the full feature requirement list Dawn enforces; produce a delta between panvk-bifrost's advertised features and Dawn's requirements. This tells us whether the gap is one more feature (small patch) or many features (big campaign or structural "won't fit").

  2. Independent compositing investigation: the drirc-flip effect on gpu_compositing is non-monotonic in this session and needs an instrumentation pass that doesn't depend on chrome://gpu rendering (which uses Polymer/shadow DOM and is hard to extract from). Candidate: strace -f -e openat on the gpu-process during early init to see which mesa libraries get touched and which fail.

  3. Upstream signal: Mesa main flipped fragmentStoresAndAtomics to unconditional true. If we believe their judgment, we can carry a small mesa-panvk-bifrost r5 patch doing the same. The 0001-0004 lineage already establishes the precedent. Risk: shaders using actual fragment stores on Bifrost may fail at runtime — needs a CTS subset run to verify before shipping.

Open question for issue author

The original symptom that opened this issue was a stderr line during brave-vulkan startup. Was the operator-visible symptom: (a) a perf regression (slow video / slow scrolling), or (b) just the warning text in journalctl with no visible behavior change? If (b), this issue can be tracked as "cosmetic until Dawn matters". If (a), the priority is finding what actually broke compositing, since the fragmentStoresAndAtomics warning is downstream of that.

🤖 investigation by Claude Opus 4.7 / claude-noether

## Investigation log (2026-05-23) ### What was confirmed The cited Dawn warning fires because panvk-bifrost on Mesa 26.0.6 reports `fragmentStoresAndAtomics = false` for Bifrost (PAN_ARCH 7). Sources: - `mesa-26.0.6/src/panfrost/vulkan/panvk_vX_physical_device.c`: `.fragmentStoresAndAtomics = (PAN_ARCH >= 10) || instance->force_enable_shader_atomics` - Mesa main (snapshot 617da94, 2026-05-06): flipped to `= true` unconditional — but Mesa main also explicitly considers panvk-on-Bifrost non-conformant. ### What the workaround does Mesa 26.0.6 ships a DRI option `pan_force_enable_shader_atomics` (driconf `panvk`). Drop in `~/.drirc`: ```xml <driconf> <device driver="panvk"> <application name="Default"> <option name="pan_force_enable_shader_atomics" value="true"/> </application> </device> </driconf> ``` After this, `vulkaninfo` reports both `fragmentStoresAndAtomics` and `vertexPipelineStoresAndAtomics` as `true`, and the cited "feature required" warning disappears from brave-vulkan stderr. ### What the workaround did *not* fix Dawn still falls back to `SwiftShader Device (LLVM 10.0.0)` for WebGPU. `fragmentStoresAndAtomics` was the **first** feature Dawn's PhysicalDeviceVk init checks; with that fixed, Dawn rejects the panvk adapter silently at some subsequent check (no stderr warning emitted). Need to read `third_party/dawn/src/dawn/native/vulkan/PhysicalDeviceVk.cpp:InitializeImpl` to enumerate the full requirement list — Dawn checks features in sequence and only logs the first failure. ### Side observation: GPU compositing flapping Independent of the Dawn issue, brave's high-level `gpu_compositing` state on this device is brittle: - Earlier today (~04:20 UTC, after `environment.d` + Plasma `.desktop` override + `systemctl --user import-environment`), chrome://gpu reported Compositing: Hardware accelerated, WebGL/WebGPU clean. - After repeated kill/restart cycles during the drirc experiment (and ohm reboot), chrome://gpu now reports `Compositing: Software only` with `gpu_compositing` explicitly disabled, even with no drirc, fresh boot, and identical brave-vulkan flags. - Brave's `Local State` `gpu` block is empty (`{}`) and `exited_cleanly: True` — so the persistent-state-poison hypothesis is wrong. - The disable message says "either via blocklist, about:flags or the command line." `--ignore-gpu-blocklist` is set; `--flag-switches-begin --flag-switches-end` is empty; cmdline has no `--disable-gpu*` flags. Source is therefore neither — possibly an early Vulkan init failure that doesn't surface to stderr. - Verbose logging (`--enable-logging=stderr --v=1 --vmodule=*gpu*=2,*vulkan*=2`) on this brave build doesn't emit detail from the gpu-process — likely chromium source-file renames since those vmodule patterns were canonical. ### Recommended next iterations 1. **Phase 0 / Phase 3 deeper**: read `PhysicalDeviceVk.cpp` source for the full feature requirement list Dawn enforces; produce a delta between panvk-bifrost's advertised features and Dawn's requirements. This tells us whether the gap is one more feature (small patch) or many features (big campaign or structural "won't fit"). 2. **Independent compositing investigation**: the drirc-flip effect on `gpu_compositing` is non-monotonic in this session and needs an instrumentation pass that doesn't depend on chrome://gpu rendering (which uses Polymer/shadow DOM and is hard to extract from). Candidate: `strace -f -e openat` on the gpu-process during early init to see which mesa libraries get touched and which fail. 3. **Upstream signal**: Mesa main flipped `fragmentStoresAndAtomics` to unconditional `true`. If we believe their judgment, we can carry a small `mesa-panvk-bifrost` r5 patch doing the same. The 0001-0004 lineage already establishes the precedent. Risk: shaders using actual fragment stores on Bifrost may fail at runtime — needs a CTS subset run to verify before shipping. ### Open question for issue author The original symptom that opened this issue was a stderr line during brave-vulkan startup. Was the *operator-visible* symptom: (a) a perf regression (slow video / slow scrolling), or (b) just the warning text in journalctl with no visible behavior change? If (b), this issue can be tracked as "cosmetic until Dawn matters". If (a), the priority is finding what actually broke compositing, since the fragmentStoresAndAtomics warning is downstream of that. --- 🤖 investigation by Claude Opus 4.7 / claude-noether
claude-noether commented 2026-05-23 12:31:42 +00:00
Contributor
Copy Link
Copy Source

Resolution

Shipped via marfrit-packages#92 → CI run #171 → published as mesa-panvk-bifrost-26.0.6.r5-1-aarch64.pkg.tar.xz at packages.reauktion.de/arch/aarch64/.

Three-point ship-check (on ohm, fresh pacman -S)

Repository      : marfrit
Version         : 26.0.6.r5-1
URL             : https://git.reauktion.de/marfrit/panvk-bifrost

vulkaninfo | grep -i fragmentStoresAndAtomics
    fragmentStoresAndAtomics                = true

No ~/.drirc required.

What the patch does

Backports Mesa main's unconditional .fragmentStoresAndAtomics = true flip in src/panfrost/vulkan/panvk_vX_physical_device.c. Kept the || instance->force_enable_shader_atomics disjunction as a documented kill-switch (the compiler folds it to true but the link to the DRI option pan_force_enable_shader_atomics stays semantically wired for rebases / downstream debugging).

Phase 7 verify (dEQP)

Subset r4 baseline r5 (this fix) Delta
dEQP-VK.glsl.atomic_operations.* 48 P / 0 F / 992 NS 80 P / 0 F / 960 NS +32 newly-passing, zero new failures
dEQP-VK.image.store.* 2772 P / 0 F / 238 NS 2772 P / 0 F / 238 NS identical

What this does NOT fix

Dawn still falls back to SwiftShader CPU adapter on this device — fragmentStoresAndAtomics was the first feature its PhysicalDeviceVk.cpp:InitializeImpl check rejected; with that gate cleared, Dawn presumably rejects on a subsequent silent check (no further stderr warning emitted). That work is a separate iteration; opening a follow-up issue if WebGPU HW-accel becomes a need.

Closing this issue with the warning resolved at its layer.

## Resolution Shipped via [marfrit-packages#92](https://git.reauktion.de/marfrit/marfrit-packages/pulls/92) → CI run #171 → published as `mesa-panvk-bifrost-26.0.6.r5-1-aarch64.pkg.tar.xz` at `packages.reauktion.de/arch/aarch64/`. ### Three-point ship-check (on ohm, fresh `pacman -S`) ``` Repository : marfrit Version : 26.0.6.r5-1 URL : https://git.reauktion.de/marfrit/panvk-bifrost ``` ``` vulkaninfo | grep -i fragmentStoresAndAtomics fragmentStoresAndAtomics = true ``` No `~/.drirc` required. ### What the patch does Backports Mesa main's unconditional `.fragmentStoresAndAtomics = true` flip in `src/panfrost/vulkan/panvk_vX_physical_device.c`. Kept the `|| instance->force_enable_shader_atomics` disjunction as a documented kill-switch (the compiler folds it to `true` but the link to the DRI option `pan_force_enable_shader_atomics` stays semantically wired for rebases / downstream debugging). ### Phase 7 verify (dEQP) | Subset | r4 baseline | r5 (this fix) | Delta | |---|---|---|---| | `dEQP-VK.glsl.atomic_operations.*` | 48 P / 0 F / 992 NS | **80 P / 0 F / 960 NS** | **+32 newly-passing, zero new failures** | | `dEQP-VK.image.store.*` | 2772 P / 0 F / 238 NS | 2772 P / 0 F / 238 NS | identical | ### What this does NOT fix Dawn still falls back to SwiftShader CPU adapter on this device — `fragmentStoresAndAtomics` was the **first** feature its `PhysicalDeviceVk.cpp:InitializeImpl` check rejected; with that gate cleared, Dawn presumably rejects on a subsequent silent check (no further stderr warning emitted). That work is a separate iteration; opening a follow-up issue if WebGPU HW-accel becomes a need. Closing this issue with the warning resolved at its layer.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
deferred
Phase 0 complete, parked behind another priority
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
marfrit (Markus Fritsche)
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: marfrit/panvk-bifrost#2
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?