【问题标题】:Process strings form OpenCL kernel处理字符串形成 OpenCL 内核
【发布时间】:2015-08-01 08:18:17
【问题描述】:

有几个类似的字符串

std::string 第一、二、三; ...

我的计划是将他们的地址收集到一个 char* 数组中:

char *addresses = {&first[0], &second[0], &third[0]} ...

并将 char **地址传递给 OpenCL 内核。

有几个问题或疑问:

主要问题是我无法传递指针数组。

有什么好的方法可以使用内核代码中的多对多字符串而不复制它们,而是将它们留在共享内存中?

我在 Windows 上使用 NVIDIA。所以,我只能使用 OpenCL 1.2 版本。

我无法连接字符串,因为它们来自不同的结构...

编辑:

根据第一个答案,如果我有这个(示例):

char *p;

cl_mem cmHostString = clCreateBuffer(myDev.getcxGPUContext(), CL_MEM_ALLOC_HOST_PTR, BUFFER_SIZE, NULL, &oclErr);

oclErr = clEnqueueWriteBuffer(myDev.getCqCommandQueue(), cmHostString, CL_TRUE, 0, BUFFER_SIZE, p, 0, NULL, NULL);

我是否需要将 char 数组的每个元素从主机内存复制到主机的其他部分 内存(并且新地址对主机隐藏)? ?这不符合我的逻辑。为什么我不能使用相同的地址?我可以直接从 GPU 设备访问主机内存并使用它。

【问题讨论】:

  • std::string 将其内容保存在堆上并使用内部引用,即指向数据的内部指针很可能指向另一个字符串实例,直到您开始修改它。我不明白你为什么要这样做。您可以传递指针数组,但需要注意它们指向的位置。
  • 谢谢。我无法在 1.2 中将 (__global char **myWords) 传递给内核。我什至无法编译
  • 手头没有可用的 OpenCL 设置,但有几次我使用了 __local float* 输入[2],参见例如stackoverflow.com/questions/11978024/…。您始终可以使用单个指针并在内核中重新建立行指针。如果字符串的长度不同,它会有点混乱
  • 我不确定我是否理解你。但我认为在 1.2 的情况下我在内核中有不同的地址。这意味着我不能在不复制整个数组的情况下使用 [] 运算符,不是吗?
  • 如果你知道所有字符串的长度,你可以将字符保存在一个大的一维数组中,并在内核内部创建行指针,这样你就可以得到一个指针数组,char* input[NSTRINGS ],输入[i] = largeArray[i*STRING_LENGTH]。这比一遍又一遍地使用偏移更容易。

标签: c windows opencl gpgpu nvidia


【解决方案1】:

有什么好的方法可以使用内核代码中的多对多字符串而不复制它们,而是将它们留在共享内存中?

不在 OpenCL1.2 中。共享虚拟内存概念自 OpenCL 2.0 起可用,但 NVidia 尚不支持。您将需要切换到支持 OpenCL 2.0 的 GPU,或者对于 OpenCL 1.2,将您的字符串复制到连续的字符数组中并将它们(复制)传递给内核。


EDIT:响应您的编辑 - 您可以使用:

  • CL_MEM_ALLOC_HOST_PTR 标志创建所需大小的空缓冲区,然后使用 clEnqueueMapBuffer 映射该缓冲区,并使用从映射返回的指针填充它。之后使用 clEnqueueUnmapMemObject 取消映射缓冲区。
  • CL_MEM_USE_HOST_PTR 标志创建所需大小的缓冲区并将指针传递给您的字符数组。

根据我的经验,使用CL_MEM_USE_HOST_PTR 标志创建的缓冲区通常会稍微快一些,我认为数据是否真正被复制取决于实现。但要使用它,您需要先在主机上准备好字符数组。

您基本上需要进行基准测试,看看哪个更快。也不要过多关注数据复制,与运行内核所需的时间(当然取决于内核中的内容)相比,这些数字通常很小(以 GB/秒为单位传输)。

【讨论】:

  • 我了解了 OpenCL 2.0 以及我可以用它做什么。是的,也许我应该改变......
猜你喜欢
  • 1970-01-01
  • 2018-12-27
  • 1970-01-01
  • 1970-01-01
  • 2020-03-16
  • 2023-03-05
  • 1970-01-01
  • 2017-04-02
  • 1970-01-01
相关资源
最近更新 更多