Skip to content
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

Merged
merged 21 commits into from
Apr 16, 2024
Merged

Conversation

rjodinchr
Copy link
Contributor

add IMAGE1D_BUFFER test case:

  • cl_copy_images:
    • IMAGE1D_BUFFER to IMAGE1D_BUFFER
    • IMAGE1D_BUFFER to IMAGE1D
    • IMAGE1D to IMAGE1D_BUFFER
  • cl_get_info
  • cl_fill_image
  • cl_read_write_image
  • kernel_image_methods

Most of the tests are strongly inspired from the IMAGE1D tests already present.
Most significant changes are:

  • Using the correct limit to choose the size (using CL_DEVICE_IMAGE_MAX_BUFFER_SIZE)
  • Creating the buffer needed for IMAGE1D_BUFFER
  • Add 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

@lakshmih
Copy link
Contributor

Reviewing.

@rjodinchr
Copy link
Contributor Author

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.

@lakshmih
Copy link
Contributor

lakshmih commented Oct 2, 2023

Need some more time to review this.

@lakshmih
Copy link
Contributor

lakshmih commented Oct 4, 2023

Still reviewing/testing.

bashbaug
bashbaug previously approved these changes Feb 13, 2024
Copy link
Contributor

@bashbaug bashbaug left a 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!).

Comment on lines +241 to +244
int error = clGetDeviceInfo(device, CL_DEVICE_IMAGE2D_MAX_WIDTH,
sizeof(maxWidth), &maxWidth, NULL);
Copy link
Contributor

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?

Copy link
Contributor Author

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?

@nikhiljnv
Copy link
Contributor

We are seeing some issues on NVIDIA implementation with the changes proposed in this PR. Will update in a couple of days once we dig into this more.

We have fixed the issue on our side. One small change needed here to add image_1d_buffer case.

@rjodinchr
Copy link
Contributor Author

We are seeing some issues on NVIDIA implementation with the changes proposed in this PR. Will update in a couple of days once we dig into this more.

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 CL_MEM_OBJECT_IMAGE1D_BUFFER case in the switch you mentioned. But the link you gave is not the one from this PR, thus that's why it is missing.

@nikhiljnv
Copy link
Contributor

We are seeing some issues on NVIDIA implementation with the changes proposed in this PR. Will update in a couple of days once we dig into this more.

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 CL_MEM_OBJECT_IMAGE1D_BUFFER case in the switch you mentioned. But the link you gave is not the one from this PR, thus that's why it is missing.

I think you are referring to

case CL_MEM_OBJECT_IMAGE1D_BUFFER:
from this PR, whereas the one I was referring to is here in this PR

@rjodinchr rjodinchr requested a review from lakshmih March 5, 2024 08:36
Copy link
Contributor

@lakshmih lakshmih left a 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.

test_conformance/images/clFillImage/test_fill_generic.cpp Outdated Show resolved Hide resolved
test_conformance/images/clFillImage/test_fill_generic.cpp Outdated Show resolved Hide resolved
@rjodinchr rjodinchr requested a review from lakshmih March 12, 2024 07:00
Copy link
Contributor

@lakshmih lakshmih left a 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.

@rjodinchr rjodinchr requested a review from lakshmih March 27, 2024 08:37
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
Copy link
Contributor

@lakshmih lakshmih Mar 29, 2024

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

Copy link
Contributor Author

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.

Copy link
Contributor

@lakshmih lakshmih left a 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!

@rjodinchr rjodinchr requested a review from lakshmih March 30, 2024 08:38
@bashbaug
Copy link
Contributor

Merging as discussed in the April 16th teleconference.

@bashbaug bashbaug merged commit be8b56d into KhronosGroup:main Apr 16, 2024
7 checks passed
@rjodinchr rjodinchr deleted the pr/1dbuffer branch April 16, 2024 15:49
if (gDebugTrace)
log_info(" - Creating 1D image %d ...\n", (int)imageInfo->width);

buffer = clCreateBuffer(
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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;

Copy link
Contributor Author

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?

Copy link
Contributor

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);

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?

Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants