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

Re: [Public WebGL] option for suggesting "low power" mode at context creation

On Sep 26, 2012, at 3:14 PM, Kenneth Russell <kbr@google.com> wrote:

I most like the idea of a single flag like "preferLowPower" defaulting
to false. I'm concerned that if WebGL's default is changed to use the
low-power GPU that we will unpleasantly surprise developers who were
already expecting the highest performance from their applications on
dual-GPU systems. Developers concerned about saving battery life will
change their context creation code.

While list of priorities would be more general, it also seems
difficult to document its semantics.

Perhaps "preferPowerSavingsOverPerformance" to be very clear what it is you're giving up?


On Wed, Sep 26, 2012 at 3:03 PM, Dean Jackson <dino@apple.com> wrote:

On 27/09/2012, at 7:47 AM, Kenneth Russell <kbr@google.com> wrote:

I'm personally in favor of adding another entry in the context
creation flags, rather than adding a new callback API to choose one of
a number of supported configurations. I have some experience with
exposing this sort of chooser API in the Java binding to OpenGL, and
it's both complex to use and implement in a cross-platform manner.
Among other issues, it becomes necessary to ask the system what its
preferred choice is from within the chooser callback.

The list of priorities seems like a general enough mechanism which
still leaves some flexibility in how it can be implemented. It also
seems mostly orthogonal to other discussions such as specifying
minimum and maximum bit depths per color channel.

So it seems that we're generally in favour of extra flags in the context creation parameters. Great. We just need to decide on a way to do it.

The options so far are:

- list of predefined priorities. HighPerformance, PowerSaving, ???

- a single flag to indicate preferring low power mode (less performance). Systems will probably default to high power in this case (but are not required to)

- a single flag to indicate preferring higher power mode (higher performance). Systems will probably default to low power in this case (but are not required to)

I kind of like the last option, although it could mean a significant hit to existing WebGL content (but a potential battery saving). The list of priorities is a lot more general, but I feel it could be slightly confusing to authors (they effectively need to know what all the possible options mean, even the ones that haven't been invented yet).

Again, to be clear, these are just hints, and have less priority than other flags like antialiasing.



On Wed, Sep 26, 2012 at 12:38 PM, Won Chun <wonchun@google.com> wrote:
Speaking as a WebGL user, I think this is a good idea. There have been other
"how do I control the context I get" kind of discussions, and I think the
appropriate solution is a layered API.

1) Keep getContext as a nice, standard and simple way to get an accelerated

2) Acknowledge that it is impossible to anticipate what is important for
every WebGL app, and provide a more conventional enumerate/choose model so
that applications can enforce their own priorities how they wish. Unlike
desktop GL, there would probably have to be standard sets of context forms,
to reduce the amount of info leakage.


On Wed, Sep 26, 2012 at 3:26 PM, Florian Bösch <pyalot@gmail.com> wrote:

I like the low/high power selection a lot better than solving the specific
problem with an extra call. Note I'm running webglstats, which does also
need to create a context to test some more things, which should work on
integrated and discrete regardless, so kicking discrete into gear everytime
you visit a page embedding the webglstats tracker would be... overkill.

There are other uses of the setting though. I'm not familiar how OSX makes
the GPU selection exactly. But if applications could influence it, they
could, in theory, offer this as a choice to users. On OSX you can override
this with some app, but most people don't have that gfx selector app. For
instance, a presentation toolkit based on webgl would likely want to use
integrated GPUs when possible. Most of my demos would likely like to get
discrete GPUs if possible.

On Wed, Sep 26, 2012 at 9:15 PM, Dean Jackson <dino@apple.com> wrote:

This topic came up at the F2F meeting. It's not clear if this is a
significant/temporary issue or not, and there wasn't any consensus on
approach, so I'm sending this to get broader feedback.

Currently, in WebKit (or Apple's port of it), WebGL will always use a
discrete GPU on an OS X dual-GPU system. This follows the system behaviour,
where any OpenGL application gets the discrete GPU unless it explicitly asks
otherwise (and even then it is not guaranteed to get the integrated card,
nor stay on it). The idea is that if you're doing OpenGL, you're probably
wanting the highest performance possible.

WebGL has no way to indicate one way or the other. This came up recently
in a complaint that an older version of the popular _javascript_ library
Modernizr was detecting WebGL support by creating a context (and thus firing
up the discrete GPU). It then deleted the context (thus reverting to the
integrated GPU). This was on a page that had no other WebGL code - it was
just detecting the possibility.

It might be nice if at WebGL context creation time you could pass in some
flag indicating that you are not concerned with raw performance, or that the
system can opt into a lower power mode if possible. For example, it could be
that your WebGL only draws once to create a background image for the page. A
game that wants to run at 60fps would not request this mode.

canvasEl.getContext("webgl", { suggestLowPower: true });

NOTE: I have no good ideas for the naming of anything here

This is just a hint. If you requested antialiasing and low-power, the
desire for AA would win (if only the discrete GPU supported it, for

Another suggestion was a list of priorities:

canvasEl.getContext("webgl", { priorities: ["performance", "poweruse"])

(where the priority values would be constants defined in the spec, not
arbitrary strings)

Yet another option would be to always use low-power mode on these system
configurations. We don't really have control over if/when the system will
decide to automatically upgrade though, so some benchmarks would suffer.

And yet another option is to avoid the initial problem by having a method
to indicate whether WebGL is supported: canvasEl.supportsContext("webgl").
I've proposed this to HTML5 (or HTML.next) and the reaction is an almost
50/50 split. Obviously, you'd still need to create a context to know for

At the moment I'm actually tempted to turn on low-power mode for all
dual-GPU systems on OS X and see what the performance fallout is.


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

~Chris Marrin