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


> -Ken
> 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
>> context.
>> 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.
>> -Won
>> 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
>>>> example).
>>>> 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
>>>> sure.
>>>> 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.
>>>> Dean
>>>> -----------------------------------------------------------
>>>> 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