OpenCL-Docs

OpenCL-Docs copied to clipboard

Memory Consistency for Memory Objects Created from SVM Allocations

3

Found while considering memory objects created from SVM allocations for the unified SVM extension: What are the memory consistency expectations for memory objects created from SVM allocations? Some specific questions...

bashbaug

Does the dispatch_data field set by clIcdSetPlatformDispatchDataKHR need to be read atomically?

5

I can see a situation where thread 1 calls `clIcdSetPlatformDispatchDataKHR` to update the `dispatch_data` field of the `cl_platform_id` object, then thread 2 relies on the value to be visible in...

karolherbst

For `param_name` of `CL_KERNEL_GLOBAL_WORK_SIZE`, the table in the description of `clGetKernelWorkGroupInfo` [specifies](https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_API.html#CL_KERNEL_GLOBAL_WORK_SIZE) "return type" `size_t[3]` and contains the following description: > This provides a mechanism for the application to query...

YurkoFlisk

See discussion: https://github.com/KhronosGroup/OpenCL-Docs/pull/1375#issuecomment-2892417816 We need to add a requirement in the SPIR-V environment spec to effectively say that an OpControlBarrier with work-group scope only has defined behavior when the barrier...

bashbaug

cl_ext_alive_only_barrier

8

This extension adds a new built-in function to perform barrier synchronization across the work-group even if some of the work-items are not "alive" anymore due to having returned from the...

pjaaskel

Clarification of clCreateBuffer memory flags

2

The [table](https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_API.html#memory-flags-table) of memory flags describes `CL_MEM_READ_WRITE` like this: > This flag specifies that the memory object will be read and written by a kernel. This is the default. It...

YurkoFlisk

Image conversion rules duplicated between environment spec and OpenCL C spec

1

See https://github.com/KhronosGroup/OpenCL-Docs/pull/1352 for an example of an extension that needs to add the same (lenghty) descriptions twice.

kpet

Device Pointers for Memory Objects Created from SVM Allocations

1

Found while considering memory objects created from SVM allocations for the unified SVM extension: The `cl_ext_buffer_device_address` extension added a requirement for memory objects (specifically, buffers) created from SVM allocations: [CL_MEM_DEVICE_PRIVATE_ADDRESS_EXT](https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_API.html#CL_MEM_DEVICE_PRIVATE_ADDRESS_EXT):...

bashbaug

Found while discussing and developing the unified SVM extension: the current description for the _svm_ptr_ argument to [clEnqueueSVMMemFill](https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_API.html#clEnqueueSVMMemFill) is confusing and should be improved. For reference, the current text is:...

bashbaug

cl_ext_float_atomics: required minimum capabilities

1

Currently, the cl_ext_float_atomics explicitly states that there are no mandated minimum capabilities: https://registry.khronos.org/OpenCL/extensions/ext/cl_ext_float_atomics.html#_modifications_to_the_opencl_api_specification This means that an implementation could theoretically advertise support for the extension but then return zero for...

bashbaug