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

Re: [Public WebGL] Context creation flag proposal: "failIfMajorPerformanceCaveat"

Perhaps we could come up with a definition based on "drastically slower than a native app making equivalent OpenGL calls", or perhaps to be less subjective, "requiring additional steps than a native app making equivalent OpenGL calls would demand"? In other words, if the browser is introducing additional steps to the render pipeline (e.g. readback for a "software compositor" as opposed to "direct rendering"), then fail to create the context. Perhaps the flag could be "failIfNotNative"? However software compositors like SwiftShader don't seem to fall under this definition. Perhaps then we could also fail to create if the first choice device is on the browser blacklist. For example, Chrome only uses Swiftshader if the system has a blacklisted device/driver, so Swiftshader can be clearly identified as a secondary or fallback renderer.

So, defining a "native context" as:
- comparable rendering pipeline to a native app
- first choice has not been blacklisted

Then if "failIfNotNative" is set to true, fail to create the context if:
- the browser will perform additional rendering steps that a native app would not typically perform, such as readback every frame
- the first choice renderer has been blacklisted

This is as objective a definition as I can come up with. I haven't defined all the terms I've used, but hopefully it still makes sense. It would also appear to solve the problem we face with our game engine. It would allow us to choose WebGL knowing it will be comparable to a GPU-accelerated native app, and fall back to canvas2d if not.

Alternatively, a simple and objective flag would be "failIfBlacklisted". This would indicate to fail to create a context if either the WebGL support or compositor/layers support for the primary device is subject to a blacklist. So this would imply both WebGL and composition are hardware accelerated.


On 17 September 2013 17:49, Kenneth Russell <kbr@google.com> wrote:

On Mon, Sep 16, 2013 at 7:16 PM, Rémi  Arnaud <jsremi@gmail.com> wrote:
> This is interesting, but it is too much of a black box, wich can't be clearly defined nor  conformance tested.
> Why not instead be explucit about the configuration and let the application decide?

See below.

On Tue, Sep 17, 2013 at 5:31 AM, Ben Houston <ben@exocortex.com> wrote:
> I guess I am just used to specifically asking for no software
> rendering when creating contexts in DirectX and this seems to fall
> into that case.  Couldn't that be an alternative that is based around
> requiring specific capabilities such as (1) no software rendering or
> (2) no software compositing or asking for (3) a pure hardware context
> be clearer and easier to use and implement?  I can imagine just
> starting with one or two of these three flags.  This proposed flag
> seems like a way of capturing a specific capability query (what is
> required to make Google Maps work well) into a single flag, but that
> isn't a general approach even if it solves the Google Maps issue.
> Different applications of WebGL will have different WebGL bottlenecks.

In a face-to-face meeting last week an option like
"failIfSoftwareComposited" was proposed as an alternative to this one,
and there was pushback because the browser vendor didn't want to call
their implementation software composited. There was a difference of
opinion about what "software composited" meant. There was also
pushback against simply blacklisting WebGL where the rendering
pipeline couldn't be fully GPU accelerated.

In the past the possibility of enumerating "performance caveats" was
considered, but there are too many to enumerate them all in the spec.
As a couple of examples, some GPUs used to fall back to software
vertex processing, sometimes only when operations like vertex texture
fetch was used. The list of caveats grew rapidly, and ultimately there
would be too many for any individual application to make use of,
besides avoiding using WebGL if the list had any entries in it.

Again, as much as I would like for the failIfMajorPerformanceCaveat
flag to be unnecessary, it's been identified as a requirement by the
Maps team, and it's important to address use cases discovered by real
world applications.


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