4

我正在探索使用计算着色器将骨骼变形应用于网格顶点，而不是使用流输出的顶点着色器。我发现计算着色器的执行速度比顶点着色器慢得多，但在我把它写下来之前，我想确定我没有做错什么。

使用我的 100,000 个顶点的测试数据和 300 个骨骼的 1,000 帧动画数据，顶点着色器的运行时间约为 0.22 毫秒，而计算着色器的运行时间是 0.85 毫秒的 4 倍。计时是通过 D3D API 计时器查询（而不是 cpu 计时器）完成的。

变形结构体.hlsl

struct Vertex {
  float3 position : POSITION;
  float3 normal : NORMAL;
  float2 texcoord : TEXCOORD;
  float3 tangent : TANGENT;
  float4 color : COLOR;
};

struct BoneWeights {
  uint index;
  float weight;
};

StructuredBuffer<matrix> g_bone_array : register(t0);
Buffer<uint> g_bone_offsets : register(t1);
Buffer<uint> g_bone_counts : register(t2);
StructuredBuffer<BoneWeights> g_bone_weights : register(t3);

bone_deform_cs.hlsl

#include "deform_structs.hlsl"

StructuredBuffer<Vertex> g_input_vertex : register(t4);
RWStructuredBuffer<Vertex> g_output_vertex : register(u0);

[numthreads(64,1,1)]
void BoneDeformCS(uint id : SV_DispatchThreadID) {
  Vertex vert = g_input_vertex[id.x];
  uint offset = g_bone_offsets[id.x];
  uint count = g_bone_counts[id.x];

  matrix bone_matrix = 0;
  for (uint i = offset; i < (offset + count); ++i) {
    BoneWeights weight_info = g_bone_weights[i];
    bone_matrix += weight_info.weight * g_bone_array[weight_info.index];
  }

  vert.position = mul(float4(vert.position,1), bone_matrix).xyz;
  vert.normal = normalize(mul(vert.normal, (float3x3)bone_matrix));
  vert.tangent = normalize(mul(vert.tangent, (float3x3)bone_matrix));
  g_output_vertex[id.x] = vert;
}

bone_deform_vs.hlsl

#include "deform_structs.hlsl"

void BoneDeformVS(uint id : SV_VertexID, Vertex vsin, out Vertex vsout) {
  uint offset = g_bone_offsets[id];
  uint count = g_bone_counts[id];

  matrix bone_matrix = 0;
  for (uint i = offset; i < (offset + count); ++i) {
    BoneWeights bone_info = g_bone_weights[i];
    bone_matrix += bone_info.weight * g_bone_array[bone_info.index];
  }

  vsout.position = mul(float4(vsin.position,1), bone_matrix).xyz;
  vsout.normal = normalize(mul(vsin.normal, (float3x3)bone_matrix));
  vsout.tangent = normalize(mul(vsin.tangent, (float3x3)bone_matrix));
  vsout.texcoord = vsin.texcoord;
  vsout.color = vsin.color;
}

缓冲区运行后比较它们的内容，它们是相同的并且包含预期值。

我怀疑我可能错误地执行了计算着色器，产生了太多线程？我传递给Dispatch错误的号码吗？由于它是一维数据行，因此对我来说使用[numthreads(64,1,1)]. 我尝试了 32-1024 的各种值。64 似乎是最佳选择，因为它是高效使用 AMD GPU 所需的最低要求。反正。当我调用时Dispatch，我要求它执行(vertex_count / 64) + (vertex_count % 64 != 0) ? 1 : 0。对于 100,000 个顶点，调用最终为Dispatch(1563,1,1).

ID3D11ShaderResourceView * srvs[] = {bone_array_srv, bone_offset_srv,
                                     bone_count_srv, bone_weights_srv,
                                     cs_vertices_srv};
ID3D11UnorderedAccessView * uavs[] = {cs_output_uav};
UINT srv_count = sizeof(srvs) / sizeof(srvs[0]);
UINT uav_count = sizeof(uavs) / sizeof(uavs[0]);
UINT thread_group_count = vertex_count / 64 + (vertex_count % 64 != 0) ? 1 : 0;

context->CSSetShader(cs, nullptr, 0);
context->CSSetShaderResources(0, srv_count, srvs);
context->CSSetUnorderedAccessViews(0, uav_count, uavs);
context->Dispatch(thread_group_count, 1, 1);

这就是顶点着色器的执行方式：

