[Public WebGL] debugging a shaderLinkError

Daniel Koch [email protected]
Mon Feb 28 05:44:20 PST 2011


Steve Baker is exactly correct.

AFAIK, Chrome always uses ANGLE by default under windows, and as pointed out, the DX9 API only supports 10 varying vectors, even if more are supported by the hardware.

ES 2.0 actually has a very well specified packing algorithm for packing and counting varyings.  See the GLSL ES v100 specification, Appendix A, Section 7 (p108).  This is the algorithm that is implemented by ANGLE.  Unless the browsers are also re-packing varyings behind the scene, you are very likely not getting this behaviour when using Desktop GL (since Desktop GL doesn't have explicit packing rules), and will likely run into problems when running on a true ES2 implementation. 

ANGLE did have a bug where varying packing wasn't being done quite correctly.  This bug probably still exists in Chrome 9, although it is fixed in ToT ANGLE.

Hope this helps,
Daniel

On 2011-02-28, at 8:19 AM, [email protected] wrote:

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

---
                        Daniel Koch -+- [email protected]
Senior Graphics Architect -+- TransGaming Inc.  -+- www.transgaming.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20110228/d15054d8/attachment.html>


More information about the public_webgl mailing list