[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Blacklisted driver notification
- To: Ashley Gullen <firstname.lastname@example.org>
- Subject: Re: [Public WebGL] Blacklisted driver notification
- From: Ben Vanik <email@example.com>
- Date: Mon, 5 Mar 2012 18:12:48 -0800
- Authentication-results: mr.google.com; spf=pass (google.com: domain of firstname.lastname@example.org designates 10.50.197.135 as permitted sender) email@example.com; dkim=pass firstname.lastname@example.org
- Cc: "email@example.com" <firstname.lastname@example.org>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=lZ9Z4RCrqbvSu2Fasbt1k81cEKvPoNDhhPkf8iiOnMg=; b=KyXoMCNfHZv3Pk4jGpkMYPDXqKCCavejw/BEPHWH1hNOJxUKNxuYyEzFNJSI4hVU04 9yTddnbiFAatfVYyd5aoEhAFyg51rSi0h+1PPwlbgAXDy3/nTxfrp49XtqmOCxGdP8Va MFgthVikhKS1zF/2LRBB7NRrskgQ0rG09guvLnKzHEp7bkPNVcgyUprEgRA3DHNZIkWK W2kF6bOv6miocga0TFEVx2aRgvqz/eAf6bFc1A7filIsV+BQhNls9R5IYZcC6TxUCsDF lIzib0tHcqy1Muazsw65Ul3fvAZymF5vVf2+fZeTvA4vvBNgVpWwXy7Pj85dquVciXDl fkWw==
- In-reply-to: <CAABs73iF5iB-G1W3NYDSF9=jGr368Q4iL-b8GDHf67MMW7D_uw@mail.gmail.com>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <CAABs73iF5iB-G1W3NYDSF9=jGr368Q4iL-b8GDHf67MMW7D_uw@mail.gmail.com>
- Sender: email@example.com
I'd really like to see the browsers take care of prompting the user to update their drivers instead of making pages handle it. That takes care of any entropy bit issues (whether your drivers are out of date or not is potentially one more bit that can be used to identify you), simplifies things for people trying to build robust apps (one less case to handle/write copy for/translate/etc), and a browser can more intelligently direct users based on platform/vendor/etc, which are not reliably accessible to user pages. Steam does this for known bad drivers today, and it'd be a great service if the browsers did it (especially as more start to rely on GPU acceleration for their internals).
This prompting for upgrade of drivers is orthogonal to the software renderer, though. The user could of course deny any attempt the browser's make at upgrading, may be running on a pure software device (such as a remote desktop session), or may be unable to upgrade (no administrator access, no new non-blacklisted drivers available, etc) - in cases such as these the potential to run while blacklisted still exists. In some cases, the browser may not even be aware it is running in software - such as if the user is running on a device where the 'GPU' is emulated via mesa or some equivalent.
For this, my instinct would be to add a context creation attribute that specifies that no software fallback should be used. One still needs benchmarks/etc to know whether their performance would be acceptable, though, which diminishes the value. It'd make it easier to quickly block out all those who would certainly be too slow to run an app, however there are many old GPUs out there that would perform just as poorly and an end user still doesn't get a great experience. Users really need to be split into two categories: those who can run a piece of software (but be prevented due to driver issues/etc), and those who can't. Unfortunately where the dividing line lies is different for every application.
I think one thing we can push for is better support in the former case of blacklisted drivers for users who can run an app but are prevented by correctable issues - with better presentation by the browser to users as to why they are blacklisted and potential courses of action. This is something that could be made better today in all browsers without any changes to the spec - although asynchronous context creation could allow for an experience where users get to opt-in to software mode or unsafe drivers.
I don't currently see a bug in Chrome for this - maybe you could file one :) http://crbug.com
On Mon, Mar 5, 2012 at 5:50 PM, Ashley Gullen <firstname.lastname@example.org>
Firefox and Chrome implement driver blacklists for WebGL to prevent buggy drivers crashing the user's computer. I've read this is almost exclusively due to the drivers being out of date, so the user updating their drivers ought to fix the problem. More recently, I've read about Google and Mozilla making moves to add software-rendered WebGL implementations so users who have blacklisted drivers can still see content.
For real-time games, software renderers really don't make for a good playing experience on the common mid to low end machine. Poor performance is one of the most common criticisms we've heard with our HTML5 game engine, and it only comes from users who get software rendering. Some combinations of game and machine result in unplayable performance. Often if we get the user to update their driver then the GPU gets used and the game runs excellently. It's frustrating that the player may have a bad experience when they actually have the necessary hardware to run the game really well, but just lack a decent up-to-date driver.
While software rendering is one way to solve the problem, it seems to me that it's worth trying to solve it by getting users to update their drivers. This is more complicated for the user, but has a better end result. Browsers could prompt users to upgrade their driver when it's blacklisted, but it may be unnecessary depending on the content. There's no good way for the content itself to detect software rendering (and apparently the term is vague, since some GPUs use part software processing). However, if the fact that the user's graphics driver is on the browser's blacklist is exposed to the content (a simple flag), the content itself can issue some kind of notification if appropriate. This does not involve exposing any hardware details, does not need to determine a definition for software rendering, does not require running performance tests to try to detect software rendering, and could result in a much better end-user experience since they end up using the GPU they paid for.
Is this something that might be suitable for the WebGL spec?