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

Re: [Public WebGL] another proposal to temporarily expose some device/driver information only when really needed

I think this is a great idea and I'm desperate for something like this.  Our engine implements both a WebGL and Canvas 2D renderer, and currently the Canvas 2D renderer is never used in Chrome 18 due to Swiftshader.  I am keen to fall back to Canvas 2D instead of using Swiftshader but there is no way to do that.

I don't think "slow" is a good term to use because it seems to me to be subjective.  Suppose someone has a weird system with a fully-hardware 2006 graphics card and a modern 8-core 2012 CPU.  Swiftshader might be faster than the GPU.  Which is "slow"?

I'd rather one of these terms, or both:
"no_gpu": no graphics-specific hardware chip is present.  This does not mean "software rendering".  A GPU using part software rendering still counts as a GPU.
"blacklisted": a device is present but was blacklisted (not used) due to known issues.  A Swiftshader WebGL context would say "blacklisted", because it *could* have used a GPU, but didn't because the driver was unstable or whatever.  In that case I'd want to ditch the blacklisted WebGL context and fall back to Canvas 2D.  Alternatively a message could be issued indicating the user needs to upgrade their driver or hardware.  Considering Firefox's stats show something like 50% of users have a blacklisted driver, I think it's essential to expose this information.

Note they don't mean the same thing, if you have no graphics hardware then no_gpu is true and blacklisted is false (a non-existent graphics card is not blacklisted), whereas a blacklisted GPU sets no_gpu to false and blacklisted to true.

If there is the possibility of multiple GPUs with different advisories then I suppose they should be associated with the context that you actually got.

I would then myself define 'slow' as:
var slow = advisory.no_gpu || advisory.blacklisted;
which I think is what most people's definition really is, but is not enforced or suggested by the browser, it's the developer's interpretation.

Some people have expressed concern that this will make the weird system with the 2006 graphics card and 2012 CPU run slower than if it had used the CPU.  My answer is: I don't care.  If there is a GPU there I want to use it, because it is probably more power-efficient than the CPU, which is important on mobile.  Also, a good software renderer like Swiftshader will burn up all your CPU cores, which is a little obnoxious - lots of people complained about how Flash would always "use 100% CPU" for a simple advert when looking at a simple web page; people notice if they have a noisy fan; other apps struggle for CPU time; in apps like games, logic is fighting with rendering for CPU time, so there's less parallelism.  So in short you're system is designed wrong (why install a graphics chip which has the overall effect of *slowing down* graphics rendering??) and I would say the software rendering is still "wrong" even if it's faster because it's *inefficient*, which is a slightly different meaning to "slow".

Ashley Gullen

On 2 May 2012 16:47, Benoit Jacob <bjacob@mozilla.com> wrote:

----- Original Message -----
> On Tue, May 1, 2012 at 11:22 AM, Benoit Jacob <bjacob@mozilla.com>
> wrote:
> >
> > Hi,
> >
> > We've discussed several times before, and rejected, proposals to
> > expose device/driver info to content. Here's another, different
> > proposal.
> >
> > 1. add a new function --- let's call it getDeviceAdvisories() ---
> > that can be called without a WebGL context, as it will be meant to
> > be called before getContext. For example, it could be a method on
> > the window object.
> >
> > 2. getDeviceAdvisories() returns a JS Object, which may be null. By
> > default, the browser will return a null object, which should be
> > interpreted as "nothing special to say about this device".
> >
> > 3. Now if browser developers get reports from application
> > developers that a certain device is causing them trouble, browser
> > vendors can quickly update this object to add some properties that
> > are characteristic of this device. For example, if a driver is
> > known to have very slow VTF, the object returned would have a
> > boolean property,
> >
> >    vtf_slow = true
> >
> > We could also imagine
> >
> >    slow = true
> >
> > for software-only WebGL renderers, as many apps that have a good
> > Canvas2D or even non-Canvas fallback would prefer it over a slow
> > WebGL implementation.
> >
> > It should even be possible to update it within 24 hours without
> > requiring a software update, as is typically done for blocklist
> > updates. I imagine that JSON would be a convenient format for
> > browsers to store this information.
> I propose using URIs for capability profile predicates.
> If you dislike the idea of using absolute URIs, I propose using
> relative URI references like "#vtf_slow" and "#slow" with a default
> base URI at khronos.org.

I have no experience with that whatsoever, so no opinion. I just want to make one point: any solution that relies on parsing strings is probably bad. I'm not saying that the URIs approach relies on parsing strings, but I do see strings in the above paragraph, so I'm saying that just in case.

Even if somehow that particular kind of string parsing can't be gotten wrong by applications, it remains that any string parsing will be more complicated to use than just

 if (advisories.slow)


> This same host profile facility is probably useful to a wide variety
> of nouveau browser APIs. Integrating with an extant standard or host
> profile system would be preferable to creating a new profile system.
> I
> believe most logical assertions regarding Web hosts, resources, and
> clients should attempt to use the federated namespace structure of
> that is now ubiquitous.
> David
> > 4. Whenever the device is no longer a major cause of trouble, e.g.
> > if a work-around has been implemented since, the device advisory
> > can be dropped.
> >
> >
> > Some reasons why I like this proposal while I was against the
> > vendor/renderer/version strings:
> >
> >  * Any exposed information is directly useful. By contrast,
> >  UA-string-like solutions rely on applications to correctly parse
> >  them and correctly make use of that information, which is a
> >  well-known cause of artificial portability problems on the Web.
> >  * The default is to expose no information.
> >  * If a browser always returns null, that's totally cool, apps will
> >  just assume no driver issue then.
> >  * The amount of information exposed is minimal (I don't think we'd
> >  expose more than 2 bits given that the OS name is already
> >  exposed, compared to about 10 bits for the renderer/version
> >  strings).
> >  * The information exposed pertains to specific testable issues, so
> >  it could be obtained fairly easily anyway by running some WebGL
> >  code exposing the corresponding issue.
> >
> >
> > Why do I care about this now? Partly from conversations with Web
> > developers, and partly because browsers are getting software
> > fallbacks for WebGL (Chrome already has it now), and I am
> > concerned that silently falling back to software rendering for
> > WebGL is going to break applications that have a WebGL and a
> > non-WebGL renderer and make the naive assumption that if WebGL is
> > available then it is necessarily the better choice.
> >
> >
> > Opinions?
> > Benoit
> >
> > -----------------------------------------------------------
> > 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