[DO NOT MERGE] range/id term ordering issue. #2169
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
andWidthInBytes
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 thesize_t *
Region and Offset args expected bypiEnqueueMemBufferReadRect
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]