-
Notifications
You must be signed in to change notification settings - Fork 88
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
Copy device_matrix_data into arrays #1476
Conversation
This fixes an issue in #1450 |
c0c8c28
to
dc1a10f
Compare
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.
LGTM!
49ac14f
to
9d106fc
Compare
6e43034
to
60c2269
Compare
format! |
Another question: how should |
This only applies to Csr and Coo only, right? In that case, I would suggest calling |
30f36b5
to
8a3d846
Compare
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.
LGTM for the most part, only some test assertions are throwing instead of failing the test directly.
b86c726
to
5ae2e93
Compare
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.
Macro change and usage of this->
Also a general question: Is a macro part of the public interface and if so does removing a macro mean breaking interface ? |
ec54be8
to
93777dc
Compare
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 for updating this! LGTM!
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.
LGTM! The macro is part of our public headers, but to me, it's only intended for internal usage, so I'm fine with removing it. There is no such thing as a detail
macro after all.
81d2064
to
284f979
Compare
284f979
to
d113c9c
Compare
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.
I do not think the device_matrix_data view means the matrix also be a view on it.
If user want the Coo view on the device_matrix_data view, they can use the Coo constructor rather than the read
auto row_idxs = gko::array<index_type>(this->exec, 4); | ||
auto col_idxs = gko::array<index_type>(this->exec, 4); | ||
auto values = gko::array<value_type>(this->exec, 4); | ||
auto m = Mtx::create(this->exec, gko::dim<2>{2, 3}, values.as_view(), | ||
col_idxs.as_view(), row_idxs.as_view()); |
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.
if the view is larger than read size?
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.
I will add tests to check that is throws.
// the device matrix data contains views on the column indices | ||
// and values array of this matrix, and an owning array for the | ||
// row indices (which doesn't exist in this matrix) |
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.
It introduces the inconsistence.
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.
we had the same view + owning split previously when moving from a device_matrix_data
, because row pointers need to be allocated separately in any case.
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.
Yes, discussed something related to this with @MarcelKoch. My question is not introduced in this pr.
I will create another issue and we can discuss the reason there.
I'm not understanding this. Do you want to see something changed? |
ASSERT_EQ(orig_row_idxs, m->get_row_idxs()); | ||
ASSERT_EQ(orig_col_idxs, m->get_col_idxs()); | ||
ASSERT_EQ(orig_values, m->get_values()); |
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.
matrix array view is now to use the device_data view not the original one
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.
yes, but device_data is empty after the move, so we need to store the pointers beforehand.
24272c3
to
a773e16
Compare
// the device matrix data contains views on the column indices | ||
// and values array of this matrix, and an owning array for the | ||
// row indices (which doesn't exist in this matrix) |
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.
Yes, discussed something related to this with @MarcelKoch. My question is not introduced in this pr.
I will create another issue and we can discuss the reason there.
core/test/base/array.cpp
Outdated
EXPECT_EQ(view.get_data()[2], TypeParam{3}); | ||
EXPECT_EQ(view.get_size(), 3); | ||
EXPECT_EQ(const_view3.get_size(), 3); | ||
ASSERT_THROW(view = const_view2, gko::ValueMismatch); |
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.
if you use GKO_ENSURE_COMPATIBLE_BOUNDS
, then it is accepted.
a773e16
to
4f36649
Compare
Co-authored-by: Marcel Koch <[email protected]>
- ensure equal bounds - don't make row_ptrs owning - disable conversion assignment - add in-code comment - fix tests - use this-> - add tests for incompatible reads Co-authored-by: Tobias Ribizel <[email protected]> Co-authored-by: Pratik Nayak <[email protected]> Co-authored-by: Yu-Hsiang M. Tsai <[email protected]>
4f36649
to
c99bce3
Compare
Kudos, SonarCloud Quality Gate passed! 0 Bugs 95.2% Coverage The version of Java (11.0.3) you have used to run this analysis is deprecated and we will stop accepting it soon. Please update to at least Java 17. |
This PR changes the behavior for the
read(const device_matrix_data&)
overload forCoo
andCsr
.Currently, the
const &
read overload copies the input device_matrix_data and moves it into the&&
overload. The&&
overload will cause the internal arrays of the matrix to use the arrays of the device_matrix_data. This means that if the matrix was created from views, the matrix after the read will have owning arrays.For the
&&
overload this is justified, since here the matrix takes ownership of the input data. But for theconst &
it's unexpected, since no ownership is transferred. So, this PR makes theconst &
copy the input device matrix data directly into the matrix's arrays. The ownership property of the internal arrays will thus be preserved.Note: The behavior of theI was under the impression that device_matrix_data always owns its arrays. But that is not the case. The device_matrix_data can also be constructed from array, which might be views.&&
overload is a bit inconsistent across our matrix types. ForCoo
andCsr
the&&
overload will result in the matrix arrays having ownership. But for all other matrix types, the ownership property is not changed. Maybe we should consolidate that.