渲染循环 - 最大并行化
Render loop - maximum parallelization
下面是一个 UML 序列图，显示了我对库中游戏循环的理解的处理时间 libGDX。我认为其他所有游戏库都应该采用相同的架构。我不确定我是否理解正确。
理论上 CPU 和 GPU 并行工作。当 CPU 等待 GPU 完成缓冲区更改时，这使其成为一个串行进程。
如何让我的游戏循环并行工作或者我的理解有误？
现在图像我们想要并行化并且 GPU 比 CPU 慢并且 CPU 在 GPU 渲染时继续下一帧。我们有第二个线程等待 GPU 完成。 GPU 完成后，将计算下一张图像。 OpenGL 状态更改和绘制命令现在去哪里了？ GPU 现在很忙。这使我得出结论，我遗漏了一些东西。
编辑：
罗斯·范德建议：
我在第二张图中看到的一个问题可能是你出错的地方是 GPU 似乎 return 到 CPU 线程 2，即使它是 CPU线程 1 将数据发送到 GPU 并开始阻塞它。交换前缓冲区和后缓冲区的两个引用不会改变哪个线程在 GPU 上阻塞。
我觉得事件的顺序更应该是这样的：CPU线程1将数据从前台缓冲区发送到GPU进行渲染。同时，线程 2 正在写入后台缓冲区。当 GPU 完成时，线程 1 可以自由交换前后缓冲区（假设线程 2 已完成），然后将数据发送到 GPU。线程 2 在 GPU 工作时再次写入后台缓冲区。
更新：取自https://github.com/libgdx/libgdx/wiki/Threading
Any graphics operations directly involving OpenGL need to be executed
on the rendering thread. Doing so on a different thread results in
undefined behaviour. This is due to the OpenGL context only being
active on the rendering thread. Making the context current on another
thread has its problems on a lot of Android devices, hence it is
unsupported.
下面是一个 UML 序列图，显示了我对库中游戏循环的理解的处理时间 libGDX。我认为其他所有游戏库都应该采用相同的架构。我不确定我是否理解正确。
现在图像我们想要并行化并且 GPU 比 CPU 慢并且 CPU 在 GPU 渲染时继续下一帧。我们有第二个线程等待 GPU 完成。 GPU 完成后，将计算下一张图像。 OpenGL 状态更改和绘制命令现在去哪里了？ GPU 现在很忙。这使我得出结论，我遗漏了一些东西。
编辑：
罗斯·范德建议：
我在第二张图中看到的一个问题可能是你出错的地方是 GPU 似乎 return 到 CPU 线程 2，即使它是 CPU线程 1 将数据发送到 GPU 并开始阻塞它。交换前缓冲区和后缓冲区的两个引用不会改变哪个线程在 GPU 上阻塞。 我觉得事件的顺序更应该是这样的：CPU线程1将数据从前台缓冲区发送到GPU进行渲染。同时，线程 2 正在写入后台缓冲区。当 GPU 完成时，线程 1 可以自由交换前后缓冲区（假设线程 2 已完成），然后将数据发送到 GPU。线程 2 在 GPU 工作时再次写入后台缓冲区。
更新：取自https://github.com/libgdx/libgdx/wiki/Threading
Any graphics operations directly involving OpenGL need to be executed on the rendering thread. Doing so on a different thread results in undefined behaviour. This is due to the OpenGL context only being active on the rendering thread. Making the context current on another thread has its problems on a lot of Android devices, hence it is unsupported.