[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Disable software rendering



I think there is some confusion here due to the brevity of the original post causing lack of clarity.

I thought the OP was talking about apps taking alternative measures on finding that some non-OpenGL ES 2.0-feature it wants to use is not available. This has nothing to do with the underlying GL driver.

Perhaps my interpretation is coloured by the fact that I do not know of any OpenGL ES 2.0 "GPU" that falls back to software nor any full software implementation that is used inÂmobile or embedded products.

Under this interpretation, I would say it isÂthe application's responsibility to ensure that any alternative it provides for a missing extension has decent performance.

Regards

-Mark


Software rendering for WebGL is a difficult decision, because:
 * sometimes it's better to do slow software rendering than nothing;
 * sometimes it's worse, because if the WebGL context just failed, the page would default to e.g. Canvas2D rendering that would (in some cases) work better on non-accelerated systems. See Angry Birds, three.js, etc.

Maybe we need to add a WebGL context creation attribute "IHaveAGoodCanvas2DFallbackSoJustFailIfWebGLIsLikelyToBeSlowerHere". Native English speakers please advise on the name. Note that I didn't suggest "requireHardwareAcceleration" because we already discussed that that wasn't what was actually the most useful to know.

Benoit

----- Original Message -----
It's your driver that fell back to software mode, not webgl/browser.
Since webgl/browser side doesn't know when the underlying driver
switches between sw/hw, so it's either webgl is totally blocked, or
not blocked.

If you are using chrome, what's the about:gpu page say? We might want
to block your GPU in general.

On Thu, Jun 16, 2011 at 8:56 PM, stephen white <steve@adam.com.au>
wrote:
As I have a nobile GPU that is strictly OpenGL ES 2.0 only, there
are a number of demos that fall back to software rendering. These
demos absolutely kill my machine, and it takes me up to 2 minutes to
find and kill the page that is causing such wild thrashing.

As the result is nearly always unusable, with basically a "picture"
that changes every 10 seconds or so, I'm not seeing that the
fallback to software rendering helps here. Is there a way to have
only hardware rendering otherwise an error with no fallback?

--
Âsteve@adam.com.au


-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------


-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------
-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------
begin:vcard
fn:Mark Callow
n:Callow;Mark
org:HI Corporation;Graphics Lab, Research & Development
adr:Higashiyama 1-4-4, Meguro-ku;;Meguro Higashiyama Bldg 5F;Tokyo;;153-0043;Japan
email;internet:callow_mark@hicorp.co.jp
title:Chief Architect
tel;work:+81 3 3710 9367 x228
tel;fax:+81 3 5773 8660
x-mozilla-html:TRUE
url:http://www.hicorp.co.jp,  http://www.mascotcapsule.com
version:2.1
end:vcard