Gpu compute - CyrilB1531/lodestar GitHub Wiki
Development build. This page describes
main, not a released package. The latest published Lodestar.Gpu is 0.2.0 — read its documentation.
GPU kernels — Lodestar.Gpu.Compute
Four kernels over ILGPU, and the device-resident types they read and write. Everything here is
additive: no package under src/ depends on this one, so the SIMD and scalar paths the rest
of Lodestar ships stay the complete answer on every target framework (decision 0003).
Three facts run through the whole namespace, and knowing them saves reading every entry.
- Residency is the point, not an optimisation. A kernel that uploads its corpus per call is
slower than the CPU path it replaces — measured at 9.25× slower for a hundred thousand
documents answering one query. The
Device*types exist so a corpus crosses the bus once and is swept many times, andsrc/Lodestar.Gpu/performance.mdhas the figures. - A kernel parameter must be blittable, so no kernel takes a
stringor aCsrMatrix. Text is renamed to symbol codes on the host; matrices are taken as spans and dimensions. The package's one inter-package edge is toLodestar.Abstractions, which declares the two Lodestar types its API names:SearchResult, whichTiledCosineTopK.Searchreturns, andMinHashScheme. - Device data belongs to the context it was uploaded to. A kernel refuses a
Device*object from anotherGpuContext, or one disposed, or its own context once disposed, before anything launches — a buffer is a pointer into one accelerator's memory, and a launch would trust it.
The types
| Type | What it does |
|---|---|
GpuContext |
Opens a device and holds the accelerator its kernels load onto. |
TiledCosineTopK |
Sweeps a resident matrix with a batch of queries: cosine, then top-k. |
TiledSparseDenseProduct |
A resident CSR matrix times a dense block, tiled through shared memory. |
BitParallelEditDistance |
Myers' edit distance from one pattern to a batch of strings. |
TiledMinHashSignatures |
MinHash signatures for a batch, one thread per permutation. |
DeviceEmbeddingMatrix |
A row-major embedding matrix held across many queries. |
DeviceSparseMatrix |
A CSR matrix held across many products. |
DeviceDenseBlock |
A dense block held between two operations, which is what makes a chain. |
DeviceTextBlock |
A batch of strings renamed to a dense alphabet and held on the device. |
DeviceTokenHashes |
One document's token hashes per row, held flat. |
MinHashScheme |
Which permutation family a signature is built from. |
Which device runs, and how to be sure
GpuContext.Create() orders the devices itself rather than asking ILGPU for a preferred one.
That is not a stylistic choice: asked for a non-CPU device, ILGPU returned an OpenCL runtime
that executes on the processor — a machine here enumerated cpu-skylake-avx512-AMD Ryzen 7 8700G
as an OpenCL device beside a CUDA card. A check on the accelerator's type called that a GPU.
So read IsHardwareGpu, not the accelerator type, and publish
DeviceName beside any figure. Create(preferCpu: true) forces ILGPU's
CPU accelerator, which is what proves a kernel correct where there is no graphics hardware —
a different question from whether it is faster, which
the package's performance page answers on a named
machine.
What this namespace does not offer
No approximate index, no Block-Max WAND, no query language. TiledCosineTopK is exhaustive: it
scores every row and selects the best k. That is the trade this package makes — brute force is
what a GPU is good at, and an approximate structure would spend its parallelism on branching.
See also — the package's performance page for what each kernel measured,
and bench/README.md sections 24 to 26 and 72 for how. Every type here applies to net10.0 and
netstandard2.1; its own page says so.