问题标签 [directcompute]

我正在为计算着色器存储一组 uint 的方式而苦苦挣扎。我有以下着色器代码（重现问题的简单极简示例）：

编译后，我检查编译器的输出以了解常量缓冲区项的偏移量和大小。项目“uint UIntArray[10];” 令人惊讶的大小为 148 字节。这很奇怪，因为 uint 是 4 个字节。所以我希望数组大小为 40 个字节。

这是编译器输出：

我检查了各种数组大小，结果很奇怪：当元素数量改变时，每个元素的大小是不同的！

我做错了什么或者我想念什么？谢谢。

我有一个 DirectCompute 应用程序对图像进行计算（比如计算平均像素值、应用过滤器等等）。对于某些计算，我只是将图像视为整数数组并像这样调度计算机着色器：

结果正是预期值，因此计算是正确的。尽管如此，在运行时，我在调试日志中看到以下消息：

此错误仅显示在调试日志中，其他一切都正确，包括计算结果。这让我认为 GPU 以某种方式管理非常大的线程组，可能会将其分解为按顺序执行的较小组。

我的问题是：我应该关心这个错误还是可以保留它并让 GPU 为我完成工作？

谢谢。

我正在查看来自 Nvidia 的并行缩减示例。如果tid < 32那么线程都意味着在同一个warp中，那么指令应该是SIMD同步的，所以我们可以假设sdata[tid] += sdata[tid + 32];之前的所有线程都完成了sdata[tid] += sdata[tid + 16];，依此类推。但这对我来说并没有发生。

Cuda 上相同问题的解决方案已经发布（参见），但它使用指针和 volatile 关键字。Directcompute 没有指针，也不允许在全局内存上使用 volatile 关键字。

我正在尝试在 gpu 中实现截锥剔除。在阅读了一些内容并偶然发现了这个非常有用的存储库：https ://github.com/ellioman/Indirect-Rendering-With-Compute-Shaders之后，我注意到 goto 实现似乎是

1. 测试所有对象的 bbox 并用 1 标记相机平截头体中的对象，以及不使用 0 的对象
2. 将结果保存在缓冲区中。
3. 对此缓冲区执行扫描算法
4. 使用作为最终缓冲区中的索引计算的索引来存储选定的矩阵，这些矩阵将在绘制过程中使用。

但我想知道：为什么要使用扫描及其所有复杂性，而不仅仅是将通过 bbox 测试的对象的矩阵直接附加到附加缓冲区中？我的猜测是 appendbuffer 访问速度很慢，但它们是否比在 gpu 上运行扫描慢（如果输入数组大于每组的最大线程数，则可能需要 2 个调度调用）。

谢谢 ！

编辑：我是团结一致的，但我认为这个问题并不重要。

我想提高计算着色器的性能。

shader的每个线程组需要8个数据块，每个数据块有24个元素。

我主要针对我的开发 PC 中的 GeForce 1080Ti 和生产服务器中的 Tesla V100 进行优化，但其他人也在他们的工作站上运行此代码，GPU 各不相同，不一定是 nVidia。

哪种方式更好：

1. [numthreads( 24, 1, 1 )]，写一个循环for( uint i = 0; i < 8; i++ )
   这在每个warp中浪费了25%的执行单元，但是内存访问模式很棒。这 24 个活动线程的 VRAM 读取要么合并，要么完全广播。

2. [numthreads( 96, 1, 1 )], write a loopfor( uint i = groupThreadID / 24; i < 8; i += 4 )
   在执行单元利用率方面看起来更好，但是 VRAM 访问模式变得更糟，因为每个 warp 正在读取 2 个输入数据切片。
   我也担心GroupMemoryBarrierWithGroupSync()内在的同步损失，组共享内存会分成 3 个扭曲。
   实施起来也有点困难。

我一直在以最糟糕的风格编写 gpgpu 计算着色器（即只有一个整体程序）。我认为问题是我已经阅读了不是这样的虚拟代码，所以我希望有人能指出一些代码来学习风格。

我希望以更具功能性的风格进行编程（对于我的并行减少、蝴蝶等），并且想知道是否可以使用宏来实现某些目标。（扫描被认为是 gpgpu 的原语）

我正在寻找的东西包括：

• hlsli 包含文件以防止重复。
• 铸造组共享内存。起初我放弃了，因为我无法正确转换 c 数组。

• 通过输出参数写入组共享内存。

另外，如果有人有任何这样的风格提示，请发布。

我想要有范围的组共享内存，所以我可以完成一个使用一种格式的组共享内存的计算（即并行减少）并开始一个使用不同格式的新的（以避免超过组共享内存限制或不得不分成两个着色器）。

以下编译但给了我之前计算的剩余数据并且非常慢：

这也可以编译，但速度非常慢。

无论如何要让它正常工作。剩余数据可能是由于打包差异DirectCompute 着色器（HLSL）具有奇怪的数组大小

我正在开发一个放置系统，我从特定参数中找到计算着色器中的位置，然后将它们附加到 AppendStructuredBuffer。这按预期工作。问题源于在另一个着色器中使用生成的缓冲区，该着色器也尝试追加到新的 AppendStructuredBuffer。该缓冲区的输出比输入的要少得多。

最终将结果复制到最终缓冲区以使用 DrawMeshInstancedIndirect 进行渲染。

这是计算着色器，它只是将对象放置在平面上。

而调度 - 在更新中运行，着色器已在启动函数中实例化。

它应该看起来如何

然后我有另一个计算着色器，它使用该缓冲区作为 StructuredBuffer 来读取，然后填充另一个 AppendStrucuredBuffer，最终会在这里发生一些剔除。这是第二个计算着色器：

这是我调用第二个计算着色器的方法。它在第一个着色器调度之后运行。

第一个着色器的 AppendStructuredBuffer 在第二个计算着色器中设置为 StructuredBuffer“_InVegetationData”。

使用第二个计算着色器后的样子：注意细化。

结果的希望是第一个计算着色器/缓冲区的输出，但如果我不将它们附加到第二个计算着色器中，它们就不会出现。我认为这可能/肯定是 GPU 未完成或类似的问题，但我不太确定。任何帮助都感激不尽！

谢谢。