-
Notifications
You must be signed in to change notification settings - Fork 915
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose stream-ordering to interop APIs #17397
Conversation
|
||
struct DLPackTest : public cudf::test::BaseFixture {}; | ||
|
||
TEST_F(DLPackTest, ToDLPack) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should these two tests contain assertions, such as EXPECT_NO_THROW
?
Irrelevant to this PR, I noticed that many other tests out there under cpp/tests/streams
don't have assertions. I'm curious if there's any special consideration for that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Stream tests only verify if the stream is being forwarded correctly. We do not check functional correctness here; the test tracks the test stream passed and verifies that it is used for all device operations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. I guess my question is what would be a signal of problem for these tests. Say I artificially introduced a bug where one device operation is on a stream separate from others. Do we expect cudf::to_dlpack()
to error out?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah sorry, I misunderstood what you were asking. Yes, if we use a stream other than cudf::test::get_default_stream()
for a device operation anywhere in the test, a runtime error is thrown. CUDA APIs are overloaded to check the passed stream and either raise an exception for an unexpected stream, or forward arguments to the original function.
Reference:
throw std::runtime_error("cudf_identify_stream_usage found unexpected stream!"); |
TLDR: If we invoke
cudf::to_dlpack(empty, cudf::get_default_stream())
in this test, a runtime error is thrown.
TEST_F(DLPackTest, ToDLPack) | ||
{ | ||
cudf::table_view empty(std::vector<cudf::column_view>{}); | ||
cudf::to_dlpack(empty, cudf::test::get_default_stream()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to (also) use a non-default stream for testing purpose?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question, stream testing here depends on the compile-time option STREAM_MODE_TESTING
. When it is defined, cudf::test::get_default_stream()
returns a non-default stream and the test throws for CUDA calls being invoked on any stream other than cudf::test::get_default_stream
.
Reference:
rmm::cuda_stream_view const get_default_stream() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. I learned something new today.
In this case, I still think EXPECT/ASSERT_NO_THROW
is a good practice as opposed to let the application itself throw, but that's a nit for this PR.
/merge |
Description
Adds stream parameter to
Added stream gtests to verify correct stream forwarding.
Reference: #13744
Checklist