[Public WebGL] debugging a shaderLinkError

[email protected] [email protected]
Mon Feb 28 05:19:10 PST 2011

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

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

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_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 -+- [email protected]
> Senior Graphics Architect -+- TransGaming Inc.  -+- www.transgaming.com

You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl

More information about the public_webgl mailing list