the readme gives this as a motivating regression: "a patch that fixes canvas and quietly desyncs WebGPU from WebGL", so i assume some rule in packages/checks compares probes/webgpu.ts output against probes/webgl.ts.
on a stock chrome on a laptop with an igpu and a dgpu (intel + nvidia, or apple silicon vs an eGPU), the two apis don't have to land on the same gpu. requestAdapter() with no powerPreference, or with high-performance, can return the discrete card, while the webgl context usually stays on the integrated one unless powerPreference is passed to getContext. so an unmodified browser could show ANGLE (Intel, ...) in WebGL and vendor: nvidia in adapter.info.
questions:
- what
powerPreference (if any) does each probe request, and do they match?
- does the check compare vendor only, or architecture/device too?
- is a vendor mismatch on real hardware scored as a lie, or is there an allowance for multi-adapter machines?
if it's a straight vendor equality, i'd expect this to be a common false positive on dev laptops.
the readme gives this as a motivating regression: "a patch that fixes canvas and quietly desyncs WebGPU from WebGL", so i assume some rule in
packages/checkscomparesprobes/webgpu.tsoutput againstprobes/webgl.ts.on a stock chrome on a laptop with an igpu and a dgpu (intel + nvidia, or apple silicon vs an eGPU), the two apis don't have to land on the same gpu.
requestAdapter()with nopowerPreference, or withhigh-performance, can return the discrete card, while the webgl context usually stays on the integrated one unlesspowerPreferenceis passed togetContext. so an unmodified browser could showANGLE (Intel, ...)in WebGL andvendor: nvidiainadapter.info.questions:
powerPreference(if any) does each probe request, and do they match?if it's a straight vendor equality, i'd expect this to be a common false positive on dev laptops.