渲染到纹理和同步

我有一个使用标准渲染到纹理设置的跨平台代码库（iOS和Android）。每个帧（初始化之后），按以下顺序发生：渲染到纹理和同步

与纹理颜色附件的帧缓冲区的glBindFramebuffer
渲染一些东西
*
glBindFramebuffer默认帧缓冲区（0在Android，通常为2 iOS上）
那是颜色附着至第一帧缓存
渲染纹理使用结合纹理

在iOS和一些Android设备（包括模拟器）上，这可以正常工作，并且和预期的一样。在其他设备上（当前坐在运行4.0.4的Samsung Galaxy Note前面），使用该纹理的第二阶段渲染看起来很“跳跃”。其他动画在“跳跃”位相同的屏幕上继续以60 fps运行;我的结论是，对目标纹理的更改在第二次渲染过程中并不总是可见的。

为了测试这个理论，我在标有*的步骤中插入了glFinish（）。在所有设备上，现在，这具有正确的行为。有趣的是，glFlush（）不能解决问题。但是glFinish（）是昂贵的，我还没有看到任何文件表明这应该是必要的。

所以，这里是我的问题：当完成渲染到纹理以确保最近绘制的纹理在后续渲染过程中可用时，我该做些什么？

来源

2013-02-26 addaon

听起来不像合理的OpenGL行为。我不是ES专家，但我很确定ES（至少按规范）不会改变这种基本的同步行为。如果这不起作用，就不能依赖任何东西，就像在渲染之前依靠缓冲区写入的完成一样。这些操作没有其他显式同步机制，因此命令队列必须按顺序正确同步。 – 2013-02-28 09:20:22

我认为没有人观察到这一点？当然，很可能是设备/构建特定的，但这并不好玩。 – addaon 2013-02-28 18:22:03

你描述的代码应该没问题。

只要您使用单个上下文，并且不选择任何用于放宽同步行为的扩展（如EXT_map_buffer_range），那么每个命令都必须看起来像执行完全一样按照API以及您在从中读取纹理之前将渲染到纹理中的API用法。

鉴于此，您可能会遇到这些设备上的驱动程序错误。你能列出哪些设备遇到问题？您可能会找到常见的硬件或驱动程序。

来源

2013-03-04 03:43:29 Frogblast

渲染到纹理和同步

回答

相关问题