[DLPack] Update stream=None default guideline
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 25/100
- Loại issue
- Tài liệu
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Đình trệ
- Lĩnh vực
- documentation
Hướng nghiên cứu
Không có tệp hoặc kiểm thử nào được nêu tên. Hãy bắt đầu bằng cách xem lại hướng dẫn DLPack stream=None và ví dụ đồ thị CUDA trong issue này, sau đó giải quyết thảo luận về hành vi mặc định và ghi lại việc truyền stream một cách tường minh, hành vi không đồng bộ hóa và lý do; được xem là hoàn tất khi hướng dẫn và lý do đã được cập nhật nhất quán.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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.
- Ngôn ngữ chính
- Python
- Star
- 281
- Fork
- 52
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của data-apis/array-api
-
bug Maintenance Narrative Content
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 88/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
-
Maintenance
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
Tất cả issue của data-apis/array-api
Issue tương tự
-
good first issue hacktoberfest
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 92/100
RogueAlg0/taken#387 · 4 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
tool-calling
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
vllm-project/vllm#59838 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 92/100
raullenchai/Rapid-MLX#4042 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
documentation
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 92/100
transitmatters/mbta-slow-zone-bot#70 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
open-webui/open-webui#31871 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày