OpenCL实战一

OpenCL之运行环境配置

一、配置环境

环境变量

参考意见修改环境变量：
https://blog.csdn.net/chocolate2018/article/details/109162307

这些环境变量可用于控制OpenCL行为并提供调试的可见性。

TI_OCL_COMPUTE_UNIT_LIST=”0”

TI_OCL_KEEP_FILES
当为DSP编译OpenCL C内核时，结果是/tmp子目录中的二进制.out文件。它们随后可下载到DSP以供运行。编译过程为每个源文件生成多个中间文件。OpenCL通常会删除这些临时文件。但是，有时检查这些文件是有用的。可以将此环境变量设置为指示运行时将临时文件留在/tmp中。检查与OUT文件关联的程序集文件，可以帮助您查看代码优化得有多好。
TI_OCL_DEBUG
设置此环境变量将修改OpenCL应用程序的执行，以启用OpenCLC内核的调试。如果应用程序使用在线编译(即从字符串而不是二进制编译)，那么在线编译将调试标志断言给编译器。(如果应用程序使用脱机编译，即从二进制文件创建程序，则需要将-g作为选项传递给脱机编译器clocl。OpenCL运行时在分派所有内核之前暂停应用程序。当暂停运行时，运行时会向用户指示内核调度正在挂起。
目前，通过将TI_OCL_DEBUG设置为“gdb”或“ccs”，支持两种调试方法。如果设置为“gdb”，运行时将提供gdbc6x命令来连接到DSP并设置适当的断点。如果设置为“CCS”，运行时将提供CodeComposerStudio(CCS)指令，以连接到DSP并设置适当的断点。在这两种方法中，运行时强制内核中的所有内核和工作组只在dsp核心0上执行。详细信息可以在调试中找到。
TI_OCL_CACHE_KERNELS
内核的在线编译是便携式OpenCL程序的一个有用特性。为设备编译内核所需的所有细节都封装在OpenCL API调用中。然而，DSP的在线编译可能很费时.设置此环境变量会导致OpenCL运行时对内核执行一次在线编译，并将结果缓存在/tmp中的数据库中。在不修改内核源代码或编译它的选项的情况下再次运行应用程序，就会绕过编译步骤，并使用缓存的内核二进制文件。
TI_OCL_COMPUTE_UNIT_LIST
将OpenCL运行时可用的计算单元指定为一个逗号分隔的计算单元索引列表，从0开始。指定的计算单元列表必须是连续的，例如K2H上的“1，2，3，4”。如果未指定环境变量，则运行时默认使用设备上可用的所有计算单元(或从OpenCL产品版本1.1.13开始，所有可用的计算单元在/etc/ti-MCTD/ti_MCTD_config.json中指定)。

Example usage on AM570x:
 
Listing 9 runs the vecadd kernel only on DSP1¶
-> TI_OCL_COMPUTE_UNIT_LIST="0" ./vecadd
Listing 10 runs the vecadd kernel only on DSP2¶
-> TI_OCL_COMPUTE_UNIT_LIST="1" ./vecadd
Listing 11 runs the vecadd kernel on both DSP1 and DSP2 (default behavior)¶
-> TI_OCL_COMPUTE_UNIT_LIST="0, 1" ./vecadd

TI_OCL_LOAD_KERNELS_ONCHIP
默认情况下，OpenCL内核相关代码和全局数据将从DDR内存中分配。如果设置了此环境变量，则从MSMC内存中分配与内核相关的代码和全局数据。
TI_OCL_CPU_DEVICE_ENABLE
目前，OpenCL ARM CPU设备只支持本机内核(有关本机内核的描述，请参阅OpenCL1.1规范)。因此，默认情况下，在执行OpenCL平台查询时，ARM CPU不被视为计算设备。如果应用程序只对本机内核使用ARM CPU，那么可以使用这个环境变量作为OpenCL的计算设备。即使设置了这个环境变量，也不支持将NDRangeKernels或任务排队到CPU。
TI_OCL_WORKER_SLEEP
OpenCL运行时启动应用程序中定义的每个OpenCL命令队列的新CPU线程。这些线程管理OpenCL命令队列以及CPU与命令队列关联的设备之间的通信。如果在设备上有主动运行的OpenCL内核，则为监视与设备代表这些内核的通信而分配的线程消耗CPU资源，检查这些内核的状态。该环境变量可用于提供对消耗多少CPU资源的控制级别。当不设置 TI_OCL_WORKER_SLEEP时，OpenCL运行时使用更多的CPU容量，以确保内核执行上最快的周转延迟。当将ti_OCL_worker_sleep环境变量设置为几微秒时，它会降低内核执行的周转延迟，以降低监视内核所需的CPU容量。如果应用程序不是由CPU周期限制的性能，或者应用程序对许多细粒度内核进行排队，那么具有 TI_OCL_WORKER_SLEEP环境变量UNSET是合适的。在相反的情况下，当CPU周期限制了应用程序的性能或如果更少，但是更长的运行内核会排队，则将 TI_OCL_WORKER_SLEEP置为某个数量的微秒是合适的。要使用的微秒的正确数量取决于执行平台和特定应用。然而，使用从80到150的范围内的微秒值是合理的起点。
TI_OCL_ENABLE_FP64
C66xDSP是双精度浮点，在OpenCL实现中支持双精度浮点OpenCL规范中的所有可选功能，但双FP支持包括子正常行为或优雅下溢的要求除外。C66xDSP上的64位浮点硬件不支持子正常行为。它支持与零行为的刷新。为了支持双打的子正常行为，需要软件仿真，这将会对C66xDSP的硬件性能造成重大的性能损失。因此，默认情况下，在TIOpenCL实现中支持的平台和设备不支持双浮点的支持。也就是说，如果查询了平台或设备进行扩展，则默认情况下不列出CL_KHR_FP64。此外，OpenCLC预定宏CL_KHR_FP64不会默认定义。当设置TI_OCL_ENABLE_FP64环境变量时，TIOpenCL实现报告支持双浮点，即CL_KHR_FP64被列为平台的扩展，并在编译OpenCL内核时定义DSP设备和CL_KHR_FP64。此环境变量控制OpenCLImplementation是否支持Double。然而，双、所有双矢量类型和使用双打的所有内置函数都被支持和可用，而不考虑该环境变量的设置。
TI_OCL_VERBOSE_ERROR
OpenCL规范提供了一个明确定义的机制，用于从API函数返回错误代码。然而，通常情况是出于不同原因返回通用错误代码。当设置此环境变量时，除了定义的返回代码错误机制之外，OpenCL运行时可能会打印更多的描述错误消息。
TI_OCL_WG_SIZE_LIMIT
OpenCL将查询提供给一个设备，以查找工作组中允许的最大工作项数量。TI的实施中的DSP设备允许每个工作组大量的工作项。其他OpenCL实现具有小得多的最大工作组大小限制。当运行代码为其他OpenCL实现而设计和优化时，此环境变量可用于限制报告的最大工作组大小。
TI_OCL_PROFILING_EVENT_TYPE
指定要配置的硬件事件类型。两个基本的划分，失速周期事件和内存事件，描述在剖析。如果指定了1，OpenCL运行时将分析一个失速循环事件。如果指定了2，OpenCL运行时将分析一个或两个内存事件。否则，将禁用分析。
TI_OCL_PROFILING_EVENT_NUMBER1
指定要配置文件的事件号。此变量的确切值表示来自AET_GEM_START_EVT_START或AET_GEM_MEM_EVT_START的偏移量，这取决于事件类型。有关完整的事件列表，请参见分析。
TI_OCL_PROFILING_EVENT_NUMBER 2
指定要配置文件的第二个内存事件号。可以跳过。
TI_OCL_PROFILE_STACK_BLOCK
阈值指定了要计数的失速循环的阈值。计数器中只捕获失速周期高于此阈值的失速事件。OpenCL运行时中的默认值为1，即捕获所有暂停事件。

Dispatch from multiple Linux processes
在OpenCL版本1.1.11及更高版本上，与OpenCL应用程序对应的Linux进程在遇到第一个OpenCL API调用时获得OpenCL DSP设备的所有权，并在其结束时放弃所有权。互斥访问是使用文件锁/var/lock/OpenCL实现的。如果进程A和B包含OpenCL API调用并且A开始运行，A将在执行第一个OpenCL API调用时获得文件锁。进程A将保持锁，直到它完成执行，此时进程B可以获得锁。另外，如果一个进程分叉了一个子进程，并且两个进程都调用了OpenCL API，那么这些进程就会死锁。从1.1.12版本开始，取消了进程级锁/var/lock/OpenCL。多个Linux进程可以将OpenCL内核分派给DSP。每个内核运行到完成。由多个进程提交的内核的执行是交错的。

ti-mctd 介绍

为了启用并发进程来调度OpenCL API，添加了一个守护进程（ti-mctd）。守护进程提供以下服务：
管理OpenCL连续内存（CMEM）堆。
由于OpenCL API的多个进程共享堆，因此守护进程提供了一个集中的位置来管理堆。 开放式DSP监控寿命管理（仅在K2x SoCs上）。在K2x设备上，ti-mctd守护进程使用MPM在启动期间在DSP上重置、加载和运行OpenCL监视器。 作为systemd服务，在引导期间启动ti-mctd守护进程。
关联的systemd单元文件位于/lib/systemd/system/ti-mct-daemon.service。
使用场景2，可以使用守护进程配置文件/etc/ti-mctd/ti_mcd_config.json中指定的更大的Linux共享内存区域来停止和重新启动ti-MCTD守护进程。例如：

# pkill ti-mctd
# edit /etc/ti-mctd/ti_mctd_config.json, increase linux-shmem-size-KB from 128 to 256
# rm /dev/shm/HeapManager (if still exists)
# ti-mctd
# ls -lh /dev/shm/HeapManager
-rw-r--r--    1 root     root      256.0K May  2 

15:44 /dev/shm/HeapManager
ti-mct-heapcheck

ti-mct-heap-check打印OpenCL CMEM堆的当前状态。例如，下面的输出是在执行OpenCL程序期间运行ti-mct-heap-check时生成的。
可以使用-c选项释放任何分配的块，而分配这些块的进程没有释放这些块。这种情况通常发生在进程异常终止时。

ti-mctd 配置文件

从OpenCL产品版本1.1.13开始，ti-mctd守护进程在启动时读取配置文件etc/ti-mctd/ti_mctd_config.json。以下是来自K2H EVM的示例配置：

root@k2hk-evm:~# cat /etc/ti-mctd/ti_mctd_config.json
{
        "cmem-block-offchip" : "0",
        "cmem-block-onchip" : "1",
        "compute-unit-list" : "0,1,2,3,4,5,6,7",
        "linux-shmem-size-KB" : "128",
        "eve-devices-disable" : "0",
}

cmem-block-offchip和cmem-block-onchip指定用于OpenCL的CMEM块ID。OpenCL需要片外CMEM块，而片上CMEM块是可选的。提供了这两个配置项，以便OpenCL CMEM块可以与专用于其他用途的CMEM块共存。
compute-unit-list
指定OpenCL应用程序可以使用的DSP。这是一个系统范围的配置。它可以被环境变量TI_OCL_COMPUTE_UNT_LIST在每个shell或每个应用程序的基础上重写。计算单元列表必须是连续的。但是它不需要从第一个可用开始，以系统中最后一个可用的DSP结束。例如，1，2，3，4，5，6是K2H上的有效计算单元列表。OpenCL内核将只被分派到此列表中指定的DSP。提供此配置项是为了使OpenCL DSP可以与专用于其他用途的DSP共存。

执行步骤

root@AM57xx-Tronlong:~# ti-mctd 
root@AM57xx-Tronlong:~# TI_OCL_COMPUTE_UNIT_LIST="0" ./abort_exit 
TIOCL FATAL: Internal Error: Number of message queues (0) does not match number of compute units (1)
root@AM57xx-Tronlong:~#


root@AM57xx-Tronlong:~# cat /proc/iomem | grep CMEM
40500000-405fffff : CMEM
a0000000-abffffff : CMEM
root@AM57xx-Tronlong:~# [   39.488832] random: crng init done
 

TI 指导链接

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/676127/linux-dra746-internal-error-number-of-message-queues-0-does-not-match-number-of-compute

感谢阅读，祝君成功！
-by aiziyou