在Nexus 10/Android 4.2.2上缓慢的glTexSubImage2D性能(三星Exynos 5 w/ malit - t604)

时间:2023-02-09 11:24:05

I have an Android app that decodes video into yuv420p format then renders video frames using OpenGLES. I use glTexSubImage2D() to upload y/u/v buffer to GPU then do a YUV2RGB conversion using shader. All EGL/OpenGL setup/rendering code is native code.

我有一个Android应用程序,将视频解码成yuv420p格式,然后使用OpenGLES渲染视频帧。我使用glTexSubImage2D()将y/u/v缓冲区上传至GPU,然后使用着色器进行YUV2RGB转换。所有EGL/OpenGL设置/呈现代码都是本机代码。

Now I am not saying there is no problem with my code, but considering the same code is running perfecting fine on iOS (iPad/iPhone), Nexus 7, Kindle HD 8.9, Samsung Note 1 and a few other cheap chinese tablets (A31/RockChip 3188) running Android 4.0/4.1/4.2. I would say it's less likely my code is wrong. On those devices, glTexSubImage2D() uses less than 16ms to upload a SD or 720P HD texture.

现在我并不是说我的代码没有问题,但是考虑到相同的代码在iOS (iPad/iPhone)、Nexus 7、Kindle HD 8.9、三星Note 1和其他一些便宜的中国平板(A31/RockChip 3188)上运行Android 4.0/4.1/4.2。我认为我的代码不太可能是错的。在这些设备上,glTexSubImage2D()使用不到16毫秒的时间上传一个SD或720P高清纹理。

However, on Nexus 10, glTexSubImage2D() it takes about 50~90ms for a SD or 720P HD texture which is way too slow for a 30fps or 60fps video.

然而,在Nexus 10上,glTexSubImage2D()需要大约50~90ms的SD或720P高清纹理,这对于30fps或60fps的视频来说太慢了。

I would like to know

我想知道。

1) if I should pick a different texture format (RGBA or BGRA). Is there a ways to detect which is the best texture format used by a GPU?

1)如果我选择不同的纹理格式(RGBA或BGRA)。有没有一种方法可以检测GPU使用的最佳纹理格式?

2) if there is a feature that is 'OFF' on all other SOCs but set to 'ON' on Exynos 5. For example, the automatic MIPMAP generation option. (I have it off, btw)

2)如果在所有其他soc上有一个“OFF”的特性,但在Exynos 5上设置为“on”。例如,自动的MIPMAP生成选项。(我把它拿下来了,顺便说一下)

3) if this is a known issue of Samsung Exynos SOC - I can't find a support forum for Exynos CPU

3)如果这是三星Exynos SOC的已知问题——我找不到Exynos CPU的支持论坛。

4) Is there any option I need to set when configure the EGL surface? like, transparency, surface format, etc? (I have no idea what I am talking about)

4)在配置EGL表面时是否需要设置选项?比如,透明度,表面格式等等?(我不知道我在说什么)

5) It could mean GPU is doing an implicit format conversion but I checked GL_LUMINANCE is always used. Again it works on all other platform.

5)它可能意味着GPU正在进行隐式格式转换,但是我检查了GL_LUMINANCE。它同样适用于所有其他平台。

6) anything else?

6)还有吗?

My EGL config:

我的EGL配置:

const EGLint attribs[] = {
    EGL_SURFACE_TYPE, EGL_WINDOW_BIT,
    EGL_RENDERABLE_TYPE, EGL_OPENGL_ES2_BIT,
    EGL_BLUE_SIZE, 8,
    EGL_GREEN_SIZE, 8,
    EGL_RED_SIZE, 8,
    EGL_NONE
};

Initial setup:

初始设置:

glTexImage2D(GL_TEXTURE_2D, 0, GL_LUMINANCE, ctx->frameW, ctx->frameH, 0, GL_LUMINANCE, GL_UNSIGNED_BYTE, NULL); /* also for U/V  */

subsequent partial replacement:

随后的部分替换:

glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, ctx->frameW, ctx->frameH, GL_LUMINANCE, GL_UNSIGNED_BYTE, yBuffer); /*also for U/V */

I am trying to render video at ~30FPS or ~60FPS at SD or 720P HD resolution.

我正尝试在SD或720P高清分辨率下渲染~30FPS或~60FPS的视频。

3 个解决方案

#1


6  

This is a known driver issue that we have reported to ARM. A future update should fix it.

这是我们报道过的一个已知的驱动因素。将来的更新应该会修复它。

#2


1  

EDIT Status update

编辑状态更新

We've now managed to reproduce slow upload conditions for one path on the public firmware, which you are possibly hitting, and this will be fixed in the next driver release.

我们现在已经成功地复制了公共固件上的一个路径的缓慢上载条件,您可能会遇到这种情况,这将在下一次驱动程序发布中修复。

If you double-buffer texture IDs (e.g. frame N = ID X, N+1 = ID Y, N+2 = ID X, N+3 = ID Y, etc) for the textures you are uploading to it should help avoid this on the current firmware.

如果你将纹理ID(例如,frame N = ID X, N+1 = ID Y, N+2 = ID X, N+3 = ID Y,等等)添加到它的纹理中,你将会在当前的固件中避免这一点。

Thanks, Iso

谢谢,Iso

#3


1  

I can confirm this has been fixed in Android 4.3 - I'm seeing a performance increase by a factor of 2-3 with RGBA format and by a factor of 10-50 with other texture formats over Android 4.2.2. These results apply for both glTexImage2D and glTexSubImage2D. (Can't add comments yet so I had to put this here)

我可以确认这是固定在Android 4.3 -我看到一个性能增加了一个因素2-3和RGBA格式和一个10-50和其他纹理格式超过Android 4.2.2。这些结果应用于glTexImage2D和glTexSubImage2D。(还不能添加注释,所以我必须把它放在这里)

EDIT: If you're stuck with 4.2.2, you could try using RGBA texture instead, it should have better performance (3-10x or so with larger power-of-two texture sizes).

编辑:如果你使用的是4.2.2,你可以尝试使用RGBA纹理,它应该有更好的性能(3-10x或者更大的两个纹理大小)。

#1


6  

This is a known driver issue that we have reported to ARM. A future update should fix it.

这是我们报道过的一个已知的驱动因素。将来的更新应该会修复它。

#2


1  

EDIT Status update

编辑状态更新

We've now managed to reproduce slow upload conditions for one path on the public firmware, which you are possibly hitting, and this will be fixed in the next driver release.

我们现在已经成功地复制了公共固件上的一个路径的缓慢上载条件,您可能会遇到这种情况,这将在下一次驱动程序发布中修复。

If you double-buffer texture IDs (e.g. frame N = ID X, N+1 = ID Y, N+2 = ID X, N+3 = ID Y, etc) for the textures you are uploading to it should help avoid this on the current firmware.

如果你将纹理ID(例如,frame N = ID X, N+1 = ID Y, N+2 = ID X, N+3 = ID Y,等等)添加到它的纹理中,你将会在当前的固件中避免这一点。

Thanks, Iso

谢谢,Iso

#3


1  

I can confirm this has been fixed in Android 4.3 - I'm seeing a performance increase by a factor of 2-3 with RGBA format and by a factor of 10-50 with other texture formats over Android 4.2.2. These results apply for both glTexImage2D and glTexSubImage2D. (Can't add comments yet so I had to put this here)

我可以确认这是固定在Android 4.3 -我看到一个性能增加了一个因素2-3和RGBA格式和一个10-50和其他纹理格式超过Android 4.2.2。这些结果应用于glTexImage2D和glTexSubImage2D。(还不能添加注释,所以我必须把它放在这里)

EDIT: If you're stuck with 4.2.2, you could try using RGBA texture instead, it should have better performance (3-10x or so with larger power-of-two texture sizes).

编辑:如果你使用的是4.2.2,你可以尝试使用RGBA纹理,它应该有更好的性能(3-10x或者更大的两个纹理大小)。