ID3D11ShaderResourceView * srvs[] = {bone_array_srv, bone_offset_srv,
                                     bone_count_srv, bone_weights_srv};
UINT srv_count = sizeof(srvs) / sizeof(srvs[0]);
UINT stride = 0;
UINT offset = 0;

context->GSSetShader(streamout_gs, nullptr, 0);
context->VSSetShader(vs, nullptr, 0);
context->VSSetShaderResources(0, srv_count, srvs);
context->SOSetTargets(1, &vs_output_buf, &offset);
context->IASetPrimitiveTopology(D3D11_PRIMITIVE_TOPOLOGY_POINTLIST);
context->IASetInputLayout(vs_input_layout);
context->IASetVertexBuffers(0, 1, &vs_vertices, &stride, &offset);
context->Draw(vertex_count, 0);

或者答案仅仅是从着色器资源视图读取并写入无序访问视图比从顶点缓冲区读取并写入流输出缓冲区要慢得多？

4

1 回答 1

5

我只是在学习如何使用计算着色器，所以我不是专家。关于你的骨骼计算，我确信 CS 至少应该和 VS 一样快。直觉告诉我，numthreads (64,1,1) 它的效率不如numthreads (16,16,1). 所以你可以试试这种方法：

  1. 将您的线性缓冲区视为具有二次布局，x 和 y 大小相同
  2. 计算 x/y 大小为size = ceil (sqrt (numvertices))
  3. ch(size / 16, size / 16)在您的程序和numthreads (16,16,1)hlsl 文件中使用 dispat
  4. 分配一个常量缓冲区，您可以在其中复制size和numvertices值
  5. 而不是使用id.x作为索引，您计算自己的（线性）索引为int index = id.y * size +id.x)，（也许 id.xy 也可以作为索引）

  6. 在大多数情况下size * size会大于numvertices，所以你最终会得到比顶点更多的线程。您可以通过在 hlsl 函数中添加条件来阻止这些额外的线程：

    int index = id.y * size +id.x;
if (index < numvertices) { .. // your code follows

我希望这种方法可以加快您的 CS 计算速度。

================ 编辑==================

我的建议是基于我自己的计时测试。为了验证我的情况，我用更多的 numthreads 参数变化重复了这些测试。我计算了超过 1034 x 827 = 855,118 像素的 mandelbrot 集。结果如下：

numthreads       Dispatch      groups  threads/  total
  x   y    fps     x     y             group     threads

  4   4    240    259   207    53445     16     855118
  8   8    550    129   103    13361     64     855118
 16  16    600     65    52     3340    256     855118
 32  32    580     32    26      835   1024     855118
 64   1    550     16   827    13361     64     855118
256   1    460      4   827     3340    256     855118
512   1    370      2   827     1670    512     855118

如您所见，最佳点 - numthreads(16,16,1) - 创建与 numthreads(256,1,1) 相同的 #of 线程组 (3340)，但性能提高了 30%。请注意，总线程数（并且必须）始终相同！我的 GPU 是 ATI 7790。

================ 编辑2 ==================

为了更深入地调查您关于 CS 与 VS 速度的问题，我重新观看了一个非常有趣的第 9 频道视频（PDC09 演示文稿，由 Microsoft 首席架构师 Chas Boyd 举办，关于直接计算，请参见下面的链接）。在此演示文稿中，Boyd 指出优化线程布局 (numthreads) 可以导致吞吐量增加两倍。

然而，更有趣的是他的演讲部分（从第 40 分钟开始），他解释了 UAV 和 GPU 内存布局之间的相关性（“图形与计算 I/O”）。我不想从 Boyds 的陈述中得出错误的结论，但似乎至少有可能，通过 UAV 绑定的计算着色器确实比其他 GPU 着色器具有更低的内存带宽。如果这是真的，我们可能会解释无人机不能绑定到 VS 的事实，例如（至少在版本 11.0 中）。

由于这些内存访问模式也取决于硬件设计，因此您应该将您的问题直接上报给 ATI / NVIDIA 工程师。

结论

我已经吸收了大量关于 CS 使用的信息，但没有丝毫迹象表明 CS 可以比 VS 运行相同的算法慢。如果情况确实如此，那么您已经检测到对所有使用直接计算的人来说都很重要的东西。

链接：http ://channel9.msdn.com/Events/PDC/PDC09/P09-16

于 2013-11-27T14:02:46.313 回答