Uh oh!
There was an error while loading. Please reload this page.
Add support for CI testing - #124
Conversation
sandeepd-nv
commented
Sep 26, 2024
Blocked on #128. |
leofang
commented
Oct 9, 2024
See #128 (comment), thx! |
7763fc9 to
8e11153Compare19b1525 to
5ffa6b7CompareUh oh!
There was an error while loading. Please reload this page.
Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
leofang
commented
Dec 7, 2024
/ok to test |
leofang
commented
Dec 8, 2024
/ok to test |
leofang
commented
Dec 8, 2024
/ok to test |
leofang
commented
Dec 8, 2024
/ok to test |
leofang
commented
Dec 8, 2024
/ok to test |
1 similar comment
leofang
commented
Dec 8, 2024
/ok to test |
leofang
commented
Dec 8, 2024
/ok to test |
Here are some updates since Friday:
It turns out that this is a misunderstanding (of mine), sorry! It's the other way around: It's the composite actions that do this, not reusable workflows, see, e.g. https://docs.github.com/en/actions/sharing-automations/avoiding-duplication#comparison-of-reusable-workflows-and-composite-actions. So I refactored in the opposite (and wrong) direction. Let us do this (change all composite actions to reusable workflows) in a follow-up PR since the CI is now working and there's no reason to delay.
This is another misunderstanding (of mine), sorry (again)! For both cases (distinct jobs vs distinct workflows), it require some handling of input/output. There's no way for sharing the env vars in either case.
As part of this I removed all CI scripts in commit 7b074f0. It is the best that we focus on testing pip-based workflows for now, and add conda next (which would be treated differently). Mixing-and-matching is not ideal. |
| @pytest.fixture(scope="session", autouse=True) | ||
| def always_init_cuda(): | ||
| handle_return(driver.cuInit(0)) |
There was a problem hiding this comment.
FYI, @ksimpson-work the CI was able to catch this issue: Depending on how the tests are run, it could be possible that a test ends without CUDA even initialized. So we must ensure it ourselves by the test start time.
| ctx = handle_return(driver.cuCtxGetCurrent()) | ||
| if int(ctx) == 0: | ||
| # no active context, do nothing | ||
| return |
There was a problem hiding this comment.
FYI, @ksimpson-work another issue caught by the CI (and also back in #261): A test could end early without a CUDA context set current, so we need to detect this at the test teardown time.
| import os | ||
| import sys | ||
| import cupy as cp |
There was a problem hiding this comment.
For now I treat CuPy as an optional test dependency, so any reference to CuPy in this file should be removed. (We're not using too much memory during tests anyway.)
| def can_load_generated_ptx(): | ||
| _, driver_ver = cuda.cuDriverGetVersion() | ||
| _, nvrtc_major, nvrtc_minor = nvrtc.nvrtcVersion() | ||
| if nvrtc_major * 1000 + nvrtc_minor * 10 > driver_ver: | ||
| return False | ||
| return True |
There was a problem hiding this comment.
FYI @ksimpson-work this is akin to this snippet that I added to CuPy in the past (PTX might not be loadable/JIT'able if it's newer than the driver):
https://github.com/cupy/cupy/blob/8eb16ac910e85c119a20f68a69de9a2e6034069c/tests/cupy_tests/core_tests/test_raw.py#L557-L568
leofang
commented
Dec 8, 2024
Thanks for help, @sandeepd-nv! |
No description provided.