几个硬件相关问题

[pointer3d]

有几个硬件相关问题想在这里咨询一下各位大牛.

1. 在硬件层面上, 做深度测试时 z-read/test/write 是否是单独的一次操作呢? 还是分解为了几个步骤, 比如有的模型是关闭 z-test 的, 这种情况下硬件开销是否比完整的深度测试小?

2. 对于 alpha blend 的 fragment, 是需要完整的 frame buffer-read/modify/write 操作的, 该操作是否也是单独的一次操作呢? 还是分解为了几个步骤. 我理解上, 不需要 alpha blend 的 fragment 是不需要 frame buffer-read/modify 操作, 只需要 frame buffer-write, 这在整个渲染中占大多数, 那么硬件是否针对只需要 fb-write 的操作进行了优化? 相比完整的 fb-read/modify/write 操作更少的时钟周期?

3. 因为都是在 on-chip memory 上操作的, 完整的 z-read/test/write 操作相比于完整的 fb-read/modify/write 操作哪个开销更小? 我理解上, fb-modify 操作比 z-test 操作要复杂, 是否会消耗更多的时钟周期?

4. 在使用 alpha test 时, 因为在 fragment shader 阶段可能存在 discard 操作, 所以只有跑完完整的 fragment shader 才能够确定 fragment 是否需要保留, 这样会破坏 early-z. 那么硬件是如何处理带有 alpha test 的 fragment 的呢? 是发现 shader 中存在 discard 操作, 就对三角形投射到的整个 tile 关闭 early-z 开启 late-z; 还是先不管, 假设所有 fragment 都不会 discard, 在 fragment shader 阶段真正遇到 discard 操作后, 才对整个 tile(或者是单个fragment?) 进行补救操作?

盼复.

[宁道奇]

1. 在硬件层面上, 做深度测试时 z-read/test/write 是否是单独的一次操作呢? 还是分解为了几个步骤, 比如有的模型是关闭 z-test 的, 这种情况下硬件开销是否比完整的深度测试小? 硬件做这个很快的，这个不是瓶颈，你可以理解为写入的同时做了测试。 关闭深度测试后，就要看情况了。节省了深度测试的步骤，但是可能导致多画一些被挡住的像素。如果没有遮挡，关掉深度测试硬件开销是要小一些。 2. 对于 alpha blend 的 fragment, 是需要完整的 frame buffer-read/modify/write 操作的, 该操作是否也是单独的一次操作呢? 还是分解为了几个步骤. 我理解上, 不需要 alpha blend 的 fragment 是不需要 frame buffer-read/modify 操作, 只需要 frame buffer-write, 这在整个渲染中占大多数, 那么硬件是否针对只需要 fb-write 的操作进行了优化? 相比完整的 fb-read/modify/write 操作更少的时钟周期? 你的理解是对的。需要blend的就要read, blend and then write. 不需要blend的就直接write了. 3. 因为都是在 on-chip memory 上操作的, 完整的 z-read/test/write 操作相比于完整的 fb-read/modify/write 操作哪个开销更小? 我理解上, fb-modify 操作比 z-test 操作要复杂, 是否会消耗更多的时钟周期? Color buffer 比z buffer操作复杂，消耗的时钟更多. 4. 在使用 alpha test 时, 因为在 fragment shader 阶段可能存在 discard 操作, 所以只有跑完完整的 fragment shader 才能够确定 fragment 是否需要保留, 这样会破坏 early-z. 那么硬件是如何处理带有 alpha test 的 fragment 的呢? 是发现 shader 中存在 discard 操作, 就对三角形投射到的整个 tile 关闭 early-z 开启 late-z; 还是先不管, 假设所有 fragment 都不会 discard, 在 fragment shader 阶段真正遇到 discard 操作后, 才对整个 tile(或者是单个fragment?) 进行补救操作? 如果发现fragment shader里面有discard或者其他修改z值的操作，early-z就不能用了，会用late-z. 驱动会检测这种情况，因为draw的时候已经知道当前绑定的fragment shader了，所以这些信息都是有的。不存在操作错误需要补救的情况。