我正在尝试编写一个在特定 CPU 上执行内核的 OpenCL 概念验证应用程序(因此将来可以扩展为 NUMA 感知并为相应 NUMA 上的内核执行分配内存-节点，正如指出的 in the Intel Dev forums )。
不幸的是，Windows 调度程序并不关心我想要什么，因为它似乎通过所有可用的 CPU 内核来循环我的内核(因此远离本地内存)。
我现在正在使用 CL_DEVICE_PARTITION_BY_COUNTS 属性创建一个只有一个执行单元的子设备，然后我在这个子设备上执行内核。尽管如此，当我观察 Windows 的 CPU 使用率时，并不是单个内核繁忙，而是多个内核的工作负载出现峰值(除非我使用任务管理器手动将进程固定到一个内核 - 然后我得到结果我一直期待)。
这是我用来创建子设备的属性的完整定义(如果我查询子设备的执行单元数量，它会正确地给出“1”):
cl_device_partition_property props[4];
props[0] = CL_DEVICE_PARTITION_BY_COUNTS;
props[1] = 1;
props[2] = CL_DEVICE_PARTITION_BY_COUNTS_LIST_END;
props[3] = 0;
我正在使用带有两个 Intel Xeon 处理器的 Windows 机器(顺便说一下，它们被 Intel OpenCL 实现识别为一个具有 24 个执行单元的执行设备)并且也尝试使用 CL_DEVICE_PARTITION_BY_NAMES_INTEL ，这也没有成功)。
我做错了什么(或理解错误的方式)？
感谢您的帮助。
最佳答案
您是否尝试过使用这些标志？
CL_AFFINITY_DOMAIN_L1_CACHE_EXT 0x1
CL_AFFINITY_DOMAIN_L2_CACHE_EXT 0x2
CL_AFFINITY_DOMAIN_L3_CACHE_EXT 0x3
CL_AFFINITY_DOMAIN_L4_CACHE_EXT 0x4
CL_AFFINITY_DOMAIN_NUMA_EXT 0x10
CL_AFFINITY_DOMAIN_NEXT_FISSIONABLE_EXT 0x100
我认为当您使用 CL_DEVICE_PARTITION_BY_COUNTS 时，您是在要求任何一个核心来完成这项工作。上面的标志将尝试根据缓存级别进行分组，无论如何这是您的目标。我自己还没有对此进行测试，看看操作系统是否会尊重亲和性，但我希望它应该这样做。 read more here.
关于c - 调度程序不考虑 OpenCL 子设备亲和性，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/27754816/