[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 5:47 AM, <firstname.lastname@example.org> wrote:
>>> On Sun, Mar 13, 2011 at 10:50 PM, Benoit Jacob <email@example.com>
>>>> ----- Original Message -----
>>>>> I have an odd vertex shader compiler error that's happening on just
>>>>> 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
>>>>> 3x3 matrix.
>>>> It seems that GLSL ES 1.0 doesn't have a mat3(mat4) constructor, as
>>>> 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
>>>> 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
>>>> 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
>> 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
>> 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
>> spec. We also need to find some way to test against that set of
>> restrictions without having every WebGL developer having to own an
>> 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.
Yeah - it's probably fairly old - but lots of people still use computers
that old for stuff like web browsing. In this case, the kid who owns it
is in college...his parents don't have a lot of money - so they bought him
this used Sony VAIO laptop. As a practical matter, WebGL runs really well
on it...but this one particular shader crapped out.
I don't know about "reported correctly" though. "unsupported version 120"
hardly says "matrix casts unsupported due to obsolete GLSL version". I
was lucky that the shader was so simple - I could guess the problem on the
very first try. But most WebGL developers are going to be completely
I guess the "correct" thing would be to blacklist anything that doesn't
support GLSL 120 - but that's unfortunate because aside from this tiny
problem, this laptop actually runs 99.9% of WebGL a hell of a lot better
than the brand shiney new Win7 NetBook that I bought just two weeks ago
(Intel graphics chip).
I don't know what other restrictions there are with GLSL before version
120 - but it would be nice to know so that developers could avoid them and
widen the number of systems they can run on. Losing matrix casting is a
small price to pay - IF you know that you have to avoid them.
>> Perhaps a good first step would be to have a flag to tell ANGLE to emit
>> "#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.
I'm not saying that ANGLE shouldn't emit #version directives in the normal
operation of the browser - obviously it must.
I'm just asking for a way to know that my code won't run on GLSL <120
systems so that I can fix that. Turning off ANGLE's verifier doesn't help
because I need to know that there is a latent problem even though I'm
working on a very modern computer. Most developers don't own a bunch of
ANGLE must know when this problem crops up because it's outputting the
#version directive. What I need is a warning message with a higher
quality explanation whenever it feels the need to do that.
A sneaky "developer only" flag to turn this on would be fine. I always
turn the error verbosity all the way up and treat all warnings as errors
anyway - and I certainly don't mind setting more sneaky flags if it helps
me to run my website on older systems.
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: