-
Notifications
You must be signed in to change notification settings - Fork 194
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
Test IMAGE1D_BUFFER in more scenario #1806
Conversation
Reviewing. |
ed1cc3d
to
4203dcb
Compare
About the code formatting issue. I will leave the PR as it is formatted to ease the review. Once we agree on it, I'll fix those errors. |
Need some more time to review this. |
Still reviewing/testing. |
test_conformance/images/clReadWriteImage/test_read_1D_buffer.cpp
Outdated
Show resolved
Hide resolved
test_conformance/images/clReadWriteImage/test_read_1D_buffer.cpp
Outdated
Show resolved
Hide resolved
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, I've run all of these tests on an Intel GPU and they're passing, and I took a quick look through the code and everything looks in order.
There is a LOT of duplication among these tests, which makes them easier to review, but we might want to refactor to reduce the code duplication at some point (not in this PR!).
int error = clGetDeviceInfo(device, CL_DEVICE_IMAGE2D_MAX_WIDTH, | ||
sizeof(maxWidth), &maxWidth, NULL); |
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.
Can you check if this is correct? It's not clear to me if this value is used to create a 1D image, or a 1D image from a buffer, or both. If it's used to create a 1D image from a buffer then should we be querying CL_DEVICE_IMAGE_MAX_BUFFER_SIZE instead? Or, if it's both, should we be querying both and using the smallest value?
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 is used to create 1D images. We could query both to get the smallest, but it would mean we expect to have an implementation with 1D image from buffer smaller than standard 1D image. Is that really possible?
We have fixed the issue on our side. One small change needed here to add image_1d_buffer case.
|
I don't understand, I believe this PR already has the |
I think you are referring to
|
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.
Thank you for addressing comments so far, just a couple more questions.
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 the changes, just some more minor comments.
struct pitch_buffer_data *data = (struct pitch_buffer_data *)malloc( | ||
sizeof(struct pitch_buffer_data)); | ||
data->buf = host_ptr; | ||
data->is_aligned = CL_VERSION_MAJOR(version) == 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.
We believe this needs to be:
data->is_aligned = !((CL_VERSION_MAJOR(version) == 1)
|| (imageInfo->type != CL_MEM_OBJECT_IMAGE1D_BUFFER));
Following are incorrect assumption as per commit(9a49a34)
Assumption: if version == 1 and type is 1Dbuffer then buffer is aligned.
Actual: if version ==1 then buffer is always un-aligned
Assumption: if version != 1 then buffer is not aligned always.
Actual: if version != 1 and type is 1Dbuffer then buffer is aligned
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.
data->is_aligned = !((CL_VERSION_MAJOR(version) == 1)
|| (imageInfo->type != CL_MEM_OBJECT_IMAGE1D_BUFFER));
does not match
Actual: if version != 1 and type is 1Dbuffer then buffer is aligned
I think version != 1 && type is 1DBuffer
is correct. I'll push that modification.
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.
Hopefully the last one to fix and we should be good. Thank you for the incremental changes!
Merging as discussed in the April 16th teleconference. |
if (gDebugTrace) | ||
log_info(" - Creating 1D image %d ...\n", (int)imageInfo->width); | ||
|
||
buffer = clCreateBuffer( |
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.
The size passed to clCreateBuffer
and the one in the call to log_error
are different. The correct value that should be passed to both is imageInfo->rowPitch
.
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.
Shouldn't rowPitch
always equal width * pixel_size
?
But I agree, it would be better to remove the use of imageInfo->width * get_pixel_size(imageInfo->format)
in favour of imageInfo->rowPitch
.
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 should, but before the call to this function there is:
imageInfo.rowPitch += extraWidth;
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.
Then the caller might also need to be fixed either way, right?
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.
Sorry, I didn't dig into what the test is trying to do but my general comment is that whatever we pass in as the image row pitch for creating the image, should be the same value we use for creating the buffer (size of the buffer is required to be >= row pitch in this case), and the same value that we log.
do | ||
{ | ||
imageInfo.width = | ||
(size_t)random_log_in_range(16, (int)maxWidth / 32, seed); |
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.
Integer overflow here: maxWidth
is truncated from size_t
to int
.
It will cause problems:
(int)maxWidth
may be a negative integer. As a result, the function random_log_in_range
will have a second parameter which is negative so it will yield a negative result integer. Then this negative result integer will be converted to size_t
and imageInfo.width
will be a very large integer. Finally, the test will fail when trying to allocating memory of a very big size calculated from imageInfo.width
.
@rjodinchr Could you please fix the issue?
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.
random_log_in_range
is used more than 200 times in the CTS, with this same pattern many times. It feels like a proper fix would involve changing that function and making sure everything is still working as intended. I'm sorry to say I will not have time for that in the short term.
add
IMAGE1D_BUFFER
test case:IMAGE1D_BUFFER
toIMAGE1D_BUFFER
IMAGE1D_BUFFER
toIMAGE1D
IMAGE1D
toIMAGE1D_BUFFER
Most of the tests are strongly inspired from the
IMAGE1D
tests already present.Most significant changes are:
CL_DEVICE_IMAGE_MAX_BUFFER_SIZE
)IMAGE1D_BUFFER
IMAGE1D_BUFFER
in many switch/if statements in common code to support the new tests.I have made those tests because working on implementing 1dbuffer supports in clvk shows that lots of cases were not covered by the OpenCL-CTS to truly validate the implementation.
Ref kpet/clvk#403