Page 1 of 1

celestia generates illegal glsl shader

Posted: 31.08.2006, 15:54
by mczak
celestia 1.4.1 seems to generate shaders which are ill-formed (with celestia 1.4.1, opengl 2.0 render path, for instance when navigating to saturn).
This caused software mesa to crash (opengl information below), which has been fixed, but it still misrenders. It seems to be illegal to use non-constant initializers in glsl shaders. A more detailed bug explanation can be found here: https://bugs.freedesktop.org/show_bug.cgi?id=8065

Vendor : Brian Paul
Renderer : Mesa X11
Version : 1.5 Mesa 6.5.1
Max simultaneous textures: 8
Max texture size: 2048

Posted: 31.08.2006, 16:36
by selden
The shaders code on the page you pointed to seems to have gone through multiple hands, so it isn't clear what might have been omitted that would help identify what's generating it.

It would help if you (or the originator of the report) could provide the exact circumstance in which Celestia generates the bad code and a copy of the file shaders.log that Celestia generates. It contains a listing of Celestia's shader code.

As an "exact circumstance," a Cel /url would be the most helpful, I think. Under Windows a url is written to the clipboard by typing a Ctrl-C. I'm not sure if the same command is used under Linux.

On the other hand Chris may just have an "Aha!" moment and immediately recognize it...

Posted: 01.09.2006, 15:35
by mjkrol
The problem is detailed (with shader listing) on the bugzilla page - pointed by mczak. It says also how to solve it. You just have to fix the src/celengine/shadermanager.cpp.
It occurs in several places, but each of those faulty shaders are generated by one function, so it is not so difficult to correct that.

Thanks.

Posted: 01.09.2006, 15:59
by dirkpitt
The exact phrase in the GLSL spec (1.10.59) reads:

Declarations of globals without a qualifier, or with just the const qualifier may include initializers, in which case they will be initialized before the first line of main() is executed. Such initializers must have constant type.


It isn't crystal clear what is meant by "constant type". Uniform variables might be considered "constant" in a sense that they are constant for the primitive being rendered. FWIW, Apple's implementation accepts uniforms for global initializers. But it also accepts varying variables (which can vary across a primitive, as the name suggests) in initializers so it doesn't exactly count as a vote of confidence..

Posted: 01.09.2006, 16:58
by mjkrol
So we agree that the same rule applies to const globals and globals witthout qualifiers, right? Then the section 4.3.2 of GLSL 1.1 spec clarifies it:
Initializers for const declarations must be formed from literal values, other const variables (not including function call paramaters), or expressions of these.

The only difference between const and non-qualified globals is that you can, e.g. use it as an array size because it is guaranteed that its value did not change in the mean time.

Code: Select all

int X = 5;
void foo () {
  X = 10;
}
void main () {
  foo ();
  float arr[X];   // ILLEGAL, THE VALUE COULD CHANGE (AND IT DID)
}

If the X had const qualifier, the compiler would refuse to re-assign its value in function foo().
But I also agree that this is not very clear, because in C++ the rules are realxed, and authors of the GLSL spec say, that their language is based on C++.

Posted: 01.09.2006, 18:40
by chris
I'll fix these. It wasn't clear to me what sort of initialization was actually permitted for globals.

--Chris