khronosgroup / opencl-headers Goto Github PK
View Code? Open in Web Editor NEWKhronos OpenCL-Headers
License: Apache License 2.0
Khronos OpenCL-Headers
License: Apache License 2.0
Currently OpenCL headers are versioned based on the OpenCL spec (1.2, 2.0, 2.2 etc)
Apart from the core and optional core features that we change only with OpenCL version, we often add types and APIs required by KHR extensions in some of the standard headers (e.g. clext.h). Sometimes, the extension might be written on top of 1.2 or 2.0.
Current versioning doesn't allow differentiating between the OpenCL headers before and after such changes. Having finer versioning may help recommend right version of headers users need to use and potentially clarify this dependency in the extension specs.
Filing this issue to discuss pros and cons of adding the finer versioning.
Any plans to tag releases of the OpenCL headers on Github, as it is now done for OpenCL-CLHPP?
Thanks,
The defines for the minimum and maximum cl_short values are defined as:
#define CL_SHRT_MAX 32767
#define CL_SHRT_MIN (-32767-1)
#define CL_USHRT_MAX 65535
https://github.com/KhronosGroup/OpenCL-Headers/blob/master/CL/cl_platform.h#L190
In the spec, they are spelled out as "SHORT" completely. I think the headers should be updated to match the spec.
In KhronosGroup/OpenCL-Registry#55 I have a reference page fix to match the 2.2 extension spec, which adds a missing _KHR suffix to several tokens introduced by the mipmap extension. The suffix also appears to be missing from (all of) the headers in this repo. If the spec is taken as the controlling document, we should probably add aliases of the non-suffixed tokens with the suffix added, and maybe acknowledge somewhere (ref pages? extension spec?) that the non-suffixed versions were an error.
At least cl_icd.h
has got issues on Windows (it's not self-contained). We should add CI on Windows and fix existing errors. Extending the existing Travis CI config should work.
We have tests for many of the header files in this repo, but we're missing testing for cl_d3d10.h, cl_d3d11.h, and cl_dx9_media_sharing.h.
I'm not sure how else to contact Khronos regarding this but perhaps here will work. I was looking at all the headers on the Khronos website and noticed that for every cl.hpp
file prior to OpenCL 2.0 they are all pointing to https://www.khronos.org/registry/cl/api/2.1/cl.hpp
.
Is that the intention or has there been a mistake? It just seemed odd to me that if a user needed OpenCL 1.1 headers and the link is taking them to the 2.1 API.
cl_half is currently defined as a 16-bit integer, which allows code that might appear to assign floating point values to a cl_half to compile and give the wrong result.
Issue #102 will allow automatic conversion between cl_half and float in C++, but this will mean that C++ code that does not include the <CL/cl_half.h> header and code which is backported to C will be at risk of performing assignments without the expected conversion between floating point and integer formats.
This is fixable by defining cl_half as a struct or union containing a single 16-bit integer member.
The policy for extension preprocessor defines - meaning a #define
for cl_my_extension_name
in the headers - is currently a bit ad-hoc. It looks like the original intent was that an extension should have a define if it adds new API functions, but not otherwise, e.g.:
/* cl_khr_fp64 extension - no extension #define since it has no functions */
But, some extensions include a define anyways, either because they erroneously included a define initially and this has been carried forward for backwards compatibility, or because an extension define can be useful even when it doesn't add new API functions - see #85 and KhronosGroup/OpenCL-CLHPP#82.
Should we just add an extension define in all cases, uniformly?
Vulkan provides preprocessor macros (e.g. VK_KHR_SURFACE_EXTENSION_NAME
defined as "VK_KHR_surface"
). This helps with avoiding typos in extension names that can lead to silly bugs. We should do the same. These definitions could be generated automatically from the XML.
The current OpenCL headers include argument names, but only within comments:
extern CL_API_ENTRY cl_int CL_API_CALL
clGetPlatformIDs(cl_uint /* num_entries */,
cl_platform_id * /* platforms */,
cl_uint * /* num_platforms */) CL_API_SUFFIX__VERSION_1_0
This prevents the argument names from appearing in some IDE features, such as Intellisense.
Is there a reason for this, or can the argument names be un-commented?
extern CL_API_ENTRY cl_int CL_API_CALL
clGetPlatformIDs(cl_uint num_entries,
cl_platform_id * platforms,
cl_uint * num_platforms) CL_API_SUFFIX__VERSION_1_0;
One of our engineers reported an issue in the OpenCL headers recently regarding signed and unsigned mismatch compiler warnings in some cases with modern compilers at higher warning levels. The crux of the issue is that many of the OpenCL types are unsigned, e.g.:
typedef cl_uint cl_command_type;
But, the corresponding enums are signed, e.g.:
/* cl_command_type */
#define CL_COMMAND_NDRANGE_KERNEL 0x11F0
#define CL_COMMAND_TASK 0x11F1
#define CL_COMMAND_NATIVE_KERNEL 0x11F2
...
This can lead to an error in code like the following (see godbolt example here):
#define MY_VALUE 0x10
template <typename T1, typename T2>
bool is_eq(const T1& lhs, const T2& rhs) {
if (lhs == rhs) {
return true;
}
return false;
}
void f() {
unsigned x = 2;
is_eq(x, MY_VALUE);
}
This seems like a rather narrow use-case, but it's actually fairly common in googletest unit tests:
const cl_command_type command_type;
clGetEventInfo(event, CL_EVENT_COMMAND_TYPE, sizeof(command_type), &command_type, nullptr);
EXPECT_EQ(CL_COMMAND_TYPE_NDRANGE_KERNEL, command_type);
Should we define most OpenCL enums - all but error codes I think? - as explicitly unsigned? I don't think this will break existing code, and it will fix this compile warning:
/* cl_command_type */
#define CL_COMMAND_NDRANGE_KERNEL 0x11F0u
#define CL_COMMAND_TASK 0x11F1u
#define CL_COMMAND_NATIVE_KERNEL 0x11F2u
...
While making the changes in #41 I noticed that we do not currently define enums for cl_khr_image2d_from_buffer
in cl_ext.h
. Instead, the enums for this extension are in cl.h
, protected by #ifdef CL_VERSION_1_2
, and do not have the KHR
suffix. This doesn't seem correct.
One solution is to add suffixed versions of the enums to cl_ext.h
, similar to what was done in #33 for the mipmap extension. Note however, the extensions doc currently does not include a KHR
suffix on the enums, so this may not be the right thing to do in this case.
Alternatively, we could add the un-suffixed enums to cl_ext.h
if they aren't defined in cl.h
, similar to what was done for subgroups (see #2). This solution preserves source backwards compatibility.
I guess this is the same issue as was the case with GCC inside typedef struct _cl_image_desc
for eg. which was circumvented with the code:
#ifdef __GNUC__
__extension__ /* Prevents warnings about anonymous union in -pedantic builds */
#endif
union {
cl_mem buffer;
cl_mem mem_object;
};
MSVC has exactly the same problem when compiled with /Za, strict ANSI conformance.
The 3.0 specification added a new API entry point, this should be added to the headers.
The CL_DBL_MAX
definition results in a 311 character long literal double. When used, the preprocessor expands CL_DBL_MAX
and the resulting identifier is too long for Visual Studio 2013 resulting in the following compiler error.
fatal error C1064: compiler limit : token overflowed internal buffer
Looking into this error further the only solution provided on MSDN is this.
compiler limit : token overflowed internal buffer
An identifier exceeds the length of the internal buffer used for identifiers. Shorten the name.
This is not a problem in Visual Studio 2015 but the headers should still compile with older versions of Microsoft's compiler.
My recommendation is to revert to the current definition, in both places, to previous definition of CL_DBL_MAX
, and ensure to apply the fix to all branches in this repository.
#define CL_DBL_MAX 1.7976931348623158e+308
This applies to all of the branches is this repository, I've created a new issue since this is a compiler error but it seems it may be related to #17.
There are a number of so-called "headers" tests in the CTS (https://github.com/KhronosGroup/OpenCL-CTS/tree/master/test_conformance/headers) that don't really test the OpenCL implementation itself but rather whether the headers build cleanly using the target toolchain and whether some aspects of them behave correctly.
I think these tests should be moved to the headers repo as they're effectively testing the headers in isolation. However, I still see value in requiring that these tests pass on a platform for which OpenCL compliance is sought. Maybe this can be a requirement of the conformance process?
Any opinions?
I'm a little confused by the prefix and suffix pre-processor defines for deprecated OpenCL APIs. I believe this is a summary of what is in the headers currently:
API | Introduced In | Deprecated In | Prefix Define | Suffix Define |
---|---|---|---|---|
clSetCommandQueueProperty | OpenCL 1.0 | OpenCL 1.1 | (None!) | CL_EXT_SUFFIX__ VERSION_1_0_DEPRECATED |
clCreateImage2D | OpenCL 1.0 | OpenCL 1.2 | CL_EXT_PREFIX__ VERSION_1_1_DEPRECATED | CL_EXT_SUFFIX__ VERSION_1_1_DEPRECATED |
clCreateImage3D | OpenCL 1.0 | OpenCL 1.2 | CL_EXT_PREFIX__ VERSION_1_1_DEPRECATED | CL_EXT_SUFFIX__ VERSION_1_1_DEPRECATED |
clEnqueueMarker | OpenCL 1.0 | OpenCL 1.2 | CL_EXT_PREFIX__ VERSION_1_1_DEPRECATED | CL_EXT_SUFFIX__ VERSION_1_1_DEPRECATED |
clEnqueueWaitForEvents | OpenCL 1.0 | OpenCL 1.2 | CL_EXT_PREFIX__ VERSION_1_1_DEPRECATED | CL_EXT_SUFFIX__ VERSION_1_1_DEPRECATED |
clEnqueueBarrier | OpenCL 1.0 | OpenCL 1.2 | CL_EXT_PREFIX__ VERSION_1_1_DEPRECATED | CL_EXT_SUFFIX__ VERSION_1_1_DEPRECATED |
clUnloadCompiler | OpenCL 1.0 | OpenCL 1.2 | CL_EXT_PREFIX__ VERSION_1_1_DEPRECATED | CL_EXT_SUFFIX__ VERSION_1_1_DEPRECATED |
clGetExtensionFunctionAddress | OpenCL 1.0 | OpenCL 1.2 | CL_EXT_PREFIX__ VERSION_1_1_DEPRECATED | CL_EXT_SUFFIX__ VERSION_1_1_DEPRECATED |
clCreateCommandQueue | OpenCL 1.0 | OpenCL 2.0 | CL_EXT_PREFIX__ VERSION_1_2_DEPRECATED | CL_EXT_SUFFIX__ VERSION_1_2_DEPRECATED |
clCreateSampler | OpenCL 1.0 | OpenCL 2.0 | CL_EXT_PREFIX__ VERSION_1_2_DEPRECATED | CL_EXT_SUFFIX__ VERSION_1_2_DEPRECATED |
clEnqueueTask | OpenCL 1.0 | OpenCL 2.0 | CL_EXT_PREFIX__ VERSION_1_2_DEPRECATED | CL_EXT_SUFFIX__ VERSION_1_2_DEPRECATED |
clCreateFromGLTexture2D | cl_khr_gl_sharing | OpenCL 1.2? | CL_EXT_PREFIX__ VERSION_1_1_DEPRECATED | CL_EXT_SUFFIX__ VERSION_1_1_DEPRECATED |
clCreateFromGLTexture3D | cl_khr_gl_sharing | OpenCL 1.2? | CL_EXT_PREFIX__ VERSION_1_1_DEPRECATED | CL_EXT_SUFFIX__ VERSION_1_1_DEPRECATED |
clGetKernelSubGroupInfoKHR | cl_khr_subgroups | OpenCL 2.1? | (None!) | CL_EXT_SUFFIX__ VERSION_2_0_DEPRECATED |
Should the define indicate:
Right now it looks like we have a bit of a mix, though it looks like we have more usage of "last supported" than anything else.
I'm looking at this to ensure that if we deprecate clSetProgramReleaseCallback
we do it consistently. Thanks!
I tried to compile some code with latest headers (from HEAD) using x86_64-w64-mingw32-g++ 7.4.0 crosscompiler shipped with Cygwin. I got following errors:
In file included from /usr/x86_64-w64-mingw32/sys-root/mingw/include/intrin.h:41:0,
from ./CL/cl_platform.h:380,
from ./CL/cl.h:35,
from ./CL/opencl.h:47,
from CL/cl.hpp:170,
from RakeSearchOpenCL.h:6,
from main.cpp:19:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/psdk_inc/intrin-impl.h:1848:42: error: macro "__cpuid" requires 5 arguments, but only 2 given
void __cpuid(int CPUInfo[4], int InfoType);
^
/usr/x86_64-w64-mingw32/sys-root/mingw/include/psdk_inc/intrin-impl.h:1851:42: error: macro "__cpuid" requires 5 arguments, but only 2 given
void __cpuid(int CPUInfo[4], int InfoType) {
^
In file included from ./CL/cl_platform.h:380:0,
from ./CL/cl.h:35,
from ./CL/opencl.h:47,
from CL/cl.hpp:170,
from RakeSearchOpenCL.h:6,
from main.cpp:19:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/intrin.h:1117:44: error: macro "__cpuid" requires 5 arguments, but only 2 given
__MACHINEI(void __cpuid(int a[4],int b))
^
In file included from /usr/x86_64-w64-mingw32/sys-root/mingw/include/intrin.h:41:0,
from ./CL/cl_platform.h:380,
from ./CL/cl.h:35,
from ./CL/opencl.h:47,
from CL/cl.hpp:170,
from RakeSearchOpenCL.h:6,
from main.cpp:19:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/psdk_inc/intrin-impl.h:1848:6: error: variable or field ‘__cpuid’ declared void
void __cpuid(int CPUInfo[4], int InfoType);
^~~~~~~
/usr/x86_64-w64-mingw32/sys-root/mingw/include/psdk_inc/intrin-impl.h:1851:6: error: variable or field ‘__cpuid’ declared void
void __cpuid(int CPUInfo[4], int InfoType) {
^~~~~~~
/usr/x86_64-w64-mingw32/sys-root/mingw/include/psdk_inc/intrin-impl.h:1852:4: error: expected primary-expression before ‘__asm__’
__asm__ __volatile__ (
^~~~~~~
/usr/x86_64-w64-mingw32/sys-root/mingw/include/psdk_inc/intrin-impl.h:1852:4: error: expected ‘}’ before ‘__asm__’
In file included from ./CL/cl_platform.h:380:0,
from ./CL/cl.h:35,
from ./CL/opencl.h:47,
from CL/cl.hpp:170,
from RakeSearchOpenCL.h:6,
from main.cpp:19:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/intrin.h:1117:5: error: variable or field ‘__cpuid’ declared void
__MACHINEI(void __cpuid(int a[4],int b))
^
In file included from CL/cl.hpp:170:0,
from RakeSearchOpenCL.h:6,
from main.cpp:19:
./CL/opencl.h:55:1: error: expected declaration before ‘}’ token
}
Problem is caused by following part of code in cl_platform.h
#if defined( __MINGW64__ )
#include <intrin.h>
#else
#include <xmmintrin.h>
#endif
There are 3 similar code clocks there. When I commented out parts for __MINGW64__
, code compiled without errors.
I use SSE/AVX intrinsics for more than 2 years, and during that time I always included headers as suggested in Intel Intrinsics Guide. Looks that MinGW shipped with Cygwin has correct headers and does not need any workarounds. If you need them for some other reason, some extra checks will be needed here.
At the head of the file it comments
cl_gl_ext.h contains vendor (non-KHR) OpenCL extensions which have OpenGL dependencies.
This is followed by the KHR, non-vendor extension cl_khr_gl_event. So, documentation inconsistent with contents. Perhaps the comment should be altered to "contains OpenCL extensions which have OpenGL dependencies"? Or the extension interface moved to cl_gl.h?
I think we should be able to do cl_float4.x
with -std=c11
, as we currently are with -std=gnu99
Just need to patch line
Line 532 in bf0f43b
#if defined( __GNUC__) && ! defined( __STRICT_ANSI__ )
to also check for C11.
See also: http://stackoverflow.com/questions/10979487/opencl-cl-datatypes-arithmetic
Supposing of course CL headers will support c11.
In the OpenCL 2.1 headers, the type definition of cl_kernel_sub_group_info is performed twice:
This causes a warning when compiling with clang (3.6/3.8):
./ocl/2.1/CL/cl_ext.h:323:18: warning: redefinition of typedef 'cl_kernel_sub_group_info' is a C11 feature
[-Wtypedef-redefinition]
typedef cl_uint cl_kernel_sub_group_info;
^
./ocl/2.1/CL/cl.h:97:29: note: previous definition is here
typedef cl_uint cl_kernel_sub_group_info;
Hi,
The documentation lists the CL_VERSION_X_Y preprocessor defines as corresponding to the integer XY0, but all the examples I can find in cl.h for various versions in this repo define it as 1, e.g. in the 2.2 headers
Am I missing something?
We still need to add support in the headers for CL_HAS_NAMED_RGBA_VECTOR_FIELDS
which we added in OpenCL 3.0.
This is caused by PR #116
Minimal reproducer:
// test.cpp
#include <CL/cl.h>
int main() {
cl_image_desc image_desc;
(void)image_desc.mem_object;
return 0;
}
Then compile with
g++ -I$(pwd) -std=c++14 test.cpp
Error:
note: #pragma message: cl_version.h: CL_TARGET_OPENCL_VERSION is not defined. Defaulting to 220 (OpenCL 2.2)
test.cpp: In function ‘int main()’:
test.cpp:6:20: error: ‘cl_image_desc’ {aka ‘struct _cl_image_desc’} has no member named ‘mem_object’
(void)image_desc.mem_object;
^~~~~~~~~~
cl.h currently includes error codes for:
CL_INVALID_GL_OBJECT
CL_INVALID_MIP_LEVEL
These error codes are defined by extensions though, and are not in the core API specification.
Questions are:
I'm mostly raising this issue for awareness and to avoid duplicated work.
I started experimenting with generated extension headers using the cl.xml file over the weekend and I'm pretty close to having something workable. In addition to the nice consistency benefits, this also provides a mechanism to validate that the XML file is correct for extensions, and enables easy additions for things like a symbolic name for extensions (#111) and preprocessor defines for extensions (#86).
Note that I've only done extension headers for now, and not the core API headers. The extension headers were easier (fewer conditional rules) and are faster moving, so I think they provide a bigger bang-for-the-buck, and I don't plan to generate the core API headers at this time.
The few issues I still need to resolve are:
CL_DEVICE_DOUBLE_FP_CONFIG
(only for pre-OpenCL 1.2) and cl_kernel_sub_group_info
(only for pre-OpenCL 2.1). (See KhronosGroup/OpenCL-Docs#463, KhronosGroup/OpenCL-Docs#469)cl_khr_extended_versioning
are not in the XML file, so they need to be added and I need to figure out how to properly generate code for them. (I know how to do this - PR soon.)cl_gl_ext.h
(see #145, fixed by #156).We're not currently providing releases of the headers. This makes a number of things like integrating them into Linux distributions a bit challenging. It seems we got a request in the past that was closed without replying or providing a solution (#11). (cc @ghisvail, @vdanjean).
I suggest we use a date-based tagging scheme (e.g. YYYY-MM) to avoid the confusion with OpenCL versions.
opencl22/CL/cl.h:538
s/cl_kernel_arg_type_qualifer/cl_kernel_arg_type_qualifier/
in the cl.h
file:
Lines 695 to 707 in b758718
CL_KERNEL_MAX_NUM_SUB_GROUPS
CL_KERNEL_COMPILE_NUM_SUB_GROUPS
are attributed to cl_kernel_info
whereas they are cl_kernel_sub_group_info
(see clGetKernelSubGroupInfo).
The current and only tag v2020.03.13 gives a compiler error in the ICD-loader repository with the same release version. A bugfix was pushed two weeks later, but that forces me 'subscribe' to both master branches again, but that gives instabilities in my project that uses them.
Could you please add a new release/tag to improve stability in downstream projects? Thanks
Lines 230 to 237 in 94bbd1f
According to https://www.khronos.org/registry/OpenCL/extensions/amd/cl_amd_device_attribute_query.txt
Lots of defines have been added as part of cl_amd_device_attribute_query
, but I did't find them in the cl_ext.h.
token | value |
---|---|
CL_DEVICE_PROFILING_TIMER_OFFSET_AMD | 0x4036 |
CL_DEVICE_TOPOLOGY_AMD | 0x4037 |
CL_DEVICE_BOARD_NAME_AMD | 0x4038 |
CL_DEVICE_GLOBAL_FREE_MEMORY_AMD | 0x4039 |
CL_DEVICE_SIMD_PER_COMPUTE_UNIT_AMD | 0x4040 |
CL_DEVICE_SIMD_WIDTH_AMD | 0x4041 |
CL_DEVICE_SIMD_INSTRUCTION_WIDTH_AMD | 0x4042 |
CL_DEVICE_WAVEFRONT_WIDTH_AMD | 0x4043 |
CL_DEVICE_GLOBAL_MEM_CHANNELS_AMD | 0x4044 |
CL_DEVICE_GLOBAL_MEM_CHANNEL_BANKS_AMD | 0x4045 |
CL_DEVICE_GLOBAL_MEM_CHANNEL_BANK_WIDTH_AMD | 0x4046 |
CL_DEVICE_LOCAL_MEM_SIZE_PER_COMPUTE_UNIT_AMD | 0x4047 |
CL_DEVICE_LOCAL_MEM_BANKS_AMD | 0x4048 |
CL_DEVICE_THREAD_TRACE_SUPPORTED_AMD | 0x4049 |
CL_DEVICE_GFXIP_MAJOR_AMD | 0x404A |
CL_DEVICE_GFXIP_MINOR_AMD | 0x404B |
CL_DEVICE_AVAILABLE_ASYNC_QUEUES_AMD | 0x404C |
CL_DEVICE_PREFERRED_WORK_GROUP_SIZE_AMD | 0x4030 |
CL_DEVICE_MAX_WORK_GROUP_SIZE_AMD | 0x4031 |
CL_DEVICE_PREFERRED_CONSTANT_BUFFER_SIZE_AMD | 0x4033 |
CL_DEVICE_PCIE_ID_AMD | 0x4034 |
only the first one is avaliable right now.
We haven't documented which compilers and compiler options including C and C++ standard versions the headers support, which makes it difficult to determine if issues like #115 and #121 are header issues or unsupported configurations. We should document (and test for!) the compilers and compiler options we're intending to support and be clear that other configurations may not work or have limitations.
FWIW, there is a similar issue already for the C++ bindings:
KhronosGroup/OpenCL-CLHPP#78
The headers are using a number of identifiers that are reserved in C/C++ (e.g. those beginning with __
, see https://en.cppreference.com/w/c/language/identifier). We should rename all of these.
Currently to pass builds cleanly, warning-free we have to disable format-related warnings. We should consider fixing those.
CL_API_SUFFIX__VERSION_2_X
macros aren't defined by cl_platform.h
when __APPLE__
is present. This seems like an arbitrary limitation.
When compiling an empty main
including cl.h
the compiler bails out on anonymous structs when compiling in strict ANSI conformance using the /Za flag. This compiler option also defines __STDC__
which can be used to detect such use cases and be added to L487 of cl_platform.h
to read:
#elif defined( _WIN32) && defined(_MSC_VER) && ! defined(__STDC__)
This issue is here for me to remember ro open a PR and what the issue is (since I got to the bottom of it).
We currently provide no host-side support for converting between cl_half
and other integer or floating-point types.
The following code snippet
cl_float myfloat = ...
cl_half myhalf = (cl_half)myfloat;
results in a floating-point to integer conversion. This is really not nice.
While we can't make the above work in applications written in C, I suggest we provide conversion routines like https://github.com/KhronosGroup/OpenCL-CTS/blob/master/test_common/harness/imageHelpers.cpp#L898 as part of the headers. For applications written in C++, we could make casts work automatically.
Hi, For documentation purpose and project release process we need the Export control classification number(ECCN) for Opencl if it applies. Can you please let me know the ECCN ?
Hello,
Please I am trying to use this headers for a project I am working on, and building my system based on the Alpine docker image. I have noticed that the opencl headers are kind of old built (like2016). IS there any way please I can build the latest one myself locally? ALl I need is the command line.
Kind regards
Hi,
where can I find a header for cl_nv_d3d11_sharing and why isn't it included here?
The CL_CONTEXT_TERMINATED_KHR error code is not defined in any header file.
<cl_platform.h> defines some standard mathematical constants, in both single- and double-precision formats:
$ ( sed -n '/stdint/,$p' | grep 'CL_M_' ) <cl_platform.h
#define CL_M_E 2.718281828459045090796
#define CL_M_LOG2E 1.442695040888963387005
#define CL_M_LOG10E 0.434294481903251816668
#define CL_M_LN2 0.693147180559945286227
#define CL_M_LN10 2.302585092994045901094
#define CL_M_PI 3.141592653589793115998
#define CL_M_PI_2 1.570796326794896557999
#define CL_M_PI_4 0.785398163397448278999
#define CL_M_1_PI 0.318309886183790691216
#define CL_M_2_PI 0.636619772367581382433
#define CL_M_2_SQRTPI 1.128379167095512558561
#define CL_M_SQRT2 1.414213562373095145475
#define CL_M_SQRT1_2 0.707106781186547572737
#define CL_M_E_F 2.71828174591064f
#define CL_M_LOG2E_F 1.44269502162933f
#define CL_M_LOG10E_F 0.43429449200630f
#define CL_M_LN2_F 0.69314718246460f
#define CL_M_LN10_F 2.30258512496948f
#define CL_M_PI_F 3.14159274101257f
#define CL_M_PI_2_F 1.57079637050629f
#define CL_M_PI_4_F 0.78539818525314f
#define CL_M_1_PI_F 0.31830987334251f
#define CL_M_2_PI_F 0.63661974668503f
#define CL_M_2_SQRTPI_F 1.12837922573090f
#define CL_M_SQRT2_F 1.41421353816986f
#define CL_M_SQRT1_2_F 0.70710676908493f
Bizarrely, the single- and double-precision versions DO NOT MATCH BEYOND THE SEVENTH DIGIT:
$ ( sed -n '/stdint/,$p' | grep 'CL_M_' ) <cl_platform.h |
( sort | sed -r -e 's/ 0\./0./' -e 's/(.{36})(.*)/\1 \2/' )
#define CL_M_1_PI 0.3183098 86183790691216
#define CL_M_1_PI_F 0.3183098 7334251f
#define CL_M_2_PI 0.6366197 72367581382433
#define CL_M_2_PI_F 0.6366197 4668503f
#define CL_M_2_SQRTPI 1.128379 167095512558561
#define CL_M_2_SQRTPI_F 1.128379 22573090f
#define CL_M_E 2.718281 828459045090796
#define CL_M_E_F 2.718281 74591064f
#define CL_M_LN10 2.302585 092994045901094
#define CL_M_LN10_F 2.302585 12496948f
#define CL_M_LN2 0.6931471 80559945286227
#define CL_M_LN2_F 0.6931471 8246460f
#define CL_M_LOG10E 0.4342944 81903251816668
#define CL_M_LOG10E_F 0.4342944 9200630f
#define CL_M_LOG2E 1.442695 040888963387005
#define CL_M_LOG2E_F 1.442695 02162933f
#define CL_M_PI_2 1.570796 326794896557999
#define CL_M_PI_2_F 1.570796 37050629f
#define CL_M_PI 3.141592 653589793115998
#define CL_M_PI_F 3.141592 74101257f /* re-ordered */
#define CL_M_PI_4 0.7853981 63397448278999
#define CL_M_PI_4_F 0.7853981 8525314f
#define CL_M_SQRT1_2 0.7071067 81186547572737
#define CL_M_SQRT1_2_F 0.7071067 6908493f
#define CL_M_SQRT2 1.414213 562373095145475
#define CL_M_SQRT2_F 1.414213 53816986f
THEY CAN'T BOTH BE CORRECT!
The situation may not be as bad as it looks -- the double-precision values may be entirely correct, and since eight decimal digits would be sufficient to represent the 24-bit mantissa of the single-precision values, their inaccuracy may be very small. But it looks quite odd, and is likely to cause problems if these definitions are ever copied and reused somewhere else.
Surely this should be investigated?
Apparently I have just opened my first PR on this repository, so I need to file the CLA. No problem, but it says
All contributions to this repository are made under the MIT License. You may obtain a copy of the License at https://opensource.org/licenses/MIT. Each contributor represents and warrants, on behalf of their employer or other principal if they are acting within the scope of their employment or otherwise as the agent of a legal entity, that they have the right and authority to make their contribution under these terms.
And then quotes the full MIT license.
This is out of date, the license was recently changed to Apache 2.0: #76
I've just noticed that this repository is using an MIT license, whereas most of our others use Apache 2.0. The new test files that I added recently (copied from CTS) use Apache 2.0, which doesn't match the MIT license specified in the root LICENSE
file in this repository.
IANAL, so I don't know if this matters and/or what we should do about it, so opening this issue just to check with others. Can we change either the licenses for the new tests or the licenses for the headers themselves? Should we just add the Apache 2.0 license text to the root LICENSE
file? Or do nothing since the test sources were originally released under Apache 2.0 before being copied here?
See:
KhronosGroup/OpenCL-Docs#284
KhronosGroup/OpenCL-Docs#458
It looks like the enums for depth images in the headers have a similar problem:
#ifdef CL_VERSION_1_2
#define CL_DEPTH 0x10BD
#define CL_DEPTH_STENCIL 0x10BE
#endif
We should:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.