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

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



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.

-Ken


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