gpu-kernels

sparq-gpu — experimental GPU compute kernels (T24d, parked)

sparq-gpu is an opt-in measurement prototype: opt-in wgpu / WGSL compute kernels for sparq's three hot-path primitive shapes — FILTER + count, hash-join probe, and GROUP BY COUNT+SUM — over plain ValueId-shaped columns (&[u32] / &[f64]). It was built to answer one question with measurements instead of aspiration:

Where (if anywhere) does a GPU beat the CPU for sparq's hot paths once the host→device transfer tax is charged honestly?

What this is — and is NOT (read first)

• It is a roadmap-T24d measurement prototype, publish = false, and parked. Nothing in the workspace depends on it; it is not wired into the query engine — there is no scheduler integration, no residency cache, no SPARQL-level routing of work to the GPU. You drive the kernels directly.
• It deliberately has no sparq-core dependency — the kernels take plain slices in exactly the shape of sparq-core's permutation-index object columns / dense numeric cache, so the engine carries zero GPU code and wgpu never enters the wasm build (cargo tree -p sparq-wasm --target wasm32-unknown-unknown contains no wgpu).
• The measured verdict is: parked. On an M1 (unified memory — the best possible transfer economics) the GPU loses or merely ties an 8-core CPU on compute-light scans even when the column is already device-resident, and only wins on the hash-probe shape. One winning kernel class does not pay for a residency cache, scheduler integration, and a second execution backend. Full tables + the re-open conditions: research/gpu-verdict.md. Do not present this crate as a GPU-accelerated query engine.

Quickstart

crates/sparq-gpu/Cargo.toml (no cargo features; publish = false):

[dependencies]
sparq-gpu = { path = "../sparq-gpu" }

Gpu::new() returns Option — no adapter ⇒ None (runtime check, so a CI box with no GPU skips gracefully):