The coverage fold's gain is out by up to 0.9 dB on a directional antenna, against its CPU twin

On a real Intel integrated GPU the coverage fold kernel disagrees with its CPU twin by more than the tolerance, so the device fails its own self-check and MeshBench falls back to the processor.

First run of these kernels on real Windows hardware. windows-check.yml's own header says why that matters:

The GPU kernels are proven on Metal (a real Mac) and on Vulkan (Linux), and have never once been run on DX12 … A kernel that is wrong there fails as a silently slow or silently empty link warm, which is exactly the kind of bug that reaches a user.

What happens

Windows 10, Intel UHD Graphics 620, driver 27.20.100.8853. wgpu picks Vulkan here, not DX12 — so this is not the DX12 path that header is about, and DX12 remains untested.

--- FAIL: TestCoverageFoldMatchesCPU
    coveragefold_equiv_test.go:95: best: 100 of 9216 cells disagree with the CPU twin
--- FAIL: TestSelfCheckPassesOnARealDevice
    selfcheck_test.go:19: a correct device failed its own self-check:
                          fold best: cell 408's margin disagrees with the processor by 0.07 dB

The tolerance is 0.05 dB; the worst disagreement is 0.07 dB, on about 1% of cells.

The base coverage kernel is fine on the same device, which is what makes this specific rather than "this GPU is bad":

--- PASS: TestCoverageKernelMatchesCPU
    coverage_equiv_test.go:45: GPU: 0x3ea0 (vulkan)
    coverage_equiv_test.go:87: worst disagreement 0.0263 dB over 9216 cells

0.026 dB for the raster, 0.07 dB once it is folded into best/second per cell. Whatever the fold does beyond the raster is where the difference is.

The product behaves correctly, which is the good news

gpuwarm.go runs SelfCheck before trusting the device and records why when it fails:

if err := d.SelfCheck(); err != nil {
    p.present, p.why = false, err.Error()
}

So nothing wrong is computed. A user on this hardware gets coverage on the CPU, which is what CLAUDE.md promises — "a machine without a usable GPU loses time, not features" — and the reason is available rather than hidden. This is not a correctness bug in results.

What it costs, and what to decide

Everyone on Intel integrated graphics — a large share of Windows laptops — silently loses GPU coverage. That is the "silently slow" half of the sentence quoted above, and it is worth knowing before a release rather than after.

The question is which of these it is, and I do not think it can be answered from here:

the fold kernel is wrong, subtly, in a way Metal and Vulkan-on-Linux happen not to expose — in which case the self-check is doing its job and the kernel wants fixing
0.05 dB is too tight for float32 accumulation on this hardware, and the fold's arithmetic legitimately lands 0.07 dB away — in which case the tolerance wants widening with a reason, not loosening to make a test pass

The base kernel agreeing to half the tolerance on the same device is evidence for the first. TestCoverageFoldMatchesCPU's own comment already allows a rank swap at a near-tie as float noise, so the shape of the problem was anticipated; this is past that allowance.

One thing possibly relevant: wgpu warns on every device open here.

[wgpu] [Warn] Disabling robustBufferAccess2 and robustImageAccess2: IntegratedGpu Intel
Driver is outdated. Found with version 0x192295, less than the known good version
0x194843 (31.0.101.2115)

Worth ruling in or out with a newer driver before concluding anything about the kernel.

And a process note

windows-check.yml runs go test ./internal/rf/gpu/ with continue-on-error: true, on a hosted runner where wgpu falls back to WARP, DX12's software rasteriser. So this job has never had a real GPU to disagree with, and would not have gone red if it had. That is deliberate — the comment says the GPU step is exploratory — but it does mean the only signal here is somebody running it on their own machine, which is how this was found.

