[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 macbooks there's a gfx control app that overrides OSX GPU selection. I don't think a global control should be part of the browser. A web developer can easily offer the user a choice (like SD vs. HD) and set the hint accordingly. If anything the global control over power usage belongs into the operating systems settings, right next to disabling wifi, bluetooth, airplane mode etc.

On Thu, Sep 27, 2012 at 11:23 PM, Matt McLin <mr.mclin@gmail.com> wrote:
 Having "low power" be the default would help the WebGL-enabled Internet to be mobile-friendly out of the box

This comment provided a kind of epiphany for me, and changes my mind, and makes me think that this entire discussion is headed in a bad direction.  As a developer I like to have control over how the target platform handles my code, and being able to specify a low-power hint is nice for this.  However, as an end-user of a mobile device, there are times when I want the best performance I can get out of it, even if I have to recharge 1 hour later, and other times (maybe a long airplane flight) where I would prefer to extend the battery life as long as possible.  In other words, I would prefer that the end user has control over power/performance concerns.

So what does this mean towards the browser & web apps?  I think it means that there does need to be a way for the browser to influence the performance considerations made by the graphics device, but that the direction of this influence should come from the end user, not the web app.  Now what could be very interesting is that the web app has a way of exposing this control in its own way (e.g., via an HTML5 GUI), and in this way both the web app & end user have control, but in general there would need to be a simple way to adjust this independently from the web app.

I think the original post from Dean was really about avoiding a [temporary] problem with some current gfx devices & drivers that were consuming more power than they need to to handle a very simple task.  As these devices & drivers become smarter about power usage, that issue goes away by itself.

Just my 2 cents, and good luck to you all.

Regards, Matt 

On Thu, Sep 27, 2012 at 2:01 PM, Kenneth Russell <kbr@google.com> wrote:

One other issue needing consideration. Let's assume that the
"preferLowPowerToHighPerformance" flag is added to the
WebGLContextAttributes dictionary, and that
WebGLRenderingContext.getContextAttributes() returns the correct value
for the flag. (In other words, if the flag is set to true during
getContext, and the machine has two GPUs, and the implementation
supports low-power mode, then getContextAttributes() will return true
for the flag as well; otherwise, false.)

On dual-GPU Mac OS machines, at least, it will then be possible to get
WebGL to run on either the integrated or discrete GPU, and detect
which one is being used in _javascript_.

In order to keep implementations honest, it will be necessary to
change the WebGL conformance suite to run all of the tests twice, once
on the integrated GPU and once on the discrete GPU. Further, there are
currently many more test failures on Mac OS when running the
conformance suite on integrated GPUs than on discrete GPUs. This means
adding a low-power flag now will delay the point at which the next
snapshot of the WebGL conformance tests could be successfully passed.
There had been some hope that a new snapshot could be taken soon,
after triaging the existing test failures on top of tree.

Dean, Chris, any thoughts on this issue?


On Thu, Sep 27, 2012 at 10:22 AM, Chris Marrin <cmarrin@apple.com> wrote:
> On Sep 27, 2012, at 1:54 AM, Mark Callow <callow.mark@artspark.co.jp> wrote:
> On 12/09/27 11:27, Florian Bösch wrote:
> I don't think so. Dual GPU systems that can switch seamlessly are certainly
> somewhat of an oddity. It's certainly true that certain segments of the
> market will always aim for single GPU systems. However, if you want to
> combine very low power consumption but also powerful graphics in one system,
> dual GPU solutions will remain the solution for the forseeable future. The
> reason being that: 1) integrated graphics cannot compete performance wise
> with discrete graphics. This will always be true.
> 2) Discrete graphics cannot yet work as power effectively as simple
> integrated graphics. It is likely this will remain so for a long time due to
> this being a hard thing to do.
> 3) The need to combine both low power graphics and high power graphics in
> one system will not vanish into thin air.
> You are not giving the hardware designers much credit and nor apparently
> noticing the progress made by the latest low-power high-performance GPUs for
> mobile devices. I'm quite sure technologies for powering off unused parts of
> devices will migrate from CPUs to GPUs.
> There is no "need to combine both low power graphics and high power graphics
> in one system." There *is* a need for high-performance graphics that
> consumes low power. The current dual-GPU solution is a hack.
> No matter how good, no hardware can consistently guess your preferences.
> Turning on a low power flag might ignore the anti-aliasing flag because it
> uses a lot of power. Or might not because the GPU can do it without much
> additional battery drain. There are many other features future GPUs could
> turn on or off to sacrifice performance or quality for the sake of battery
> life. I think a flag like this gives the author the ability to make some
> very mobile friendly content.
> Regards
>     -Mark
> --
> 注意:この電子メールには、株式会社エイチアイの機密情報が含まれている場合が有ります。正式なメール受信者では無い場合はメール複製、
> 再配信または情報の使用を固く禁じております。エラー、手違いでこのメールを受け取られましたら削除を行い配信者にご連絡をお願いいたし ます.
> NOTE: This electronic mail message may contain confidential and privileged
> information from HI Corporation. If you are not the intended recipient, any
> disclosure, photocopying, distribution or use of the contents of the
> received information is prohibited. If you have received this e-mail in
> error, please notify the sender immediately and permanently delete this
> message and all related copies.
> -----
> ~Chris Marrin
> cmarrin@apple.com

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