Added sub-case for basic test where the provided pitches are zero

[shajder]

Related to #2279

[bashbaug]

This adds additional coverage for clEnqueueCopyBufferRect.

Should we add additional coverage for clEnqueueReadBufferRect and clEnqueueWriteBufferRect also? If this is something we want, it's fine to add it in a separate PR.

[shajder]

This adds additional coverage for clEnqueueCopyBufferRect.

Should we add additional coverage for clEnqueueReadBufferRect and clEnqueueWriteBufferRect also? If this is something we want, it's fine to add it in a separate PR.

Should I create separate issue or just comment to #2279

[shajder]

This adds additional coverage for clEnqueueCopyBufferRect.
Should we add additional coverage for clEnqueueReadBufferRect and clEnqueueWriteBufferRect also? If this is something we want, it's fine to add it in a separate PR.

Should I create separate issue or just comment to #2279

I've created new PR #2515 without new issue

[lakshmih]

We're running into some failures with this and would like some more time to check the verification code.

[joselopeqti]

The calculation for spitch, sslice, dpitch and dslice in lines 209 to 213 has to be changed as well. The specs says:

If src_row_pitch is 0, src_row_pitch is computed as region[0].
If src_slice_pitch is 0, src_slice_pitch is computed as region[1] × src_row_pitch.
If dst_row_pitch is 0, dst_row_pitch is computed as region[0].
If dst_slice_pitch is 0, dst_slice_pitch is computed as region[1] × dst_row_pitch.

So when the row or slice pitches are 0, the region values should be used.

Suggested change

	size_t spitch = (src_row_pitch == 0) ? sregion[0] : src_row_pitch;
	size_t sslice = (src_slice_pitch == 0) ? sregion[1] * spitch : src_slice_pitch;
	size_t dpitch = (dst_row_pitch == 0) ? dregion[0] : dst_row_pitch;
	size_t dslice = (dst_slice_pitch == 0) ? dregion[1] * dpitch : dst_slice_pitch;

[shajder]

FYI: @bashbaug @kpet

So when the row or slice pitches are 0, the region values should be used.

To me this sounds like a specification issue. If anything other than the actual source/destination buffer width/height is used for the row/slice pitches, we will no longer be copying a rectangular (or cubic) region. Instead, the copy will become skewed because each row will start at an incorrect offset. Am I missing something ?

[shajder]

@joselopeqti I've applied your correction with a minor caveat:

size_t dpitch = (dst_row_pitch == 0) ? sregion[0] : dst_row_pitch;
size_t dslice =
(dst_slice_pitch == 0) ? sregion[1] * dpitch : dst_slice_pitch;

[bashbaug]

Discussed in the March 17th teleconference. Removing "focused review" until the spec issue is resolved.

Marcin will file a spec issue to track resolution.

[shajder]

Marcin will file a spec issue to track resolution.

@bashbaug after double-checking the spec and the test, I've applied @joselopeqti's corrections. I believe the fallback of pitches to region[N]-related values when equal to zero may indeed be confusing for developers following the logic of our CTS test. On the other hand, a parameters of clCreateBuffer has no width, height, or depth - these are only conventional values in our test. In that sense, the fallback could legitimately be many things, and for clEnqueueCopyBufferRect the most reasonable choice is region[N]. I think we should leave it as is, without the issue.

[bashbaug]

I think we should leave it as is, without the issue.

OK, sounds good, should we add back "focused review" then? In other words, is this ready to go?

[shajder]

OK, sounds good, should we add back "focused review" then? In other words, is this ready to go?

yes, it is ready, let me add the label