Skip to content

[DO NOT MERGE] range/id term ordering issue. #2169

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

Closed
wants to merge 1 commit into from

Conversation

cperkinsintel
Copy link
Contributor

@cperkinsintel cperkinsintel commented Jul 23, 2020

demonstrates an issue. Not sure how to test. Not proposing this as solution.

Hi @romanovvlad ,

So, when working on my sub-buffer PR ( #2085 ), I encountered a problem with some tests failing on CUDA. The tests were failing when sub-buffers of a 2D base buffer were copying back. The problem is that the terms being passed to CUDA were reversed. So Height and WidthInBytes would be wrong. (They were really width and height in bytes). When updating a full buffer, this doesn't really matter. Because hWb is the same as wHb and no trouble was encountered.

But it matters for the partial updates the 2D buffers are trying to perform. Fundamentally, the problem is that an id<3> or a range<3> is supposed to be [z, y, x] But the size_t * Region and Offset args expected by piEnqueueMemBufferReadRect are typically [x-in-bytes, y, z ] , the reverse order and the x-term in bytes.

Anyway, in this patch (which is for discussion, not submission) you can see that I reverse the terms. For my sub-buffer PR, this patch fixes the faiilng CUDA test. However, to my mind, making this change only in copyD2H is likely wrong. This same exercise needs to be performed in copyH2D, copyD2D and others.

Plus, were we to really do this right, we would add a new typedef for the Region/Offsets (instead of generic size_t *) and provide a converter function to switch Range<> to Region and id<> to Offsets. This would help avoid confusion. However, if we made such a change, that might also mean replacing the weird range<3>s we have in accessor_impl.hpp with Regions and that's a pretty central class. Not sure what the consequences would be.

Question: how can I make a lit test that guarantees the right order of the arguments being passed to the piEnqueueMemBufferReadRect ? Do we have a way to inject assertions when testing?

Anyway, to get my PR passing, I'll need some guidance. Any advice welcome.

Signed-off-by: Chris Perkins [email protected]

@cperkinsintel cperkinsintel requested a review from a team as a code owner July 23, 2020 21:39
@cperkinsintel cperkinsintel deleted the range-order-testing branch August 4, 2020 19:02
jsji pushed a commit that referenced this pull request Oct 5, 2023
…2169)

Definition of StringRef.consume_front also performs prefix check.
It makes additional check redundant.

Original commit:
KhronosGroup/SPIRV-LLVM-Translator@21cc1d0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant