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

Re: [Public WebGL] Disable software rendering

On Sun, Jun 19, 2011 at 10:33 PM, Glenn Maynard <glenn@zewt.org> wrote:
> On Mon, Jun 20, 2011 at 1:03 AM, Gregg Tavares (wrk) <gman@google.com>
> wrote:
>> 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?

As Gregg points out, WebGL only supports non-mipmapped NPOT at the
moment, assuming the underlying driver supports that (it's required by
spec, either GL or GL ES 2).  The browser isn't aware whether the
driver implements it in HW or SW.

> 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...)
> --
> Glenn Maynard

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