Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

已关闭
  • 哪里不对？
#719 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

已经有一个关联 PR 被合并了。

  • #728 来自 @maleadt —— 已合并

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
julia
领域
backend, performance

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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

主要语言
Julia
星标
218
派生
36
平均合并
1 天 6 小时
30 天内合并 PR
57

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

JuliaGPU/oneAPI.jl 的其他 Issue

查看 JuliaGPU/oneAPI.jl 的全部 Issue

相似的 Issue

更多 Julia Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。