Wydajność slow glTexSubImage2D na Nexusie 10/Androidzie 4.2.2 (Samsung Exynos 5 w/Mali-T604)

Mam aplikację na Androida, która dekoduje wideo do formatu yuv420p, a następnie renderuje klatki wideo za pomocą OpenGLES. Używam glTexSubImage2D() do przesłania bufora y/u/v do GPU, a następnie wykonaj konwersję YUV2RGB za pomocą modułu cieniującego. Cały kod instalacji/renderowania EGL/OpenGL jest natywnym kodem.Wydajność slow glTexSubImage2D na Nexusie 10/Androidzie 4.2.2 (Samsung Exynos 5 w/Mali-T604)

Nie mówię, że nie ma problemu z moim kodem, ale biorąc pod uwagę ten sam kod działa perfekcyjnie na iOS (iPad/iPhone), Nexus 7, Kindle HD 8.9, Samsung Note 1 i kilka innych tanich chińskich tablety (A31/RockChip 3188) z systemem Android 4.0/4.1/4.2. Powiedziałbym, że jest mniej prawdopodobne, że mój kod jest błędny. Na tych urządzeniach glTexSubImage2D() używa mniej niż 16 ms, aby przesłać teksturę SD lub 720P HD.

Jednak na Nexusie 10, glTexSubImage2D(), potrzeba około 50 ~ 90 ms dla tekstury SD lub 720P HD, która jest o wiele za wolna dla wideo 30 klatek na sekundę lub 60 klatek na sekundę.

Chciałbym wiedzieć

1) Jeśli miałbym wybrać inny format tekstury (RGBA lub BGRA). Czy istnieje sposób na wykrycie, który z najlepszych formatów tekstury jest wykorzystywany przez GPU?

2) jeśli jest funkcja wyłączona dla wszystkich innych SOC, ale ustawiona na "WŁ." Na Exynos 5. Na przykład, automatyczna opcja generowania MIPMAP. (Mam go wyłączyć, btw)

3) jeżeli jest to znany problem z Samsung Exynos SOC - Nie mogę znaleźć forum wsparcia dla procesora Exynos

4) Czy istnieje opcja muszę ustawić kiedy konfigurujesz powierzchnię EGL? jak, przejrzystość, format powierzchni, itp? (Nie mam pojęcia, o czym mówię)

5) Mogłoby to oznaczać, że GPU dokonuje niejawnej konwersji formatu, ale ja sprawdziłem, czy GL_LUMINANCE jest zawsze używany. Znowu działa na wszystkich innych platformach.

6) coś jeszcze?

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

konfiguracja początkowa:

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

późniejsze zamienne częściowy:

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

usiłuję renderowanie wideo na ~ 30FPS lub ~ 60fps w SD lub rozdzielczość 720P HD.

Źródło

2013-03-22 Yi Wang

Rozważmy 'SurfaceTexture' dla Androida> 11: http://developer.android.com/reference/android/graphics/SurfaceTexture.html – Jave

Dzięki, ale nadal chciałby dowiedzieć się, dlaczego glTexSubImage2D() jest wolna od I nie chcesz utrzymywać wielu ścieżek kodu - działa tylko dla wszystkich z wyjątkiem Exynos –

Zaobserwowaliśmy ten sam (lub bardzo podobny) problem i zgłosiliśmy go na https://code.google.com/p/android/issues/detail?id = 53135, ale wydaje się, że jest to regresja między 4.2.1 a 4.2.2 na podstawie naszych testów. – chuoling

Jest to znany problem ze sterownikami, który zgłosiliśmy firmie ARM. Przyszła aktualizacja powinna to naprawić.

Źródło

2013-03-23 00:13:28

jest to regresja z wersji 4.2 lub 4.2.1? Jeśli tak, przywrócę wersję oprogramowania i kontynuuję programowanie ... –

@ romain-guy - Czy masz pojęcie, kiedy ta aktualizacja się skończy? Moja firma ma dokładnie ten sam problem. – BlueVoodoo

Czy ustalone będzie w 4.2.3 lub 5.0? –

EDIT status

Mamy teraz udało się odtworzyć powolne warunki przesyłania dla jednej ścieżki na firmware publicznego, które są ewentualnie uderzenie, a ten zostanie rozwiązany w następnej wersji sterowników.

Jeśli posiadasz podwójne identyfikatory tekstury (np. Klatka N = ID X, N + 1 = ID Y, N + 2 = ID X, N + 3 = ID Y, itp.) Dla tekstur, które do niego przesyłasz powinno pomóc uniknąć tego na aktualnym oprogramowaniu.

Dzięki, Iso

Źródło

2013-03-23 00:31:17 solidpixel

zobacz moje edytowane pytanie –

Bardzo docenione. Tak więc, aby potwierdzić, przesyłasz półpłaszczyznową powierzchnię YUV jako dwie 8-bitowe tekstury luminancji, jedną z ośmiobitową Y i jedną z dwoma 4-bitowymi wartościami U/V umieszczonymi w 8-bitowym kanale. – solidpixel

Hmm Nie mam wystarczającej liczby punktów rep, aby skomentować odpowiedź Romaina, więc opublikuję ją tutaj. Nie jest to regresja między 4.2 a 4.2.1, więc cofnięcie nie pomoże. – solidpixel

mogę potwierdzić ten został naprawiony w Androidzie 4.3 - Widzę wzrost wydajności o współczynnik 2-3 z formacie RGBA i przez współczynnik wynoszący 10-50 z innymi formaty tekstur nad systemem Android 4.2.2. Te wyniki dotyczą zarówno glTexImage2D, jak i glTexSubImage2D. (Nie mogę dodawać komentarzy, więc musiałem umieścić to tutaj)

EDYCJA: Jeśli utkniesz w 4.2.2, możesz spróbować użyć tekstury RGBA zamiast tego, powinna ona mieć lepszą wydajność (3-10x lub więcej z większymi rozmiarami tekstury o mocy dwóch).

Źródło

2013-08-05 07:46:33

Wygląda na to, że wciąż nie jest wystarczająco szybki. Moja aplikacja zaczęła używać glTexSubImage2D z teksturą RGBA, a od tego wydania przenosi się na Nexusa 10. Nie ulega awarii na żadnym innym systemie Android! – HRJ

Wydajność slow glTexSubImage2D na Nexusie 10/Androidzie 4.2.2 (Samsung Exynos 5 w/Mali-T604)

Odpowiedz

Powiązane problemy