Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Make host-to-device uploads non-blocking via a host-USM staging pool

Chiusa
  • Qualcosa non va?
#719 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Una pull request collegata è già stata integrata.

  • #728 di @maleadt — integrata

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
julia
Ambito
backend, performance

Direzione di ricerca

Start in src/array.jl at the synchronizing upload path, then read how Batch uses host-visible events and how retire! reclaims completed work. The issue proposes a per-oneStream host-USM staging ring, slot recycling, and a synchronizing path above roughly 1 MiB. Done means uploads can return without synchronizing while preserving source safety, with exhausted slots waiting for the oldest transfer.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Since #618, copyto!(::oneArray, ::Array) (and so oneArray(::Array), adapt, scalar setindex!, ZeRef, the oneMKL batched pointer tables) ends with synchronize(stream) (src/array.jl). That's needed for safety: Level Zero gives no staging guarantee (the implementation "must not access the memory pointed to by dstptr and srcptr as they are free to be modified ... up until execution"), and NEO wraps pageable sources as userptr allocations that the GPU reads when the copy executes. But it makes every upload wait for all previously queued work.

NEO's own staging (EnableCopyWithStagingBuffers) can't be relied on: it's default-on only for Xe2/Xe3, and stages a given host pointer only once per hostSynchronize. Measured on Iris Xe (NEO 26.35), queueing a 150 ms kernel, appending a copy and mutating the source right after the append returns:

source 1 KB – 256 MB
pageable, default mutated data arrives
pageable, staging forced on original data, but a second upload of the same buffer without a sync reads the later mutation
host USM mutated data arrives

Cost on the same Iris Xe (~29 µs kernel, ×1000, three runs each; shared host so noisy), vs a prototype staging through a ring of host-USM slots:

current staged prototype
idle 1 KB upload ~140 µs ~55 µs
kernel + 1 KB copyto! + kernel 317–522 ms 142–160 ms
kernel + oneArray(1 KB) 220–253 ms 130–143 ms

Staging is even faster than appending directly from pageable memory (an unsafe upper bound measured at 124–175 ms for the first loop), as it avoids NEO's per-call userptr import.

Proposal (what CUDA's driver does for pageable memory, and CuPy with its pinned memory pool):

  • a per-oneStream ring of host-USM (zeMemAllocHost) staging slots;
  • memcpy the source into a slot, append the copy with a host-visible event (like Batch already uses) as its signal, and return;
  • recycle slots once their event is done (alongside retire!), waiting on the oldest slot only when the ring is exhausted;
  • keep the synchronizing path above a threshold (~1 MiB).

x-ref JuliaGPU/CUDA.jl#2510, JuliaGPU/CUDA.jl#3425

Lingua principale
Julia
Stelle
218
Fork
36
Merge medio
1g 4h
PR unite (30g)
55

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di JuliaGPU/oneAPI.jl

Tutte le issue di JuliaGPU/oneAPI.jl

Issue simili

Altre issue su Julia

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.