internal: go test passes on Windows (#526) (#531)

Narrowed it down. It is the azimuth gain, on the beam, and it is bigger than the self-check suggests.

I put a diagnostic through the same ADR-0004 harness to separate the kinds of disagreement. The result is much tighter than "0.07 dB, maybe a tolerance":

same station, margin differs:  100 cells, worst 0.9112 dB
different station picked:        0 cells, worst 0.0000 dB
by the station the CPU picked:  map[1:100]
of those, within 5 km of station 1:   0
                    further out:    100

Four things fall out of that, and together they rule most explanations out.

It is not a ranking problem. Zero cells pick a different station. The fold's ordering is identical to the CPU's; only the margin it records differs. So TestCoverageFoldMatchesCPU's existing allowance for a rank swap at a near-tie is not what is being exercised.

It is entirely the directional antenna. All 100 cells belong to station 1, the only one with a pattern:

func(b, e float64) float64 {
    return 9 - 12*math.Pow(math.Sin((b-45)*math.Pi/360), 2) - 0.1*math.Abs(e)
}

Stations 0 and 2 are flat — 2.15 dBi and 5.0 dBi — and contribute nothing. That is the tell: a wrong gain lookup is invisible on a constant table, because every index holds the same number. The harness's own comment says the directional station is there so "the gain table's interpolation is on trial too", and it is the only thing failing.

It is not the near-mast elevation case. Every one of the 100 is more than 5 km out. Close in, elevation is steep and a small distance difference moves it a lot — that would have been the comfortable explanation, and it is not this. Out there the pattern is governed by azimuth.

And it is far too large for f32 rounding. The pattern's steepest slope is 12·(π/360) ≈ 0.105 dB per degree of azimuth, so 0.91 dB is about 8.7 degrees of azimuth disagreement. Single precision on a bearing computed from latitudes and longitudes is nowhere near that. Something systematic differs between how the shader and the twin arrive at the azimuth they look up, not how precisely they round it.

What I checked and eliminated

The uniform layout. Budget in coverage.wgsl and the budget slice in coveragefold.go agree field for field, including az_n, el_n, el_min, el_step and the two pads. A mismatch there would have been exactly this shape — invisible on flat patterns, wrong on a beam — so it was the first thing to look at.
The interpolation itself. gain_db and GainTable.Sample are the same arithmetic in the same order, wrapping azimuth and clamping elevation identically. Sample's comment says "interpolates the table exactly as the kernel does", and as written it does.
The table's contents. Uploaded straight from gt.DB, which is []float32 on both sides, so nothing is converted on the way.

That leaves the inputs: bearing_deg and the elevation handed to gain_db, against whatever the CPU twin computes before calling Sample. Eight degrees is the number to explain.

Why nothing has caught it

gpu.Open refuses an adapter that reports itself as CPU, and no CI runner has a real GPU — ci.yml says so at length, and it is the right call. So TestCoverageFoldMatchesCPU skips everywhere in CI, on Linux as well as on the Windows job. It runs on a real Mac, on the maintainer's Linux GPU, and now here. This is not a Windows fault and I should not have implied it was one by tagging it that way: it is the first time this kernel has been checked against its twin on a third device.

Whether Metal and the Linux GPU agree with the CPU where this one does not is the next thing worth knowing, and I cannot answer it from here. If they do, the difference is in how this driver compiles the shader. If they do not, the kernel has been out by up to a decibel on directional antennas everywhere, and CLAUDE.md says what that costs: "A wrong FFT does not crash; it produces a plausible waterfall and slightly wrong sensitivity, and nobody notices for months." A beam mispriced by 0.9 dB is the same failure wearing an antenna.

The diagnostic

Not committed — it asserts nothing. Dropping this in internal/rf/gpu reproduces the table above; it is the existing TestCoverageFoldMatchesCPU harness with the comparison broken apart.

var swaps, numeric int
var worstSwap, worstNumeric float64
byStation := map[int32]int{}
for i := range wantBest {
    dm := math.Abs(float64(gotBest[i].MinDB - wantBest[i].MinDB))
    if gotBest[i].Station != wantBest[i].Station {
        if dm > 0.05 {
            swaps++
            byStation[wantBest[i].Station]++
            if dm > worstSwap { worstSwap = dm }
        }
        continue
    }
    if dm > 0.05 {
        numeric++
        byStation[wantBest[i].Station]++
        if dm > worstNumeric { worstNumeric = dm }
    }
}

Device here: Intel UHD Graphics 620, driver 27.20.100.8853, wgpu selecting Vulkan (not DX12 — that backend is still untested by anything). wgpu also warns Disabling robustBufferAccess2 and robustImageAccess2: IntegratedGpu Intel Driver is outdated, which is worth ruling out with a newer driver before concluding it is the kernel.

The product still behaves correctly throughout: SelfCheck refuses this device and coverage runs on the processor, with the reason recorded.

firmware, cmd, package: the Windows pass (#497)

The open question here was whether the fold kernel is wrong or 0.05 dB is too tight. I cannot reproduce it - this machine's GPU passes TestCoverageFoldMatchesCPU - but the mechanism can be measured without the hardware, and it answers the question.

What the fold does that the raster does not

let bearing = bearing_deg(p.st_lat, p.st_lon, ll.x, ll.y);
let elev = atan2(rx_alt - p.st_alt, dist_km * 1000.0) * 180.0 / PI;
let g = gain_db(bearing, elev);

Three things: a bearing from sin/cos/atan2, an elevation from atan2, and a sampled antenna pattern. The base kernel has none of them, which is exactly the split in the numbers here: 0.026 dB for the raster, 0.07 dB once folded.

The interpolation is not the difference. gain_db is bilinear and its comment is accurate: the CPU twin's GainTable.Sample interpolates identically.

The difference is the arithmetic width. geo.BearingDeg computes that formula in float64. The kernel computes it in f32, and then uses the result to index a pattern that can be steep.

Measured

Running the kernel's formula in f32 against geo.BearingDeg in f64, over a 96x96 raster around the fold test's own geometry:

worst f32-vs-f64 bearing drift over a 96x96 raster: 0.0095 deg

To turn 0.0095 deg into the observed 0.07 dB needs a pattern gradient of 7.3 dB/deg. A yagi or a sector near a pattern edge exceeds that comfortably; a 10 dB/deg transition would give 0.10 dB.

And that figure is a best case for the GPU: it uses Go's float64 sin/cos/atan2 rounded to f32. A real device's f32 trig carries its own error on top, Vulkan permits several ULP, and this issue's report notes the driver is older than the known-good version.

So which is it

Both readings in the issue were half right, and the third option is the true one: the kernel is not wrong, and the tolerance is not merely too tight - the kernel is precision-limited by construction, and the fold is where that becomes visible because only the fold multiplies a direction into a steep function.

That also explains the platform split without appealing to "this GPU is bad". Metal and Vulkan-on-Linux have trig accurate enough that the drift lands under 0.05 dB. Intel with the older driver does not.

What that suggests doing

Reduce the sensitivity rather than the standard. The station is one point for a whole raster, so anything depending only on it can be computed in f64 on the host and passed in. That removes the largest-magnitude trig arguments from the kernel. Worth measuring before committing to: my own attempt at that measurement had a bug in the harness and I am not reporting a number for it.
If a tolerance change is still needed after that, tie it to the gradient rather than picking a bigger constant. "0.05 dB" is a statement about a flat pattern; the honest bound scales with how steep the pattern is at the sampled bearing, and the test knows its own antenna.
Either way the self-check is doing its job and the product is behaving correctly, as this issue already says.

Still needs the hardware

Whatever is changed has to be confirmed on the Intel machine, because this one cannot fail the test in the first place. The measurement above narrows what to try; it does not close the issue.

gpu: the fold's bearing no longer depends on the driver's trig

GPU coverage fold: compute the bearing without the driver's trig (#779)

Reopened: #779 is merged but not yet confirmed on the UHD 620. Run go test ./internal/rf/gpu/ -run 'TestKernelTwins|TestSelfCheck' -v there and close this if the fold comparison passes.

Navigation Menu

Repository navigation

The coverage fold's gain is out by up to 0.9 dB on a directional antenna, against its CPU twin #530

What happens

The product behaves correctly, which is the good news

What it costs, and what to decide

And a process note

Narrowed it down. It is the azimuth gain, on the beam, and it is bigger than the self-check suggests.

What I checked and eliminated

Why nothing has caught it

The diagnostic

What the fold does that the raster does not

Measured

So which is it

What that suggests doing

Still needs the hardware

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

The coverage fold's gain is out by up to 0.9 dB on a directional antenna, against its CPU twin #530

Description

What happens

The product behaves correctly, which is the good news

What it costs, and what to decide

And a process note

Activity

A13xB0 commented on Sep 2, 2026

Narrowed it down. It is the azimuth gain, on the beam, and it is bigger than the self-check suggests.

What I checked and eliminated

Why nothing has caught it

The diagnostic

A13xB0 commented on Sep 2, 2026

What the fold does that the raster does not

Measured

So which is it

What that suggests doing

Still needs the hardware

A13xB0 commented on Oct 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions