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.

[bashbaug]

I don't understand this part of the change. Shouldn't this continue to call test_functions.copy instead of copy_region directly?

Why are extra {curly braces} needed?

[shajder]

Corrected

[bashbaug]

Nitpick: I don't know what comp_pitch is supposed to mean. Could we spell "comp" out completely to add clarity?

Additionally, with this changes we either always seem to compute all four pitches, or we pass zero for all four pitches. Should we test different combinations of zero and non-zero pitches?

[shajder]

Corrected

[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.