[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Disable software rendering
On Mon, Jun 20, 2011 at 1:03 AM, Gregg Tavares (wrk) <email@example.com>
WebGL requires NPOT support at the same level as OpenGL ES 2.0 (ie, non-mipped) so browsers can't just turn off NPOT support as it would not meet the spec.
Are WebGL implementations emulating NPOT and other features when they aren't supported by hardware?
It should generally be possible for the implementation to tell when this is happening, whether it's the WebGL implementation doing it or drivers, and it'd certainly be useful to be able to tell whether various features are considered--by some reasonable definition--to have acceptable performance or whether they'll trigger a known slow path.
This won't always be possible, since you can hit a slow path in drivers without any reliable way of detecting it, but exposing what's known is better than nothing at all, if these issues are common. This is particularly the case if WebGL itself is emulating features (because they're required); clearly the implementation knows if it itself is doing this.
Figuring out which rendering features are acceptable on various hardware has always been a nightmare for developers, and it's even worse with WebGL: you have an extra abstraction layer between you and the hardware to introduce slow paths. You're also more limited: even if you have the resources to do so, you can't bulk-test your hardware on lots of consumer hardware to create support tables (defining which rendering features to use on which hardware), as I'm certain many commercial PC games do: the hardware identifiers are hidden from you by WebGL, so you can't even tell what GPU vendor you're running on.
Trying to guess which rendering features are fast through timing is painfully brittle, and anything that can reduce the need for it seems like a win.
(As an aside, although I know the rationale for not exposing the video card vendor/model, I wonder at how meaningful it is--I'm guessing you can narrowly pinpoint that information trivially by testing the performance of a bunch of different features and correlating the results...)