[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Public WebGL] Context creation flag proposal: "failIfMajorPerformanceCaveat"
A flag like this would be very useful. I don't think that needing a CPU readback is necessarily a sufficient condition to fail with the flag, that's just a constant overhead per composited frame which might be small compared to all the other things the WebGL app is doing, but running on software emulation would definitely be a good reason to fail if the flag is set.
From: email@example.com [firstname.lastname@example.org] On Behalf Of James Darpinian [email@example.com]
Sent: Tuesday, September 17, 2013 6:05 AM
To: firstname.lastname@example.org; email@example.com
Cc: public webgl
Subject: Re: [Public WebGL] Context creation flag proposal: "failIfMajorPerformanceCaveat"
"Major" would, by necessity, be implementation defined. However I believe the guideline "drastically slower than a native app making equivalent OpenGL calls" can make the decision unambiguous in almost all cases.
Unfortunately exposing more information about the user's GPU has been proposed and shot down repeatedly due to complexity and user privacy concerns. I don't believe there's a perfect solution to this problem which is simple and respects user privacy while remaining completely non-subjective. Some kind of compromise solution is necessary to get past this impasse. By accepting some subjectivity in the definition of "major" we can make progress, even if it's not the ideal solution for everyone.
On Mon, Sep 16, 2013 at 6:32 PM, Ben Houston <firstname.lastname@example.org<mailto:email@example.com>> wrote:
This is a subjective condition. What is major? Major may not mean the same thing to different people and it depends on what webgl features one is using and which are degraded. Instead one should just query for what is actually being done, is there gpu read back for software composting or other such things going on. This would be more specific and less ambiguous. Also sometimes gpu read back is fast such as for integrated graphics. Thus even this is not indicative of performance. I think this is generally problematic and ambiguous.
Sent from my phone.
On Sep 16, 2013 7:49 PM, "James Darpinian" <firstname.lastname@example.org<mailto:email@example.com>> wrote:
I'd like to propose a new context creation flag to help WebGL apps make better decisions about performance tradeoffs: "failIfMajorPerformanceCaveat".
The problem we're facing is that WebGL sometimes offers drastically reduced performance compared to what you would expect given the hardware it's running on. For example, if a machine has a GPU that is blacklisted for WebGL, the browser might use a software renderer that is much slower. Or, if the browser is using a software compositor, it might have to readback the WebGL framebuffer into system memory before drawing it to the screen.
For apps that aren't full-screen or otherwise don't stress performance too much, these reduced-performance modes can work fine, so we don't want to simply disable WebGL in these cases. However, many apps don't work well in these reduced-performance modes. Apps that have a fallback rendering path (e.g. a 2D canvas mode) might prefer to use it instead of a reduced-performance WebGL context, but right now there's no way for apps to tell when WebGL is in a reduced-performance mode (vs. the user's machine just generally being slow).
"failIfMajorPerformanceCaveat" would default to false. When "failIfMajorPerformanceCaveat" is true, context creation would fail if WebGL is known to be drastically slower than a native app making equivalent OpenGL calls.
This means, for example, that context creation would fail if the browser has to readback the WebGL framebuffer into system memory before drawing it to the screen. Context creation would also fail if the browser is using a software renderer due to the user's GPU being blacklisted for WebGL. In these cases apps could switch to a fallback rendering path, or try again with "failIfMajorPerformanceCaveat:false" and the knowledge that they should use a low-resolution mode.
Thoughts? Alternate naming suggestions?
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: