Slow glTexSubImage2D Leistung auf Nexus 10/Android 4.2.2 (Samsung Exynos 5 w/Mali-T604)

Ich habe eine Android-App, die Video in yuv420p Format decodiert dann Video-Frames mit OpenGLES rendert. Ich benutze glTexSubImage2D() um y/u/v Puffer auf GPU hochzuladen und dann eine YUV2RGB Konvertierung mit Shader durchzuführen. Der gesamte EGL/OpenGL-Setup-/Rendering-Code ist systemeigener Code.Slow glTexSubImage2D Leistung auf Nexus 10/Android 4.2.2 (Samsung Exynos 5 w/Mali-T604)

Jetzt sage ich nicht, es gibt kein Problem mit meinem Code, aber in Anbetracht der gleichen Code läuft perfekt auf iOS (iPad/iPhone), Nexus 7, Kindle HD 8.9, Samsung Note 1 und ein paar andere billige Chinesisch Tablets (A31/RockChip 3188) mit Android 4.0/4.1/4.2. Ich würde sagen, dass es weniger wahrscheinlich ist, dass mein Code falsch ist. Auf diesen Geräten verwendet glTexSubImage2D() weniger als 16 ms zum Hochladen einer SD- oder 720P-HD-Textur.

Allerdings benötigt glTexSubImage2D() auf Nexus 10 etwa 50 ~ 90ms für eine SD- oder 720P HD-Textur, die für ein 30fps oder 60fps Video viel zu langsam ist.

Ich mag

1) wissen, ob ich ein anderes Textur-Format (RGBA oder BGRA) holen soll. Gibt es eine Möglichkeit zu erkennen, welches das beste Texturformat ist, das von einer GPU verwendet wird?

2) wenn es eine Funktion gibt, die bei allen anderen SOCs "AUS" ist, aber auf Exynos 5 auf "EIN" gesetzt ist. Zum Beispiel die automatische MIPMAP-Generierungsoption. (Ich habe das Ganze abzurunden, btw)

3), ob dies ein bekanntes Problem von Samsung Exynos SOC ist - ich nicht ein Support-Forum für Exynos CPU

4) Gibt es eine Möglichkeit, die ich brauche finden einstellen wenn die EGL-Oberfläche konfiguriert wird? wie, Transparenz, Oberflächenformat, etc? (Ich habe keine Ahnung worüber ich spreche)

5) Es könnte bedeuten, dass GPU eine implizite Formatkonvertierung durchführt, aber ich habe überprüft, dass GL_LUMINANCE immer verwendet wird. Wieder funktioniert es auf allen anderen Plattformen.

6) noch etwas?

Meine EGL config:

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 
};

Ersteinrichtung:

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

anschließende Teilersatz:

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

ich bei ~ 30 FPS oder ~ 60 FPS auf SD zu machen Video versuche oder 720P HD-Auflösung.

Quelle

2013-03-22 Yi Wang

Betrachten Sie die "SurfaceTexture" für Android> 11: http://developer.android.com/reference/android/graphics/SurfaceTexture.html – Jave

Danke, aber ich möchte immer noch herausfinden, warum glTexSubImage2D() ist langsam seit ich möchte keinen Mehrfachcodepfad beibehalten - funktioniert für alle außer Exynos –

Wir haben das gleiche (oder sehr ähnliche) Problem beobachtet und es unter https://code.google.com/p/android/issues/detail?id gemeldet = 53135, aber es scheint eine Regression zwischen 4.2.1 und 4.2.2 basierend auf unseren Tests zu sein. – chuoling

Dies ist ein bekanntes Treiberproblem, das wir ARM gemeldet haben. Ein zukünftiges Update sollte es beheben.

Quelle

2013-03-23 00:13:28

ist dies eine Regression von 4.2 oder 4.2.1? Wenn ja, werde ich die Firmware-Version zurücksetzen und die Entwicklung fortsetzen ... –

@ romain-guy - Hättest du eine Idee, wann dieses Update veröffentlicht wird? Meine Firma hat genau das gleiche Problem. – BlueVoodoo

Ist das behoben in 4.2.3 oder 5.0 zu sein –

EDIT Status-Update

Wir haben es geschaffen, jetzt für einen Weg auf den öffentlichen Firmware langsame Upload-Bedingungen zu reproduzieren, die Sie möglicherweise schlagen werden, und dies wird in der nächsten Treiber-Release behoben werden.

Wenn Sie Textur-IDs (z. B. Rahmen N = ID X, N + 1 = ID Y, N + 2 = ID X, N + 3 = ID Y usw.) für die Texturen, die Sie hochladen, doppelt puffern sollte helfen, dies auf der aktuellen Firmware zu vermeiden.

Danke, Iso

Quelle

2013-03-23 00:31:17 solidpixel

siehe meine bearbeitete Frage –

Sehr geschätzt. Um also zu bestätigen, dass Sie eine semi-planare YUV-Oberfläche als zwei 8-Bit-Luminanztexturen hochladen, eine mit 8-Bit-Y und eine mit zwei 4-Bit-U/V-Werten in einen 8-Bit-Kanal. – solidpixel

Hmm Ich habe nicht genug Rep-Punkte, um Romains Antwort zu kommentieren, also poste ich sie hier. Nein, das ist keine Regression zwischen 4.2 und 4.2.1, also hilft das Zurückrollen nicht. – solidpixel

ich dieses Problem behoben wurde in Android 4.3 bestätigen kann - ich bin eine Leistungssteigerung um den Faktor 2-3 mit RGBA-Format und um einen Faktor von 10-50 mit anderen zu sehen Texturformate über Android 4.2.2. Diese Ergebnisse gelten für glTexImage2D und glTexSubImage2D. (Kann noch keine Kommentare hinzufügen, also musste ich das hier setzen)

EDIT: Wenn Sie mit 4.2.2 festgefahren sind, könnten Sie stattdessen versuchen, RGBA Textur zu verwenden, sollte es eine bessere Leistung (3-10x oder so mit größeren Zweierpotenzgrößen.

Quelle

2013-08-05 07:46:33

Offenbar ist es immer noch nicht schnell genug. Meine App begann mit glTexSubImage2D mit einer RGBA-Textur und ab dieser Version stürzt es auf Nexus 10 ab. Es stürzt nicht auf anderen Android-Geräten ab! – HRJ

Slow glTexSubImage2D Leistung auf Nexus 10/Android 4.2.2 (Samsung Exynos 5 w/Mali-T604)

Antwort

Verwandte Themen