为什么我调整后的 OpenGL ES 2.0 模板在 iPad 上的帧速率如此之慢?
我修改了 Xcode 中的 OpenGL es 2.0 模板,将那个小盒子渲染为离屏纹理 (50*50),然后重置视口并使用全屏四边形将纹理渲染到屏幕上。但 FPS 下降幅度很大,出现明显的延迟(大约 10)。
我知道 iPad 在填充率方面存在问题,但这似乎不对。我只使用了一个 FBO,并在循环中更改了其纹理和渲染缓冲区之间的颜色附件。这有影响吗?
此外,我正在编写一个音频可视化工具(如 Windows Media Player 中的可视化工具),在 OpenGL 中编辑像素值。有什么建议吗?
代码如下:
//implement the texture in -(id)init
glGenTextures(1, &ScreenTex);
glBindTexture(GL_TEXTURE_2D, ScreenTex);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, texSize, texSize, 0, GL_RGB, GL_UNSIGNED_BYTE, nil);
//And in the render loop
//draw to the texture
glViewport(0, 0, texSize, texSize);
glBindTexture(GL_TEXTURE_2D, ScreenTex);
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, ScreenTex, 0);
glClear(GL_COLOR_BUFFER_BIT);
glVertexAttribPointer(ATTRIB_VERTEX, 2, GL_FLOAT, 0, 0, squareVertices);
glUniform1i(Htunnel, 0);
glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);
//switch to render to render buffer here
glViewport(0, 0, backingWidth, backingHeight);
glBindRenderbuffer(GL_RENDERBUFFER, colorRenderbuffer);
glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_RENDERBUFFER,colorRenderbuffer);
glClear(GL_COLOR_BUFFER_BIT);
glVertexAttribPointer(ATTRIB_VERTEX, 2, GL_FLOAT, 0, 0, texVertices);
glUniform1i(Htunnel, 1);
glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);
//vertex shader
void main()
{
if (tunnel==0) {
gl_Position = position;
gl_Position.y += sin(translate) / 2.0;
colorVarying = color;
}else {
f_texCoord = v_texCoord;
gl_Position = position;
}
}
//frag shader
void main()
{
if (tunnel==0) {
gl_FragColor = colorVarying;
} else {
gl_FragColor = texture2D(s_texture, f_texCoord);
}
}
I've modified the OpenGL es 2.0 template in Xcode to render that little box to an offscreen texture (50*50), then reset the view port and render the texture to the screen using a fullscreen quad. But the FPS dropped down so much that obvious lags were seen (about 10).
I know iPad has problems concerning fillrate, but this just doesn't seem right. I used only one FBO and changed its color attachment between texture and renderBuffer in the loop. Does this have any influence?
Besides, I was writing an audio visualizer (like the one in Windows Media Player) editing pixel values in OpenGL. Any suggestions?
here goes the code:
//implement the texture in -(id)init
glGenTextures(1, &ScreenTex);
glBindTexture(GL_TEXTURE_2D, ScreenTex);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, texSize, texSize, 0, GL_RGB, GL_UNSIGNED_BYTE, nil);
//And in the render loop
//draw to the texture
glViewport(0, 0, texSize, texSize);
glBindTexture(GL_TEXTURE_2D, ScreenTex);
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, ScreenTex, 0);
glClear(GL_COLOR_BUFFER_BIT);
glVertexAttribPointer(ATTRIB_VERTEX, 2, GL_FLOAT, 0, 0, squareVertices);
glUniform1i(Htunnel, 0);
glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);
//switch to render to render buffer here
glViewport(0, 0, backingWidth, backingHeight);
glBindRenderbuffer(GL_RENDERBUFFER, colorRenderbuffer);
glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_RENDERBUFFER,colorRenderbuffer);
glClear(GL_COLOR_BUFFER_BIT);
glVertexAttribPointer(ATTRIB_VERTEX, 2, GL_FLOAT, 0, 0, texVertices);
glUniform1i(Htunnel, 1);
glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);
//vertex shader
void main()
{
if (tunnel==0) {
gl_Position = position;
gl_Position.y += sin(translate) / 2.0;
colorVarying = color;
}else {
f_texCoord = v_texCoord;
gl_Position = position;
}
}
//frag shader
void main()
{
if (tunnel==0) {
gl_FragColor = colorVarying;
} else {
gl_FragColor = texture2D(s_texture, f_texCoord);
}
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
如果没有实际的代码,就很难找出瓶颈在哪里。但是,您可以通过使用 Instruments 定位原因来了解问题所在。
使用 OpenGL ES 仪器和新的 Time Profiler 创建一个新的 Instruments 文档。在 OpenGL ES 工具中,点击右侧的小检查器按钮,然后单击“配置”按钮。确保在结果页面上检查几乎每个日志记录选项,特别是 Tiler Utilization % 和 Renderer Utilization %。单击“完成”并确保在
选择要列出的统计信息
页面中选中这两个统计信息。在渲染过程中,针对 iPad 上的应用程序运行这组工具一段时间。停下来看看数字。如 Pivot 对我的问题的回答,如果您看到 OpenGL ES 工具中的 Tiler 利用率百分比达到 100%,则说明您受到了几何形状的限制(此处不太可能)。同样,如果渲染器利用率接近 100%,则填充率会受到限制。您还可以查看您记录的其他统计数据以了解可能发生的情况。
然后,您可以查看时间分析器结果,看看是否可以缩小代码中速度可能变慢的热点范围。找到列表顶部附近的项目。如果它们在您的代码中,请双击它们以查看发生了什么。如果它们位于系统库中,请通过右键单击符号名称并选择
向调用者收取库费用
或向调用者收取符号费用
来过滤结果,直到看到更相关的内容。 。在某些时候,您将开始在上面看到与 OpenGL 相关的符号,这应该会提示您了解 GPU 正在做什么。此外,您可能会惊讶地发现您自己的一些代码会减慢速度。
您可以尝试另一种 OpenGL ES 工具,但它是 Xcode 4 beta 的一部分,目前处于 NDA 状态。查看 WWDC 2010 会议视频,了解有关该内容的更多信息。
Without actual code, it will be difficult to pick out where the bottleneck is. However, you can get an idea of where the problem is by using Instruments to localize the causes.
Create a new Instruments document using both the OpenGL ES instrument and the new Time Profiler one. In the OpenGL ES instrument, hit the little inspector button on its right side, then click on the Configure button. Make sure pretty much every logging option is checked on the resulting page, particularly the Tiler Utilization % and Renderer Utilization %. Click Done and make sure that both of those statistics are checked in the
Select statistics to list
page.Run this set of instruments against your application on the iPad for a little while during rendering. Stop it and look at the numbers. As explained in Pivot's answer to my question, if you are seeing the Tiler Utilization % in the OpenGL ES instrument hitting 100%, you are being limited by your geometry (unlikely here). Likewise, if the Renderer Utilization % is near 100%, you are fill-rate limited. You can also look to the other statistics you've logged to pull out what might be happening.
You can then turn to the Time Profiler results to see if you can narrow down the hotspots in your code where things might be getting slowed down. Find the items near the top of the list there. If they are in your code, double-click on them to see what's going on. If they are in system libraries, filter the results until you see something more relevant by right-clicking on the symbol name and choosing either
Charge Library to Callers
orCharge Symbol to Caller
.At some point, you'll start seeing OpenGL-related symbols up there, which should clue you in to what the GPU is doing. Also, you may be surprised to find some of your own code slowing things down.
There's another OpenGL ES instrument that you might try, but it's part of the Xcode 4 beta and is currently under NDA. Check out the WWDC 2010 session videos for more about that one.