
openCL
文章平均质量分 83
꧁白杨树下꧂
这个作者很懒,什么都没留下…
展开
-
OpenCL™规范 致谢
如果已经创建了默认设备队列,则调用clCreateCommandQueueWithProperties,并将CL_QUEUE_PROPERTIES设置为CL_QUEUE_ON_DEVICE和CL_QUEUE_ON_DEVICE_DEFAULT,将返回已经创建的默认设备队列并将其引用计数递增1。如果返回的平台配置文件是FULL_PROFILE,则OpenCL框架将支持FULL_PROFILE的设备,也可能支持EMBEDDED_PROFILE的设备。CL_COMPLETE和CL_SUCCESS的值相同。翻译 2025-02-18 10:03:37 · 20 阅读 · 0 评论 -
OpenCL™规范 附录I:OpenCL扩展(资料性附录)
Extensions to the OpenCL API can be defined by authors, groups of authors, and the Khronos OpenCL Working Group. The online Registry of extensions is available at URL对OpenCL API的扩展可以由作者、作者组和Khronos OpenCL工作组定义。在线扩展注册可在URL上找到Khronos OpenCL Registry - The Kh翻译 2025-02-18 09:39:37 · 71 阅读 · 0 评论 -
OpenCL™规范 附录H:OpenCL 3.0向后兼容性
_opencl_c_atomic_scope_all_devices——表示原子操作和围栏支持所有设备内存排序约束,跨任何主机线程和所有可以相互共享SVM内存和主机进程的设备。非正式地说,在下表中,第一行通常描述了一种特征检测机制(“可能返回此值,表示不支持该特征”),后续行通常描述不支持某个特征时的行为(“如果不支持该功能,则返回此值”)。支持镜像的OpenCL C编译器将定义特征宏。不支持从缓冲区创建2D图像,则不会描述对cl_khr_image2d_from_buffer扩展的支持。翻译 2025-02-06 14:16:55 · 42 阅读 · 0 评论 -
OpenCL™规范 附录G:其他杂项
CL_FALSE的别名,可用于提高对可能阻塞的入队函数的调用的可读性。CL_TRUE的别名,可用于提高对可能阻塞的排队函数的调用的可读性。本节列出了其他各种OpenCL枚举及其含义。表示其他枚举或条件均不适用。表示布尔值“false”。表示布尔值“true”。翻译 2025-02-04 14:31:58 · 29 阅读 · 0 评论 -
OpenCL™规范 附录F:错误代码
当CL_DEVICE_COMPILER_AVAILABLE为CL_FALSE时,从源代码或IL编译或构建程序时返回。当创建或使用的子缓冲区对象未与设备的CL_DEVICE_MEM_BASE_ADDR_ALIGN对齐时返回。当使用CL_DEVICE_PARTITION_BY_COUNTS请求的设备分区无效时返回。当CL_DEVICE_AVAILABLE为CL_FALSE时,尝试使用设备时返回。尝试获取从已获取的Direct3D 10资源创建的OpenCL对象时返回。翻译 2025-02-04 14:28:22 · 28 阅读 · 0 评论 -
OpenCL™规范 附录E:OpenCL的更改
:OpenCL 1.1平台层和运行时中添加了以下功能(第4节和第5节):table 4.3对表4.3的以下查询CL_CONTEXT_NUM_DEVICES返回到指定给clGetContextInfo的查询列表。CL_RxCL_RGx, andCL_RGBx可选图像格式:CL_Rx、CL_RGx和CL_RGBx。支持子缓冲区对象使用clCreateSubBuffer创建引用另一个缓冲区对象中特定区域的缓冲区对象的能力。and。翻译 2025-02-01 20:45:42 · 46 阅读 · 0 评论 -
OpenCL™规范 附录D:检查内存副本重叠
以下代码描述了如何确定指定给clEnqueueCopyBufferRect的源矩形和目标矩形之间是否存在重叠,前提是源缓冲区和目标缓冲区引用相同的缓冲区对象。翻译 2025-01-22 10:09:12 · 38 阅读 · 0 评论 -
OpenCL™规范 附录C:应用程序数据类型
除了上述应用程序类型定义外,还可以使用以下文本定义。字符的位宽cl_charcl_char类型的最大值cl_charcl_char类型的最小值cl_charcl_char类型的最大值cl_charcl_char类型的最小值cl_ucharcl_uchar类型的最大值cl_shortcl_short类型的最大值cl_shortcl_short类型的最小值cl_ushortcl_ushort类型的最大值CL_INT_MAXcl_intcl_int类型的最大值CL_INT_MINcl_int。翻译 2025-01-21 10:22:16 · 35 阅读 · 0 评论 -
OpenCL™规范 附录B:便携性
然而,尽管OpenCL提供了一组通用的运算符,这些运算符通常来自向量机上的运算符集,但它无法以一致的统一可移植方式提供对每个ISA可能提供的所有内容的访问。因此,OpenCL的设计允许传统的向量C语言编程扩展,如AltiVecC编程接口或IntelC编程接口(如emmintrin.h中的那些)直接在OpenCL中使用,OpenCL数据类型作为OpenCL的扩展。同样,计算架构的异构性可能意味着,例如,特定的循环构造可能在CPU上以可接受的速度执行,但在GPU上执行得很差。更令人担忧的是字节序的话题。翻译 2025-01-20 15:02:08 · 39 阅读 · 0 评论 -
OpenCL™规范 附录A:主机环境和线程安全
clSetKernelArg、clSetKernelArgSVMPointer、clSetKernelExecInfo和clCloneKernel可以安全地从任何主机线程调用,并且可以安全地重新集中调用,只要对这些API调用的任何组合的并发调用操作在不同的cl_kernel对象上。当命令排队到命令队列时,可以创建事件对象。应用程序必须实现适当的同步,以确保当多个主机线程或命令队列更改共享对象的状态时,共享对象(如命令队列对象、内存对象、程序对象或内核对象)的状态更改以正确的顺序(应用程序认为正确)发生。翻译 2025-01-18 17:18:07 · 35 阅读 · 0 评论 -
OpenCL™规范 7.OpenCL嵌入式配置文件
The OpenCL specification describes the feature requirements for desktop platforms. This section describes the OpenCL embedded profile that allows us to target a subset of the OpenCL specification for handheld and embedded platforms. The optional extensions翻译 2025-01-17 13:41:56 · 38 阅读 · 0 评论 -
OpenCL™规范 6.相关的OpenCL规范
OpenCL C内核语言是在OpenCL 1.0、OpenCL 1.1、OpenCL 1.2、OpenCL C 2.0内核语言和OpenCL C 3.0内核语言规范中定义的。当OpenCL设备支持一个或多个版本的OpenCL C内核语言时(请参阅CL_DEVICE_OPENCL_C_VERSION和CL_DEVICE_OPENCL_C_ALL_VERSIONS),可以通过将OpenCL C源字符串传递给clCreateProgramWithSource来创建OpenCL程序对象。翻译 2025-01-16 09:37:38 · 30 阅读 · 0 评论 -
OpenCL™规范 5.18. 查询支持与OpenGL共享的设备
如果通过设置属性CL_CGL_SHAREGROUP_KHR为基于CGL的OpenGL实现指定了共享组,并且指定的共享组没有标识有效的CGL共享组对象,则返回CL_INVALID_GL_SHAREGROUP_REFERENCE_KHR。属性CL_CGL_SHAREGROUP_KHR、CL_EGL_DISPLAY_KHR、CL_GLX_DISPLAY_KHR和CL_WGL_HDC_KHR中的多个设置为非默认值。CL_OUT_OF_HOST_MEMORY,如果无法在主机上分配OpenCL实现所需的资源。翻译 2025-01-15 10:00:19 · 34 阅读 · 0 评论 -
OpenCL™规范 5.17.8. 命令缓冲区查询
不是从clCommandNDRangeKernelKHR命令中记录的,则实现必须返回等于0的param_value_size_ret,表示param_value中返回的值无效。不是从clCommandNDRangeKernelKHR命令中记录的,则实现必须返回等于0的param_value_size_ret,表示param_value中返回的值无效。参数为NULL,则实现可能会返回0的param_value_size_ret(即没有要返回的属性),也可能返回0的属性值(其中0用于终止属性列表)。翻译 2025-01-14 21:10:29 · 30 阅读 · 0 评论 -
OpenCL™规范 5.17.7.2. 内核命令更新结构
有关cl_mutable_dispatch_arg_khr成员的用法,请参阅clSetKernelArgSVMPointer,arg_size将被忽略。local_work_size指向一个work_dim无符号值数组,该数组描述了组成将执行内核的工作组的工作项的数量。有关cl_mutable_dispatch_arg_khr成员的用法,请参阅clSetKernelArg。有关cl_mutable_dispatch_exec_info_khr成员的用法,请参阅clSetKernelExecInfo。翻译 2025-01-13 09:46:11 · 33 阅读 · 0 评论 -
OpenCL™规范 5.17.7.1. 可变命令更新结构
下表定义了cl_command_buffer_update_type_khr值到它们定义的结构的映射,当传递给clUpdateMutableCommandsKHR时,重新解释空指针。翻译 2025-01-09 10:11:58 · 25 阅读 · 0 评论 -
OpenCL™规范 5.17.7. 可变命令
如果命令缓冲区是使用CL_MUTABLE_DISPATCH_ASSERT_NO_ADDITIONAL_WORK_GROUPS_KHR创建的,或者更新的ND范围命令是使用此标志记录的,并且ND范围参数被更新,使得新的工作组数量超过记录ND范围命令时的数量,则行为未定义。如果arg_svm_list为NULL且num_svm_args>0,或者arg_svm_list不为NULL且num _svm_args为0,则CL_INVALID_VALUE。翻译 2025-01-08 11:36:07 · 32 阅读 · 0 评论 -
OpenCL™规范 5.17.6. 重新映射命令缓冲区
如果支持cl_khr_command_buffer_multi_device扩展,则报告CL_COMMAND_BUFFER_PLATFORM_REMAP_QUEUES_KHR功能的平台支持生成命令缓冲区的深度副本,其命令重新映射到可能与创建命令缓冲区所用的队列不兼容的命令队列列表中。除了此功能外,报告CL_COMMAND_BUFFER_PLATFORM_AUTOMATIC_REMAP_KHR的平台允许用户创建一个重新映射的命令缓冲区,其中队列到命令的映射由OpenCL运行时以其确定为最佳的方式确定。翻译 2025-01-03 10:00:02 · 39 阅读 · 0 评论 -
OpenCL™规范 5.17.5. 将命令记录到命令缓冲区
如果sync_point_wait_list不为NULL,则sync_point_wait_list指向的同步点列表必须有效,num_sync_points_in_wait_list必须大于0。与sync_point_wait_list中的同步点关联的命令缓冲区必须与command_buffer相同。如果sync_point_wait_list不为NULL,则sync_point_wait_list指向的同步点列表必须有效,num_sync_points_in_wait_list必须大于0。翻译 2025-01-02 10:16:53 · 47 阅读 · 0 评论 -
OpenCL™规范 5.17.4. 命令缓冲区排队
如果command_buffer不是使用CL_COMMAND_BUFFER_SIMULTANEOUS_USE_KHR标志创建的,并且处于挂起状态,则为CL_INVALID_OPERATION。如果event_wait_list为NULL,则。如果与command_buffer关联的上下文和event_wait_list中的事件不相同,则返回CL_INVALID_CONTEXT。CL_OUT_OF_RESOURCES,如果由于执行command_buffer所需的资源不足,导致无法在命令队列上对。翻译 2024-12-24 20:46:44 · 43 阅读 · 0 评论 -
OpenCL™规范 5.17.3. 创建命令缓冲区对象
CL_COMMAND_BUFFER_DEVICE_SIDE_SYNC_KHR-命令缓冲区中的所有命令都必须使用本机同步,如CL_DEVICE_COMMAND_BUFFER_SYNC_DEVICES_KHR所报告的那样。是无序命令队列,并且与该命令队列关联的设备不支持CL_COMMAND_BUFFER_CAPABILITY_OUT_OF_ORDER_KHR功能,则返回CL_INCOMPATIBLE_COMMAND_COMMAND_QUEUE_KHR。num_queues是队列中列出的命令队列的数量。翻译 2024-12-24 09:49:50 · 45 阅读 · 0 评论 -
OpenCL™规范 5.17.2. 命令缓冲区生命周期
Pending Count是处于Pending状态的命令缓冲区的副本数。默认情况下,命令缓冲区的挂起计数必须为0或1。如果命令缓冲区是用CL_COMMAND_BUFFER_SIMULTANEOUS_USE_KHR创建的,则命令缓冲区的挂起计数可能大于1。使用clFinalizeCommandBufferKHR完成命令记录后的状态,命令缓冲区可以排队。一旦命令缓冲区被排队到命令队列,它就会进入挂起状态,直到完成,此时它会移回可执行状态。命令缓冲区在创建时的初始状态,其中可以将命令记录到命令缓冲区中。翻译 2024-12-23 20:23:12 · 35 阅读 · 0 评论 -
OpenCL™规范 5.17.1. 命令缓冲区和多个设备
如果支持cl_khr_command_buffer_multi_device扩展,如果供应商提供设备间cl_sync_point_khr同步支持,则命令缓冲区可以包含记录到不同设备队列的命令。此功能通过CL_DEVICE_COMMAND_BUFFER_SYNC_DEVICES_KHR报告,该功能通知用户哪些设备可以在设备侧本地相互同步,或者通过CL_COMMAND_BUFFER_PLATFORM_UNIVERSAL_SYNC_KHR报告。但是,使用此功能,所有队列命令都必须记录为针对同一设备。翻译 2024-12-20 09:51:10 · 44 阅读 · 0 评论 -
OpenCL™规范 5.17. 命令缓冲区
命令缓冲区是使用命令队列的有序列表创建的,默认情况下,命令会记录到这些队列中并在其上执行。这些命令队列可以在命令缓冲区排队时用不同的命令队列替换,前提是替换列表中的每个元素的替换命令队列与创建命令缓冲区时使用的命令队列兼容。兼容的命令队列被定义为在相同的OpenCL上下文中,针对同一设备具有相同属性的命令队列。命令缓冲区对象应增加附加OpenCL对象的引用计数,如记录到命令缓冲区的命令中引用的队列、缓冲区、图像和内核。命令缓冲区对象不会更新记录在命令缓冲区中的内核上设置为参数的对象的引用计数。翻译 2024-12-19 09:49:48 · 39 阅读 · 0 评论 -
OpenCL™规范 5.16. 冲洗并完成
command_queue中所有先前排队的OpenCL命令都会发送到与command_queue关联的设备。要将引用命令队列中排队的命令的事件对象用作其他命令队列中的命令等待的事件对象,应用程序必须调用clFlush或任何执行命令队列隐式冲洗的阻塞命令,其中引用这些事件对象的命令被排队。CL_OUT_OF_HOST_MEMORY,如果无法在主机上分配OpenCL实现所需的资源。CL_OUT_OF_HOST_MEMORY,如果无法在主机上分配OpenCL实现所需的资源。不是有效的主机命令队列)。翻译 2024-12-18 10:41:17 · 36 阅读 · 0 评论 -
OpenCL™规范 5.15. 内存对象和内核的分析操作
如果支持cl_khr_command_buffer_multi_device扩展,并且如果没有可靠的设备计时器源可用于通知主机端,或者并行运行时调度使得无法识别第一个/最后一个命令,则实现可能会分别为CL_PROFILING_COMMAND_START和CL_PROFILING_COMMAND_END报告CL_PROFILING_COMMAND_SUBMIT和CL_PROFILING_COMMAND_COMPLETE。是用户事件对象,则CL_PROFILING_INFO_NOT_AVAILABLE。翻译 2024-12-17 09:51:31 · 45 阅读 · 0 评论 -
OpenCL™规范 5.14. 内核和内存对象命令的无序执行
应用程序可以通过设置命令队列的CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE属性,将排队到命令队列的命令配置为无序执行。这可以在创建命令队列时指定。同样,在clEnqueueNDRangeKernel、clEnqueueTask或clEnqueue NativeKernel命令之后排队的读取、写入、复制或映射内存对象的命令不能保证等待计划执行的内核完成(如果设置了CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE属性)。翻译 2024-12-16 22:00:07 · 49 阅读 · 0 评论 -
OpenCL™规范 5.13.8. 信号量查询
如果param_value为NULL,则忽略它。对于CL_SEMAPHORE_TYPE_BINARY_KHR类型的信号量,如果信号量处于未信号状态,则返回的有效载荷值将为0,如果处于信号状态,返回的有效负载值将为1。param_value_size_ret返回param_value查询的数据的实际大小(以字节为单位)。CL_INVALID_SEMAPHORE_KHR,如果sema_object不是有效的信号量。CL_OUT_OF_HOST_MEMORY,如果无法在主机上分配OpenCL实现所需的资源。翻译 2024-12-16 09:31:23 · 29 阅读 · 0 评论 -
OpenCL™规范 5.13.7. 保留和释放信号量
CL_INVALID_SEMAPHORE_KHR,如果sema_object不是有效的信号量对象。CL_INVALID_SEMAPHORE_KHR,如果sema_object不是有效的信号量对象。CL_OUT_OF_HOST_MEMORY,如果无法在主机上分配OpenCL实现所需的资源。CL_OUT_OF_HOST_MEMORY,如果无法在主机上分配OpenCL实现所需的资源。CL_OUT_OF_RESOURCES,如果无法在设备上分配OpenCL实现所需的资源。sema_object引用计数递减。翻译 2024-12-16 09:18:39 · 29 阅读 · 0 评论 -
OpenCL™规范 5.13.6. 等待和信号信号量
如果与command_queue关联的上下文与sema_objects中的任何信号量对象不相同,或者与command_queue关联的上下文和与event_wait_list中的事件关联的上下文不相同,则返回CL_INVALID_CONTEXT。如果与command_queue关联的上下文与sema_objects中的任何信号量对象不相同,或者与command_queue关联的上下文和与event_wait_list中的事件关联的上下文不相同,则返回CL_INVALID_CONTEXT。翻译 2024-12-15 21:47:32 · 37 阅读 · 0 评论 -
OpenCL™规范 5.13.5.2. NT手柄类型
CL_SEMAPHORE_HANDLE_OPAQUE_WIN32_NAME_KHR指定了一个NT句柄名称,该名称在OpenCL和其他兼容API之外只有有限的有效使用。CL_SEMAPHORE_HANDLE_OPAQUE_WIN32_KHR指定了一个NT句柄,该句柄在OpenCL和其他兼容API之外只有有限的有效使用。CL_SEMAPHORE_HANDLE_OPAQUE_WIN32_KMT_KHR指定了一个全局共享句柄,该句柄在OpenCL和其他兼容API之外只有有限的有效使用。它与任何原生API都不兼容。翻译 2024-12-14 19:24:29 · 21 阅读 · 0 评论 -
OpenCL™规范 5.13.5.1. 文件描述符句柄类型
CL_SEMAPHORE_HANDLE_OPAQUE_FD_KHR指定了一个POSIX文件描述符句柄,该句柄在OpenCL和其他兼容API之外只有有限的有效使用。信号量sema_object最初必须导入CL_SEMAPHORE_HANDLE_SYNC_FD_KHR类型的外部句柄。如果创建sema_object时未导入CL_SEMAPHORE_HANDLE_SYNC_FD_KHR句柄,则返回CL_INVALID_SEMAPHORE_KHR。如果fd无效,则CL_INVALID_VALUE。翻译 2024-10-18 17:32:50 · 69 阅读 · 0 评论 -
OpenCL™规范 5.13.5. 外部信号量句柄类型的描述
应用程序可以将相同的信号量有效负载导入多个OpenCL上下文,导入导出它的同一上下文,并多次导入给定的OpenCL上下文。在所有情况下,每个导入操作都必须创建一个不同的信号量对象。本节介绍由相关扩展添加的外部信号量句柄类型。翻译 2024-10-18 13:17:10 · 47 阅读 · 0 评论 -
OpenCL™规范 5.13.4. 导入信号量外部句柄
永久有效载荷导入的行为就像目标信号量被销毁一样,并且使用相同的句柄创建了一个新的信号量,但导入了有效载荷。因为导入信号量有效负载会暂时或永久地将现有有效负载与信号量分离,所以与应用于clReleaseSemaphoreKHR的使用限制类似的使用限制也适用于导入信号量负载的任何命令。当使用带有引用转移的句柄类型时,将有效载荷导入信号量会将该信号量添加到共享该有效载荷的所有信号量的集合中。此外,将信号量有效负载导出到具有复制传输的句柄,与执行信号量等待操作对源信号量的有效负载具有相同的副作用。翻译 2024-10-18 13:14:39 · 43 阅读 · 0 评论 -
OpenCL™规范 5.13.3. 导出信号量外部句柄
handle_type指定应为此可导出sema_object返回的信号量句柄的类型,并且必须是创建sema_object时指定的值之一。如果handle_size_ret为NULL,则忽略它。如果在创建sema_object时未指定请求的外部信号量句柄类型,则返回CL_INVALID_VALUE。如果handle_size小于存储返回句柄所需的大小,则返回CL_INVALID_VALUE。CL_OUT_OF_HOST_MEMORY,如果无法在主机上分配OpenCL实现所需的资源。翻译 2024-10-15 21:36:47 · 51 阅读 · 0 评论 -
OpenCL™规范 5.13.2. 创建信号量
CL_INVALID_DEVICE,如果CL_SEMAPHORE_DEVICE_HANDLE_LIST_KHR被指定为sema_props的一部分,但它并不能准确标识一个有效设备;CL_INVALID_DEVICE,如果由属性CL_SEMAPHORE_DEVICE_HANDLE_LIST_KHR标识的一个或多个设备无法导入请求的外部信号量句柄类型。指定可用于导出正在创建的信号量的信号量句柄类型属性列表(以CL_SEMAPHORE_EXPORT_HANDLE_TYPES_LIST_END_KHR结尾)。翻译 2024-10-15 20:23:32 · 41 阅读 · 0 评论 -
OpenCL™规范 5.13.1. 信号量类型
必须支持cl_semaphore_info_khr的cl_khr_semaphore扩展的“新建API枚举”部分中描述的所有枚举。cl_semaphore_properties_khr表示与信号量相关的属性。cl_semaphore_info_khr表示对信号量附加信息的查询。cl_semaphore_payload_khr表示信号量的有效载荷值。必须支持CL_SEMAPHORE_TYPE_BINARY_KHR。cl_semaphore_type_khr表示不同类型的信号量。翻译 2024-10-04 20:06:13 · 42 阅读 · 0 评论 -
OpenCL™规范 5.13. 信号量
本节介绍cl_khr_maphore扩展定义的信号量类型和函数。翻译 2024-10-04 20:02:36 · 63 阅读 · 0 评论 -
OpenCL™规范 5.12. 标记、屏障和等待事件
如果event_wait_list不为NULL,则event_wait_list指向的事件列表必须有效,num_events_in_wait_list必须大于0。此命令返回一个可以等待的事件,即可以等待此事件以确保event_wait_list中的所有事件或在此命令之前排队到command_queue的所有先前排队的命令都已完成。此命令返回一个可以等待的。,即可以等待此事件以确保event_wait_list中的所有事件或在此命令之前排队到command_queue的所有先前排队的命令都已完成。翻译 2024-10-04 20:00:43 · 90 阅读 · 0 评论 -
OpenCL™规范 5.11.1.2.1. 使用OpenGL栅栏同步对象进行显式同步
如果支持cl_khr_gl_event扩展,则使用clCreateEventFromGLsyncKHR创建的事件对象提供了另一种协调OpenGL和OpenCL之间缓冲区和图像共享的方法。当绑定到另一个线程的OpenGL上下文正在访问内存对象时,显式同步最有用。使用clCreateEventFromGLsyncKHR从生成的OpenGL同步对象创建事件;通过clEnqueueAcquireGLObjects确定该事件对象的完成。当绑定到另一个线程的OpenGL上下文正在访问内存对象时,显式同步最有用。翻译 2024-09-28 15:30:16 · 99 阅读 · 0 评论