[DLPack] Update stream=None default guideline
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 25/100
- Issue 类型
- 文档
- 描述清晰度
- 需要澄清
- 活跃度
- 停滞
调研方向
没有指定文件或测试。首先查看此 issue 中的 DLPack stream=None 指南和 CUDA 图示例，然后解决有关默认行为的讨论，并记录显式传递 stream、无同步行为及其理由；当指南和理由得到一致更新时，即视为完成。
由索引模型根据 Issue 内容生成。
描述
Previously we landed stream=None mapping to legacy default stream (a safer case). As DLPack get popularized, one most canonical use-case is to exchange between library and pytorch. As most libraries are not updated to take stream passing, and many expects that the behavior is no-sync, which works better for cases like CUDAGraph:
s = torch.cuda.Stream()
x = torch.randn(8, device="cuda")
g = torch.cuda.CUDAGraph()
with torch.cuda.stream(s):
with torch.cuda.graph(g):
_ = x + 1
mylib_tensor = mylib.from_dlpack(x)
mylib_kernel(mylib_tensor)
In the above code example, if the stream=None maps to no sync(currently stream=-1), then the cuda graph capture will work out of box. Otherwise, the cudagraph capture no longer work because of the sync. This is only the choice of default behavior as mylib can always pick a specific stream to be passed in.
So the discussion only focuses on the guideline for default behavior. The original rationale of the default was that legacy stream was a "safe choice". However, as DLPack based exchange becomes popularized and CUDAGraph integration becomes criticial. It could make sense for the default to optimize for common usecases (stream=None default to nosync if applicable).
It is worth pointing out the nosync was also the implicit original behavior before the stream proposal before frameworks get updated (many only recently like in the case of torch), so many libraries may indeed implicitly relied on such behavior.
Regardless of choices here, I think we should definitely update guideline to encourage the users to explicitly pass in stream, and document the rationale of nosync behavior, relation to CUDAgraph etc, to help libraries pick.
- 主要语言
- Python
- 星标
- 281
- 派生
- 52
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
data-apis/array-api 的其他 Issue
-
bug Maintenance Narrative Content
难度 1/5 1-3 小时 新手友好度 88/100
-
难度 2/5 1-3 小时 新手友好度 70/100
-
难度 5/5 一周以上 新手友好度 35/100
-
Maintenance
-
难度 5/5 一周以上 新手友好度 25/100
查看 data-apis/array-api 的全部 Issue
相似的 Issue
-
adr
难度 2/5 1-3 小时 新手友好度 72/100
kristofdegrave/homeassistant-smart-charging#1607 ·
维护者通常 1 天内回复
-
namespace operations
难度 2/5 1-3 小时 新手友好度 64/100
EclipseFdn/open-vsx.org#13665 ·
维护者通常 1 天内回复
-
doc good first issue help wanted
难度 2/5 1-3 小时 新手友好度 68/100
collective/icalendar#1865 · 2 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
canonical/opentelemetry-collector-operator#409 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 85/100
mozilla/addons-release-tests#1243 ·
维护者通常 1 天内回复