Clarify alignment requirements on ptr parameter to image RW commands

[kpet]

The linked section does not document any meaningful requirements. Better to remove this confusing statement.

Change-Id: Ie9715fa79901b6b6f3d110ed8989a8be9f7133ed

[bashbaug]

I was about to merge this as a non-contentious fix, but it looks like it was explicitly added as a resolution for the old (private) Khronos bugzilla 14710, so it's probably worth a bit of additional discussion.

As best I can tell, the resolution of this issue essentially requires that the pointers passed to clEnqueueReadImage and clEnqueueWriteImage are aligned to pixel granularity, as described in Alignment of Application Data Types.

• Do we still think this is the case?
• If so, should there be an error condition if the passed-in pointer is mis-aligned?

Regardless, we may want to tidy up this language and move it out of an appendix and into the main spec, since it's not very clear right now.

[kpet]

Thanks for the archaeology, I expected this PR to be a good discussion starter :). There is a lot to unpack here.

The linked section does of course call these function out explicitly but, as you've spotted too, it is an appendix and we've always considered appendices as not normative, though I can't find a place where this is documented. Should we either document it or change our minds? There is still a fair amount that is documented in appendices or footnotes.

Many suites of the CTS do not take any particular care when allocating these pointers. The resulting pointers are still very likely to be aligned to at least "the granularity of a single channel in a pixel" given that malloc guarantees that

The malloc(), calloc(), realloc(), and reallocarray() functions return a pointer to the allocated memory, which is suitably aligned for any type that fits into the requested size or less.

so maybe the CTS is satisfying this by luck (or design though given the general quality of the code, I'm inclined to believe it's luck).

As you've observed too, there is no error code in that case which is not typical of easy-to-check error conditions in OpenCL.

My vote would be to:

• Migrate the Alignment of Application Data Types section to the (assumed to be) normative section of the specification. Appendix C has more to do with the various types definitions provided by the OpenCL headers than formal requirements on either device-side or host-side data alignment for specific scenarios.

• Decide to either

  1. Remove alignment requirements as (incompletely; it does not tidy up the appendix) done in this PR.
  2. Add an error code returned when a misaligned pointer is provided

  If we chose to do ii, we may consider making the change in a future version of OpenCL and add negative tests to not change behavioural requirements on implementations that have already shipped.

[bashbaug]

Discussed in the October 14th teleconference. Suggested actions:

1. Clearly document which appendices are normative and which are informative. Are all appendices informative?
2. Move the normative text from Appendix C out of the appendix and into the main spec.
3. Determine whether we want the alignment requirements or not.
4. If we do want the alignment requirements, what should the error code be when the alignment requirements are violated?

(1) and (2) are things we should do. (3) and (4) need more discussion.