不可并行工作中的 Num Threads 权衡

Question

我一直是个好孩子，并且并行化了我的计算着色器以执行 955 个线程进行 20 次迭代

[numthreads(955, 1, 1)]
void main( uint3 pos : SV_DispatchThreadID )
{
    ...
    for (uint i = 0; i < 20; i++)
    {
        GroupMemoryBarrierWithGroupSync();
        //read from and write to groupshared memory
    }
}

但这不会奏效（因为并行化引入了实时延迟）所以我必须以一种不太并行的方式来做。 解决问题的简单方法是让 20 个线程每个执行 955 次迭代

[numthreads(20, 1, 1)]
void main( uint3 pos : SV_DispatchThreadID )
{
    ...
    for (uint i = 0; i < 955; i++)
    {
        GroupMemoryBarrierWithGroupSync();
        //read from and write to groupshared memory
    }
}

但是，我无法推断这将如何执行（可能非常糟糕）。

在这种新方法下，我必须保持迭代次数相同，但可以权衡我调用计算着色器的频率与线程数。 这给了我两个选择：

• 增加20 -> 32以获得完整的经线。
• 增加20 -> 32 * n使扭曲并行运行。

也许访问群共享 memory 非常便宜，所以我首先没有性能问题。

也许我应该尝试在 cpu 上优化它（我已经尝试过未优化并且性能低于预期）。

Answer 1

有人评论了这个答案

具体来说，单线程组通常会将利用率限制在 3-6% 左右。 只派遣一个小组使问题更加复杂，将利用率限制在远低于 1% 的范围内。 坚持使用二维大小的 256 个线程是一个很好的经验法则，您应该至少调度 2048 个左右的线程以保持硬件繁忙。

我决定在 gpu 上做这项工作是一件愚蠢的事情。 寻找可靠的解决方案总是最好的。

我的问题的最有效的解决方案是使用 SIMD，我现在必须通过艰苦的方式学习。