Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Bug] Geekbench 7 Background Blur: depthwiseConv_3x3 CPU translation exceeds 180s (TU117/Tahoe; v1.13 source replay)

Open
  • Is something wrong?
#111 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
34/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
backend, performance

Research direction

Start by tracing the captured depthwiseConv_3x3.linked.ll input through nvmtl_translate_fc and the sampled paths structured_plan_construct_tree, find_deep_shared_continuations, and reverse_reachable / predecessors; the issue does not name source files or provide a redistributable fixture. Measure CFG block and edge counts, clone counts, and bounded per-stage timings to identify where translation stalls. Done means a minimized reproducible input completes, produces valid SPIR-V, and passes GPU readback and the full workload.

Written by the indexing model from the issue text.

Description

Geekbench 7.1.0 Metal, explicitly selecting NVIDIA, does not finish the first Background Blur workload within a 600-second observation window. I captured the linked AIR/function constants and reproduced a long-running CPU translation without creating a Metal or Vulkan device. A locally built v1.13.0 translator also failed to finish this same captured input within a 180-second limit.

Related: #99 reports a Geekbench/translator stall, but on different hardware and at a different stage, with WindowServer/watchdog involvement. I have not established that these have the same root cause. #9's OS33 mapping change is also relevant to this machine's setup; the local DIRECT change resolves that specific initialization failure here.

Environment and scope
  • Lenovo Yoga 9 15IMH5; GTX 1650 Ti Max-Q, TU117 / 10de:1f95, 4 GiB VRAM, 256 MiB BAR1; Intel UHD 630 drives the internal panel.
  • macOS 26.7.1 (25G241), Intel Core i9-10980HK.
  • Installed driver: a locally modified v1.2.0-based headless stack, including system-memory OS33 DIRECT mapping in NVK. WindowServer stays on Intel; exact Geekbench processes are allowed. This is not an official unmodified v1.13.0 installation report.
  • Standard Metal enumeration and explicit NVIDIA selection work. GPU blit, simple compute, and offscreen render all complete with correct readback. No complete Geekbench score is available.
Captured input and CPU isolation

The selected NVIDIA Geekbench process produced depthwiseConv_3x3.linked.ll (570,286 bytes), paired with a kernel-stage .fc.txt containing eight function constants.

  • AIR SHA-256: c70b49fbcc862b67385062b5bca3d96f6fe02885f8263f358576315db72dc315
  • FC SHA-256: ef5564477028f23738a45fad012f0e60d317c2af5001105c9a9e53444d277571

A separate process loads libnvmtl_translate.dylib and invokes the actual nvmtl_translate_fc C ABI with this AIR/FC input, caps=3, and zeroed threadgroup lengths. No Metal/Vulkan device is created. The scope is this link-stage input/default TG path, not every sampler or pipeline variant.

As a positive control, ndArrayConvolution2D.linked.ll from the same capture, with its nine constants, translates successfully. The installed/rebuilt-baseline/local-candidate control output is byte-identical to the captured 33,108-byte SPIR-V, and passes strict Vulkan 1.3 validation through SPIRV-Tools. The v1.13.0 control also validates; its output differs by ID renumbering and declaration/function ordering under a strict instruction/ID-bijection comparison. This validates the replay setup for the control, not arbitrary shader equivalence.

Same-toolchain serial comparison

After all builds finished, these ran serially using Rust 1.90, the same dependency lockfile and release profile, and SDK 26.5:

Translator Result for captured depthwiseConv_3x3
Rebuilt baseline: translator sources identical to v1.2.0 No completion or SPIR-V within 180 seconds
Local candidate: hoist repeated predecessor-map construction within read-only finder calls No completion or SPIR-V within 180 seconds
v1.13.0 source at 0960b2ef5dbc4a573056d4c8e042a5bd2e15d651 No completion or SPIR-V within 180 seconds

The candidate's limited regression tests pass, but it does not resolve this real input and was not installed. Three tests requiring missing upstream fixtures were excluded only in an isolated test copy; this is not a full upstream-suite pass. These time limits do not prove an infinite loop, nor quantify an improvement. The v1.13.0 test uses the captured input from the current plugin; it is not a full official-package Geekbench comparison.

Samples repeatedly include:

structured_plan_construct_tree
find_deep_shared_continuations
reverse_reachable / predecessors

Other samples reach privatization/materialization and subsequent analysis paths. I have not determined whether the main cost is graph growth, repeated unsuccessful planning, or another mechanism. The input has barriers, so blindly bypassing structured planning or raising/lowering a size threshold has not been validated as a safe fix.

Useful next step

Would per-stage CFG block/edge counts, clone counts and bounded timing around the planner be the preferred way to narrow this? A regression should first complete this translation, produce valid SPIR-V, then pass actual GPU readback and the full workload.

The full captured framework-generated AIR and local machine logs are retained privately; a minimized redistributable fixture is not attached yet, so this report is not a self-contained public reproducer. The input fingerprints, isolated control and current source comparison are provided to distinguish this from GPU submission failure or simply selecting the Intel device.

Dominant language
Rust
Stars
2.5k
Forks
233
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from nullmoth/nvidia-macos-driver

All issues in nullmoth/nvidia-macos-driver

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.