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

Re: [Public WebGL] Disable software rendering

On Sun, Jun 19, 2011 at 9:44 PM, stephen white <steve@adam.com.au> wrote:

On 20/06/2011, at 1:30 PM, Mark Callow wrote:
> I thought the OP was talking about apps taking alternative measures on finding that some non-OpenGL ES 2.0-feature it wants to use is not available. This has nothing to do with the underlying GL driver.
> Perhaps my interpretation is coloured by the fact that I do not know of any OpenGL ES 2.0 "GPU" that falls back to software nor any full software implementation that is used in mobile or embedded products.

A clarifying example. My ATi Radeon X1600 Mobile CPU requires powers of two textures. If it doesn't get POT, then it will becomes very slow while my CPU works hard (= software rendering). I'm asking for this fallback to be turned off, so that it will just fail if it's not going to run on the GPU.

I'm not sure what you're asking for

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.

They could blacklist the card but if the only issue is NPOT textures make it go slow that would be blacklisting a card that works fine for apps with only POT textures of which I'm sure there are plenty.

Different GPUs have very different perf characteristics. For example I did some work on a Nexus-One 3d library and found that on that each uniform used by a fragment shader cuts the speed in half which meant the standard *collada* phong shader with emissive, ambient, diffuse, specular, power, light color, was way too slow. Just drawing a single fullscreen quad with that shader ran at 10fps.

We had to cut the shaders down to simplest thing possible.

It basically seems these issue are something apps are going to have to deal with. In your case, either start using POT textures, or have an option for POT textures or time it and just tell the user 'sorry, you need better hardware.'  I know that's not the solution you want to hear but the difference between low-end and high-end is 2 maybe 3 orders of magnitude.


I'm not concerned about "which context is better" though it's an interesting idea. I just want it to be "this code is written for the GPU, and it must run only on the GPU or provide errors". It would be great to know what the errors are, or to get the features, but I understand that's another discussion.

In practical terms, as an every day experience by normal people, I find that having web pages with WebGL on them is increasingly thrashing my machine and becoming a real issue. I'm ahead of the curve because I load more WebGL pages than usual, but this will become more common.


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