758323 - WebGL doesn't work on Galaxy S due to too many active contexts (?)

Status: RESOLVED DUPLICATE of bug 759225

(Core :: Graphics: CanvasWebGL, defect)

Description

[Jeff Muizelaar [:jrmuizel]]

http://people.mozilla.com/~jmuizelaar/implementation-tests/precision.html

throws an error and about:support reports the renderer as false.

Comment 1

[Jeff Muizelaar [:jrmuizel]]

I get the same problem on an ASUS transformer.

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I have a transformer and have an interest in this! I'll take a glance.

Comment 3

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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

Comment 4

[Jeff Muizelaar [:jrmuizel]]

I have a Transform TF101 with Android 3.2.1

Comment 5

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Attachment: screenshot on Galaxy S

Comment 6

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Ok, I'll grab your Transformer on Monday, Jeff.

Comment 7

[Mark Callow]

WebGL is blacklisted for me in Fennec 14.0a2 on my Xoom tablet even with webgl.force-enabled set to true. In Fennec 13 on the same device, it works, albeit slowly due to the read-back for compositing. Here is the output of about:support.


  Application Basics

        Name
        Fennec

        Version
        14.0a2

        User Agent
        Mozilla/5.0 (Android; Tablet; rv:14.0) Gecko/14.0 Firefox/14.0a2

        Profile Directory

          Open Directory

        Enabled Plugins

          about:plugins

        Build Configuration

          about:buildconfig

        Crash Reports

          about:crashes

        Memory Use

          about:memory

  Extensions

        Name

        Version

        Enabled

        ID

  Important Modified Preferences

      Name

      Value

        browser.startup.homepage_override.mstone
        14.0a2

        extensions.lastAppVersion
        14.0a2

        network.cookie.prefsMigrated
        true

        webgl.force-enabled
        true

  Graphics

        Adapter Description
        Model: 'MZ604', Product: 'HUBKDDI', Manufacturer: 'Motorola', Hardware: 'stingray'

        Vendor ID
        stingray

        Device ID
        MZ604

        Driver Version
        15

        WebGL Renderer
        false

        GPU Accelerated Windows
        0. Blocked for your graphics card because of unresolved driver issues.

        AzureBackend
        skia

        Couldn't get device attachments for device.

        Couldn't get device attachments for device.

        Couldn't get device attachments for device.

  JavaScript

        Incremental GC
        1

  Library Versions

        Expected minimum version

        Version in use

        NSPR
        4.9
        4.9

        NSS
        3.13.4.0 Basic ECC
        3.13.4.0 Basic ECC

        NSS Util
        3.13.4.0
        3.13.4.0

        NSS SSL
        3.13.4.0 Basic ECC
        3.13.4.0 Basic ECC

        NSS S/MIME
        3.13.4.0 Basic ECC
        3.13.4.0 Basic ECC

Should I file a separate bug for this?

Comment 8

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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.

Comment 9

[Mark Callow]

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.

Comment 10

[Benoit Jacob [:bjacob] (mostly away)]

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.

Comment 11

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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.

Comment 12

[Jeff Muizelaar [:jrmuizel]]

This: https://github.com/android/platform_frameworks_base/commit/1b4ecc63c4eceb7c125d4e749fd5f747d99d6ec6

seems to suggest this is possible.

Comment 13

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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.

Comment 14

[Jeff Muizelaar [:jrmuizel]]

(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.

Comment 15

[Benoit Jacob [:bjacob] (mostly away)]

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 ([e-mail]).
[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 ([e-mail]).
[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

Comment 16

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 17

[Martijn Wargers (dead)]

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?

Comment 18

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

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/

Comment 19

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Going to call this fixed by bug 759225, then.

Comment 20

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

removing qawanted as this bug is duplicated/fixed