Since you had more than 16 varyings, and your MacBook only had 16, the
code was working on that system for TWO reasons:
1) It had 16 varying vectors versus 8.
2) Since you had more than 16 varying variables in your code, it must have
been intelligently packing them into the available registers.
I don't know what specific improvement Chrome might do to ease this
situation in the future - but no matter what, you can't guarantee to have
enough varyings available. For example, if Chrome is forced to use DX9
(because it's running under WinXP perhaps) then DX9 itself limits you to
something like 10 varying vectors regardless of what the hardware actually
supports.
Since the smallest value for MAX_VARYING_VECTORS that WebGL allows is 8,
and the intelligent packing of your variables into the available registers
is an optimization that is not guaranteed by the specification, you really
shouldn't expect this code to work.
A fully "correct" WebGL application would:
a) Pack those 'float' varyings and the corresponding 'vec3' varyings into
a 'vec4' in shader code - and not rely on the compiler to spot that
optimization (because there is a good chance that it won't).
b) Check the value of MAX_VARYING_VECTORS and either:
* Eliminate some of the light sources when running on low-end hardware.
* Do multi-pass tricks to render more lights than you have varying's to
support.
For example, you could render (say) 4 lights the first time you draw the
geometry, then change the blend mode to SRC_ALPHA, ONE and render the
scene again with the second group of 4 lights. If you're smart, you can
cull the scene such that only objects that are lit by those additional
lights are drawn in the second pass. Done efficiently, you can render
hundreds of lights with little additional overhead in situations where
most of the lights only illuminate one or two objects in the scene.
-- Steve
I'd suggest trying with a more recent version of Chrome/ANGLE. A number
of limits have been bumped up in ANGLE since then.
(That said, I expect you'll still run out of varyings though).
The current limits (on SM3 hardware) are:
MAX_FRAGMENT_UNIFORM_VECTORS 221
MAX_VARYING_VECTORS 10
MAX_VERTEX_ATTRIBS 16
MAX_VERTEX_TEXTURE_IMAGE_UNITS 16 0
MAX_VERTEX_UNIFORM_VECTORS 1024 254
Hope this helps,
Daniel
On 2011-02-27, at 2:18 PM, Stephen Bannasch wrote:
At 5:07 PM -0800 2/25/11, Gregg Tavares (wrk) wrote:
What Steve said.
You're using 17 varyings. WebGL is only required to support 8. (see
OpenGL ES 2.0 spec section 6.19)
Since you're only varying vec3s an amazing GL driver might be able to
optimize that to 13 varyings but I wouldn't count on it and even that
is over the minimum.
You might want to check that at startup.
gl.getParameter(gl.MAX_VARYING_VECTORS);
That appears to have been the problem.
I created an html page that displays the various webgl maximums up here:
http://visual-demos.dev.concord.org/seasons/webgl-maximums.html
These differences between my MacBook Pro and the HP 425 we are using in
the classroom jumped out at me:
MacBook Pro HP 425*
-----------------------------------------------------------
MAX_FRAGMENT_UNIFORM_VECTORS 1024 16
MAX_VARYING_VECTORS 16 8
MAX_VERTEX_ATTRIBS 16 12
MAX_VERTEX_TEXTURE_IMAGE_UNITS 16 0
MAX_VERTEX_UNIFORM_VECTORS 1024 128
* HP 425 with Windows 7:
Renderer: ATI Mobility Radeon HD 4250 Graphics
Vendor: ATI Technologies Inc.
Memory: 256 MB
Version: 3.2.9752 Forward-Compatible Context
Shading language version: 1.50
---
Daniel Koch -+- daniel@transgaming.com
Senior Graphics Architect -+- TransGaming Inc. -+- www.transgaming.com