2.3 渲染管线并行

[ReturnDream (保密)]

我起初以为要将线程的计算工作移到 gpu 上去，但好像这并不是文档本意，因为若要如此操作势必要更改源代码后缀为 .cu 以及更改编译方式，这跟提交要求不符。

我在助教的公开分享文章里看到了这样一句：

启动 8 个线程便能够达到 4 以上的加速比

(edit1 来源：图形学实验框架 Dandelion 始末（四）：渲染模式与软渲染流程

文档的截图也确实显示出，8 个线程达到了 \frac{7.569}{1.231}=6.15 的加速比，但如果是 VertexProcessor::worker_thread、Rasterizer::worker_thread、FragmentProcessor::worker_thread 三类线程一起分这"8"个线程的话，假设工作时间主要由片元处理决定，因为每类线程至少要有一个，那最好的情况也是:
VertexProcessor::worker_thread: 1 个
Rasterizer::worker_thread:1 个
FragmentProcessor::worker_thread:6 个
加速比应该也不会超过 6 吧。

因为最理想情况就是 6 个 FragmentProcessor::worker_thread 能完全填补空闲时间，将这部分的时间 t_0 减少至 \frac{1}{6}t_0
( 不知道这样的分析方法对不对，还是说可以把这三个函数视为线程包工头，在这些包工头线程内部使用 std::thread 召唤工人线程来打工？
类似下图：

[storm314]

1. 本实验主要是在“软”光栅的基础上实现并行，所以不涉及 GPU，而且也不是所有设备都支持 CUDA。
2. 我不知道你看的是哪篇公开文章，但是在某些时候是可能发生超线性加速的，具体可以参考 加速比 - 维基百科，自由的百科全书。
3. 你当然可以在 work_thread 内部再维护一些线程在内部再进行任务的并行运算，但是没有必要。如何保持这些内部线程数据一致性，并且达到加速的效果，是个比较麻烦的事情。所以考虑如何增加各个阶段的 work_thread，以及如何优化各个阶段内的算法，就已经足够了。