C++14 doesn’t define built-in vector types nor memory spaces either, yet OpenCL C++ still has them. Removing the restrict keyword will also cause performance regressions in all those kernels and functions that previously could benefit from the restricted aliasing rules. Even worse, on some hardware, the restrict keyword is the only hint that can be given to the compiler to use specific forms of caching; this is so important that e.g. CUDA supports the restrict extension in C++, and relies on the no-aliasing guarantees it offer to make use of the texture cache on modern architectures where L1 isn’t used for gmem, without having to go through the hoops of texture binding and unbinding.
Geometric functions are intentionally not supported for all vector sizes. General geometric functions for N-dimensional vectors must be decomposed into powers of two, and there is no advantage to decomposing into vector widths wider than 4. OpenCL C++ provides the tools required for to write high-level libraries that can do this decomposition under the hood.
“Generic” geometric functions would only have to be introduced for 8- and 16- dimensional vectors and no, they must not be decomposed. In fact, the whole point of introducing them is to allow compilers to automatically detect opportunities to use wider-width instructions without having to second-guess the possibility to coalesce decomposed 4-wide operations. This isn’t about writing high-level libraries, it’s about exposing lower-level hardware features.
What’s worse, OpenCL C++ does not provide all the tools one would expect to write such high-level libraries, because for example it doesn’t natively provide ways to derive the basic type of a vector, or assemble vector types from scala types (unless this information is hidden in the undocumented opencl_type_traits header), nor ways to generically iterate over all vector components without prior knowledge of the vector type width. This means for example that writing a “high-level library” to extend ‘dot’ to all built-in types would require a ridiculous amount of repetitive work, only partially alleviable by judicious use of macros.
seeing final OpenCL 2.1 extensions document vs the provisional one I see two new extensions are removed:
*Named barriers for subgroups
*Subgroup Independent Forward Progress
can at least say why they have been removed?
they exposed advanced functionality exposed in CUDA also which some optimized libraries are during this adv functionality like http://legion.stanford.edu/pdfs/singe2014.pdf
also seeing AMD today announced effort to support CUDA (HIP) this functionality would be good also…
[QUOTE=oscarbg;39603]seeing final OpenCL 2.1 extensions document vs the provisional one I see two new extensions are removed:
*Named barriers for subgroups
*Subgroup Independent Forward Progress
can at least say why they have been removed?
they exposed advanced functionality exposed in CUDA also which some optimized libraries are during this adv functionality like http://legion.stanford.edu/pdfs/singe2014.pdf
also seeing AMD today announced effort to support CUDA (HIP) this functionality would be good also…[/QUOTE]
Sub-group independent forward progress has been moved into the core specification. You can check whether a device supports this feature by using the CL_DEVICE_SUB_GROUP_INDEPENDENT _FORWARD_PROGRESS query.
The named barriers extension was targeting the provisional OpenCL C++ kernel language. Since the OpenCL C++ kernel language is still under development, it didn’t make sense to include this extension in this version of the OpenCL 2.1 extension specification.
cl_egl.h, according to the registry, contains OpenCL extensions that relate to EGL. Since they relate to EGL, they also require EGL. Much like cl_d3d11.h require Direct3D 11, and cl_gl.h requires OpenGL.
If you’re writing an OpenCL loader that doesn’t deal with EGL, you wouldn’t use that header, since you’re not going to implement any of those extensions.
Following is the start of the cl_egl.h header file.
All the types defined in the function declarations are done at the start of the header. Commenting the egl.h and eglext.h includes is not generating any error or warning when including cl_egl.h and creating stubs for EGL extension functions. Thus the inclusion of these headers is superfluous. I don’t know why D3D headers are needed and I don’t have the necessary platform to test it. Nonetheless I think the policy that was used for GL was sound and should be continued for EGL. Else if we want to compile projects like ocl-icd with the official headers we will need to add a dependency on those development packages. I prefer it when things are kept as simple and independent as possible.
#ifndef __OPENCL_CL_EGL_H
#define __OPENCL_CL_EGL_H
#ifdef __APPLE__
#else
#include <CL/cl.h>
#include <EGL/egl.h>
#include <EGL/eglext.h>
#endif
#ifdef __cplusplus
extern "C" {
#endif
/* Command type for events created with clEnqueueAcquireEGLObjectsKHR */
#define CL_COMMAND_EGL_FENCE_SYNC_OBJECT_KHR 0x202F
#define CL_COMMAND_ACQUIRE_EGL_OBJECTS_KHR 0x202D
#define CL_COMMAND_RELEASE_EGL_OBJECTS_KHR 0x202E
/* Error type for clCreateFromEGLImageKHR */
#define CL_INVALID_EGL_OBJECT_KHR -1093
#define CL_EGL_RESOURCE_NOT_ACQUIRED_KHR -1092
/* CLeglImageKHR is an opaque handle to an EGLImage */
typedef void* CLeglImageKHR;
/* CLeglDisplayKHR is an opaque handle to an EGLDisplay */
typedef void* CLeglDisplayKHR;
/* CLeglSyncKHR is an opaque handle to an EGLSync object */
typedef void* CLeglSyncKHR;
/* properties passed to clCreateFromEGLImageKHR */
typedef intptr_t cl_egl_image_properties_khr;
I want to implement a function which can check OpenCL is installed or not by using java language on windows 64 bit (window 7). Please, share me that. Thank you.
I want to implement a function which can check OpenCL is installed or not by using java language on windows 64 bit (window 7). Please, share me that. Thank you.[/QUOTE]
You can check Windows Registry. Investigate the way OpenCL ICD is implemented and you’ll probably figure it out. Though, I’m not an expert in neither WinAPI nor Java, so there can be simpler solution I’m not aware of.
P.S. This topic may be inappropriate to ask questions.