-
Notifications
You must be signed in to change notification settings - Fork 89
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
fix: ListArray slicing on GPU #3248
Conversation
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.
@jpivarski - found the issue :-)
The numpy.ndarray
head that is 0
is not passed to the GPU kernel!
awkward/src/awkward/contents/listarray.py
Line 731 in ba9b4d1
head, |
in
awkward/src/awkward/contents/listarray.py
Lines 710 to 733 in ba9b4d1
elif is_integer_like(head): | |
assert advanced is None | |
nexthead, nexttail = ak._slicing.head_tail(tail) | |
lenstarts = self._starts.length | |
nextcarry = ak.index.Index64.empty(lenstarts, self._backend.index_nplike) | |
assert ( | |
nextcarry.nplike is self._backend.index_nplike | |
and self._starts.nplike is self._backend.index_nplike | |
and self._stops.nplike is self._backend.index_nplike | |
) | |
self._maybe_index_error( | |
self._backend[ | |
"awkward_ListArray_getitem_next_at", | |
nextcarry.dtype.type, | |
self._starts.dtype.type, | |
self._stops.dtype.type, | |
]( | |
nextcarry.data, | |
self._starts.data, | |
self._stops.data, | |
lenstarts, | |
head, | |
), | |
slicer=head, |
head in this case can be an array and it can be regularized to a proper backend, then the GPU kernel needs to be updated to handle a 'cp.array(0)'
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.
@martindurant - as discussed at today's awkward-uproot meeting this is a temporary fix. I will rewrite the way we handle this CUDA kernel wrapping it in a Python function and handling the 'at' type correctly.
+1, please let me know when this is out. |
Any chance of a few more test cases like [:, 1:], [:, :1], [:, 1::2], [:, ::-1] ? |
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.
@jpivarski - Please, check when you have time. I think, using roles in this case is appropriate. I cannot find tests where the awkward_ListArray_getitem_jagged_expand
is used yet. It looks like it should be invoked when a ListArray
sliced with ListOffsetArray
. It could be a different PR though. Thanks!
I used the trick of adding if index[0] == "awkward_ListArray_getitem_jagged_expand":
raise Exception("HERE") to awkward/src/awkward/_backends/numpy.py Lines 35 to 36 in 3712032
and found exactly 1 test where it's used: tests/test_0111_jagged_and_masked_getitem.py in
|
Thanks! Yes, this test is on
The CUDA tests are implemented for this and the results are equivalent to the ones produced on CPU. |
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 talked about this at length in our meeting, and I'm on board with making this kind of change.
We also said that we'll need an automated check across all CUDA kernels (implemented once, where the kernels are built) to discover these C type errors in the future: int
vs int*
. (This is a missing feature of cupy.RawKernel
!)
I am still getting a breakage with selecting by integer, as opposed to slice (and hereafter, results on the GPU are garbage). I haven't managed to make a reproducer yet! |
hmm... I think, that what we have discussed with @jpivarski might happen. |
No description provided.