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

Re: [Public WebGL] Weird shader compiler error - casting a mat4 into a mat3.





On Tue, Mar 15, 2011 at 10:57 AM, Kenneth Russell <kbr@google.com> wrote:

On Tue, Mar 15, 2011 at 5:47 AM,  <steve@sjbaker.org> wrote:
>> On Sun, Mar 13, 2011 at 10:50 PM, Benoit Jacob <bjacob@mozilla.com> wrote:
>>>
>>> ----- Original Message -----
>>>> I have an odd vertex shader compiler error that's happening on just
>>>> one
>>>> of my machines.
>>>>
>>>> The shader is utterly minimal (it renders a sky box) - and the error
>>>> message is cryptic:
>>>>
>>>> error C0201: unsupported version 120
>>>>
>>>> ...the problem appears to be that I'm trying to cast a 4x4 matrix into
>>>> a
>>>> 3x3 matrix.
>>>
>>> It seems that GLSL ES 1.0 doesn't have a mat3(mat4) constructor, as far
>>> as I can see. Either this warning is telling you that you need to add
>>> '#version 120' at the beginning of your shader, or it's telling you that
>>> your GPU driver doesn't support version 120 on this GPU. It can be
>>> interesting to check with webgl.shader_validator=false, which disables
>>> ANGLE validation/translation, to see if the warning is coming from ANGLE
>>> or straight from the driver.
>>
>> The issue is actually that GLSL 1.10 (for the desktop) reserved the
>> matrix constructor calls taking matrix as argument. They were exposed
>> for the first time in GLSL 1.20. ANGLE's GLSL shader translator emits
>> the #version 120 directive if it encounters a matrix/matrix
>> constructor call, so the issue is that your hardware doesn't support
>> GLSL 1.20. You should be able to rewrite your shader to avoid this
>> constructor call which will be problematic on some older desktop
>> machines.
>>
>> -Ken
>
> Thanks!
>
> It's worrying that something as seemingly simple as a cast could be
> something that WebGL developers have to be careful about...although it's
> no problem at all to restructure the shader to fix the problem.
>
> What's worrying is that I've been testing pretty widely and I thought I'd
> ironed out all of the portability wrinkles.
>
> I guess we should clarify the limitations of the oldest version of GLSL
> that is supported.  Almost everyone should be writing against that minimal
> spec.  We also need to find some way to test against that set of
> restrictions without having every WebGL developer having to own an entire
> antique computer collection.

I agree with you that it's problematic that some versions of desktop
GLSL are incapable of supporting the features of GLSL ES 1.0, but some
hiccups like this are bound to happen. In all fairness, the machine
you're testing on is pretty ancient -- I would guess six or seven
years old? At least the failure to compile the shader is reported
correctly via OpenGL mechanisms. It would be worse in the long run if
we restricted WebGL's shading language even further.

> Perhaps a good first step would be to have a flag to tell ANGLE to emit a
> "#version" directive for the lowest supported GLSL version so we can see
> the "real" error messages.

That doesn't work. If you use the matrix/matrix constructor calls then
ANGLE has to emit the #version 120 directive. It's otherwise illegal
to make those calls from desktop GLSL. Many GLSL compilers are lax in
checking this, but those on Mac OS X aren't, and will refuse to
compile the shader if it sees such a constructor call without the
#version directive.


Couldn't ANGLE just emit its own constructor where appropriate?

mat4 foo = mat4FromMat3(mat3);



 
-Ken

-----------------------------------------------------------
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
-----------------------------------------------------------