[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,  <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.

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

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

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
ancient laptops.

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.

 -- Steve



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