为何大Tile的OpenCL三角形渲染优化反而使代码变慢？

原因分析 #

• 核显硬件特性限制：i5-1240p的Xe核显属于低功耗GPU，计算单元数量有限。大Tile方案让单个work item处理更多像素，导致串行计算占比过高，无法充分利用GPU的SIMD并行能力。2x2 Tile时每个work item的计算量刚好匹配核显的SIMD宽度，换成大Tile后，串行执行的逐像素重心坐标计算、深度测试等操作，会抵消Tile剔除带来的收益。
• Tile剔除开销反超收益：大Tile的四角检测逻辑看似能跳过空Tile，但实际场景中（尤其是小三角形占比高的场景），大量Tile属于部分覆盖状态，四角检测无法过滤这类Tile，反而额外增加了判断开销。即使换回2x2 Tile，若保留了新增的检测逻辑，也会拖慢原本高效的执行流程。
• 内存访问模式恶化：大Tile遍历顺序若不合理，会出现非连续内存访问，导致核显缓存命中率下降。而2x2 Tile的像素通常是连续的，更符合GPU内存访问偏好，缓存利用率更高。
• work group配置不匹配硬件：大Tile会改变work group尺寸，若未对齐Xe核显的Wavefront大小（通常为16或32），会导致硬件线程调度效率降低，出现空闲执行单元。

优化建议 #

• 适配核显的Tile与work group尺寸：测试1x4、2x4这类Tile大小，让单个work item的计算量匹配SIMD宽度；同时将work group大小设置为16或32（对齐Wavefront），比如让一个work group处理8x4区域，拆分为多个2x4 Tile分配给work item。
• 优化Tile剔除逻辑：替换四角检测为更高效的AABB与三角形快速相交测试，利用三角形边方程判断Tile是否完全在三角形外；对于小三角形，直接跳过Tile剔除，改用单像素或小Tile处理，避免额外开销。
• 优化内存访问顺序：确保Tile内像素按行优先连续遍历，让帧缓冲、纹理的访问符合GPU缓存行对齐要求，提升缓存命中率。
• 减少work item内部分支：大Tile遍历中的逐像素分支判断会导致SIMD发散，降低执行效率。可改用掩码操作替代分支，或提前计算Tile内所有像素的覆盖状态，批量处理。
• 利用核显向量指令：Xe核显支持向量运算指令，可将逐像素的重心坐标增量计算打包为向量操作，提升单work item的处理效率。
• 清理2x2 Tile的冗余逻辑：若换回2x2 Tile后性能下降，检查是否保留了不必要的Tile检测逻辑，恢复到最初无额外判断的2x2实现，对比开销差异。

内容的提问来源于stack exchange，提问作者melon_head5