http://people.mozilla.com/~jmuizelaar/implementation-tests/precision.html throws an error and about:support reports the renderer as false.
I get the same problem on an ASUS transformer.
I have a transformer and have an interest in this! I'll take a glance.
Which Transformer are you using? It works fine for me on a WiFi Transformer with ICS 4.0.3. get.webgl.org works, your precision test page returns: Vertex: float high/medium/low - 128 128 23 int high/medium/low - 128 128 0 fragment: float high - 0 0 0 float medium - 33 33 13 float low - 1 1 8 int high - 0 0 0 int medium - 33 33 0 int low - 33 33 0
I have a Transform TF101 with Android 3.2.1
Ok, I'll grab your Transformer on Monday, Jeff.
Looking into this on Jeff's transformer running Honeycomb, we're getting EGL_BAD_ACCESS from eglMakeCurrent when we create the context and try to make it current. This can happen if the context is current on another thread -- which isn't the case, because we just created it -- OR if we're about to exceed the maximum number of contexts current on any threads for the given API. The latter seems pretty likely; we have at least the surfaceview GL context current on the compositor thread, so we would at least need to be able to render to 2 GL contexts from 2 different threads at the same time (and maybe more than 2; I'm not sure if we have GL contexts current elsewhere). It works fine on ICS, so it's entirely possible that this was just not implemented on some of these devices pre-ICS.
What I am reporting in comment #7 is clearly a different bug. Among the differences my problem happens with ICS. So I've opened bug #759225 for it.
In Bug 759221 I'm hitting the same issue as in comment 8 with the Tegra board. It would be very useful to find a solution as that blocks enabling canvas tests on our android test slaves.
I don't think there is a solution here; it seems to be a limitation of the drivers. We should reach out to nvidia and just get them to 100% confirm this, and then get some ICS slaves for bug 759221.
This: https://github.com/android/platform_frameworks_base/commit/1b4ecc63c4eceb7c125d4e749fd5f747d99d6ec6 seems to suggest this is possible.
That which is possible? That seems to just ensure that only one context is current app-wide at any point. That'd be bad for us, not to mention annoying, as we'd need to synchronize GL usage with the compositor and whatever else thread. Not worth it, IMO.
(In reply to Vladimir Vukicevic (:vlad) from comment #13) > That which is possible? That seems to just ensure that only one context is > current app-wide at any point. That'd be bad for us, not to mention > annoying, as we'd need to synchronize GL usage with the compositor and > whatever else thread. Not worth it, IMO. Sorry, it seems to confirm the hypothesis that some devices have the limitation of having only one active context.
cjones thinks that this problem only happens with 2 threads with in a single process, not with 2 different processes: 14:34] <bjacob> cjones: the problem is these devices don't allow having *two* GL contexts current at the same time, each on a different thread [14:34] <bjacob> cjones: but with OMTC GL, that becomes a requirement for WebGL [14:34] <cjones> ah, we hit a similar problem on nexus s GB [14:35] <cjones> it's not an issue for us because any webgl code will run in content processes [14:35] <bjacob> cjones: see https://bugzilla.mozilla.org/show_bug.cgi?id=759221#c10 , with links to other relevant bugs [14:35] <firebot> Bug 759221 nor, --, ---, nobody, NEW, Enable canvas tests on Android [14:35] --> sheppy has joined this channel (sheppy@moz-F39D62DA.dhcp.kgpt.tn.charter.com). [14:35] <bjacob> cjones: oh you mean that webgl contexts will be owned by different _processes_ than the compositor? [14:35] <cjones> correct [14:36] <bjacob> cjones: what about the home screen? i thought that used webgl already? [14:36] <fabrice> not anymore [14:36] <bjacob> fabrice: ah ok [14:36] <cjones> home screen will be in a content process [14:36] <cjones> most likely [14:37] <bjacob> cjones: and are you confident that this problem is only with threads and won't happen with processes? i.e. what if a device only allows 1 GL context *period* ? [14:37] --> pauljt has joined this channel (ptheriault@moz-D34B6DF8.lns20.syd6.internode.on.net). [14:37] <cjones> that would break android [14:37] <cjones> generally we only rely on stuff that needs to work on android [14:37] <cjones> anything else has generally proven to be broken [14:37] <-- willyaranda has left this server (Quit: Sleeping…). [14:37] <bjacob> cjones: how would it? i thought android only allowed 1 app on foreground at a time [14:38] <cjones> any 3d game has to have a separate GL context from the compositor [14:38] <cjones> android apps don't directly composite to HW gb [14:38] <cjones> *fb [14:38] <bjacob> cjones: oh you mean android has a compositor that runs all the time alongside the app being run [14:38] <bjacob> ok [14:38] <cjones> correcty [14:38] <cjones> *correct [14:38] <bjacob> ok, interesting [14:38] <bjacob> so [14:39] <-- glogiotatidis_ has left this server (Ping timeout). [14:39] <bjacob> does that mean that you intend to do cross-process-WebGL very soon? do you plan to do cross-process texture sharing, or remoting of GL calls? [14:39] <-- clee has left this server (Quit: clee). [14:39] <-- Irina has left this server (Quit: Irina). [14:39] <cjones> cross-process sharing of render target [14:40] <bjacob> cjones: using gralloc? [14:40] <cjones> more specifically though, if this problem is limited to tegra2, we don't support that currently so it's not an issue for b2g [14:40] <philikon> marshall_law: no need to ask for review again if i already r+'ed [14:40] <cjones> bjacob, right
The number of contexts we use is much lower now, and we don't use any share groups. It would be good to check if this bug still happens.
Current trunk build on the Asus TF101, using Honeycomb doesn't throw any errors on http://people.mozilla.com/~jmuizelaar/implementation-tests/precision.html Naoki, can you check this if this is fixed on the Samsung Galaxy S?
Galaxy S doesn't seem to be throwing errors on current trunk (6/18/2012) on : http://people.mozilla.com/~jmuizelaar/implementation-tests/precision.html and get.webgl.org works as well. MineGl and GnomeGL works from http://paulrouget.com/mwc-demos/webgl/
Going to call this fixed by bug 759225, then.
removing qawanted as this bug is duplicated/fixed