Roadmap

This page tracks work that is intentionally deferred or planned but not yet part of the library. It exists so the repo can evolve without keeping separate version-plan documents. Items are grouped by area and listed from most to least impactful for the next engineering effort.

Note

“Deferred” means the idea is understood but not implemented. “Planned” means it is the next concrete piece of work. Nothing here blocks correctness of the currently shipped functionality.

Benchmark automation and CI

  • Benchmark regression CI (Phase 44). Store benchmark JSON output as a baseline on each meaningful change, compare in CI, and block regressions over 10%. Threshold: 5% warns, 10% blocks. A multi-GPU benchmark matrix is the eventual target (currently only the RX 9070 has numbers).

  • Per-op kernel-only timestamp instrumentation (42a). A BenchTimestampPool exists, but full per-op instrumentation needs per-op hooks: a separate command buffer with vkCmdWriteTimestamp around each dispatch. Current bandwidth numbers are estimated as wall time minus PCIe transfer.

  • Occupancy / register introspection (42b). VK_KHR_pipeline_executable_properties is available on RADV, but per-pipeline register/occupancy queries are not implemented.

  • Polars CPU baselines and a 5-op chained benchmark (41c/41d). Multi- threaded CPU baselines exist for all ops; Polars-specific CPU baselines and a longer chained benchmark remain.

Algorithmic optimizations

  • Filter: eliminate the CPU sync point (43a-next). The 3-pass filter still reads back a per-workgroup total. A GPU-side inter-workgroup scan or a persistent-thread approach would remove that round-trip, at the cost of significant complexity. Current utilization at 16M elements is already 63% of HBM peak.

  • Join: true persistent kernel (43c-next). Join submits are batched per partition, but a persistent kernel looping over right-table partitions in a single dispatch would eliminate partition-loop submits entirely. Requires a global atomic output-offset counter instead of per-workgroup prefix-sum scatter. Note: join is currently PCIe-bound, so submit reduction alone is modest.

  • Single command buffer chaining (O8). Reuse one command buffer across chained operations to cut dispatch overhead further.

  • Slice: device-side copy. vc_slice currently round-trips through the host. For chained operations where data is already in VRAM, vkCmdCopyBuffer could avoid that transfer.

  • List sort/unique: GPU path. List sort and unique currently use host-side std::sort per subrange. A shared-memory bitonic sort for small lists is the intended GPU-accelerated follow-up.

  • Group-by pre-sizing and multi-workgroup segment detection (O3/O4). GPU memory pre-sizing and multi-workgroup segment detection are understood but deferred; measured impact is small for the current sort-based path.

Distribution and packaging

  • Prebuilt wheels for Linux and macOS (Phase 37). Windows x86_64 wheels are done. Linux x86_64 (RADV/ANV/NVIDIA) and macOS ARM64 (MoltenVK) matrices remain.

  • PyPI trusted publishing. Wheels are built and installable locally; publishing to PyPI via trusted publishing is a future distribution step.

  • `faq.rst`. A user-facing “Why Vulkan?” / “Why not CUDA?” page is planned but not written.

Interop hardening

  • List/Struct Arrow interop. Numeric and string Arrow import/export are complete. List and Struct Arrow C Data Interface support is a follow-up (nested buffers plus the child/schema arrays).

  • Large columns (>2GB) with U64 Arrow offsets. String import already reads large_utf8 (U) offsets, but the library’s internal offsets are U32. Full >2GB column support requires widening the internal offset type.

Integration repositories

Framework integrations live in separate repositories and are not part of the core library. Their plans are maintained there:

  • vulkan-columnar-polars — Rust crate plus Python import patcher for transparent Polars acceleration.

  • vulkan-columnar-spark — Scala/JVM Spark plugin with a JNI bridge.