Tried latest b2g build on sgs2 and found that crystal-scull is ~7FPS Disabled remote-frame (IPC) for this application, and it still slow. Checked with gdb and found that most of the time we spend in glCopyTexSubImage2D call.
Created attachment 645173 [details] [diff] [review] Single EGL Image, no copy With this patch I have ~40 FPS rate very smooth and fast on SGS2/Mali. Do we have any other plans for pushing webgl rendering without using glCopyTexSubImage2D?
Do we have anyone on b2g who can contact the gfx vendors and ask my CopyTexSubImage is so slow? I can ping nvidia at least, but they're not the hardware that's involved here. Oleg, the single egl image patch here removes the copy, but means that we'd get rendering happening to the same surface that the compositor is reading from, right? (I know it's just for testing, but making sure that I understand what the failure is :) Good idea though to give us an idea of what the perf impact is.
We have ARM Mali driver contacts. Mailing you privately.
(In reply to Oleg Romashin (:romaxa) from comment #1) > Created attachment 645173 [details] [diff] [review] > Single EGL Image, no copy > > With this patch I have ~40 FPS rate very smooth and fast on SGS2/Mali. > Do we have any other plans for pushing webgl rendering without using > glCopyTexSubImage2D? Bug 766366.
Depends on: 766366
Summary: Crystal Scull is very slow on SGS2 with non-remote iframe → Crystal Skull is very slow on SGS2 with non-remote iframe
This should be solved by 716859. This issue is only on some hardware+drivers where glCopyTexSubImage is slow. Official B2G hardware should be unaffected.
Oleg, do you still see this with b2g 1.3 or 1.4?
No this is not an issue anymore for SGS2 with latest b2g
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.