Another problem with shader compilation.

[GoogleCodeExporter]

Hi, i`ll be really thankful if you help me to solve this problem.
I have a Visual Studio 2012 and Windows 8,also ATI HD4850. I try to run an 
OGLDEV tutorial 39, the source is builded ok, but when i run the programm the 
compiling of shaders is start and i have an error states that "Undeclared 
identefier gl_in, Undeclared identefier gl_position, and No matching overloaded 
function found EmitVertex and No matching overloaded function found 
EndPrimitive". I attached a screenshot of errors and the shader file. Please 
help, i can provide any information if neccesary.

Thanks, Timur. 

Original issue reported on code.google.com by timur.ku...@stripedarts.com on 9 Apr 2013 at 12:00

Attachments:

• silhouette.glsl
• screenshot4.jpg

[GoogleCodeExporter]

SOLVED!

It seems that gl_position, gl_in, EmitVertex and EndPrimitive is available only 
in geometry shader, but when compile a complete shader that contain all shader 
stages in one file it flounder, and the function that was called from the 
geometry shader was declared earlier and tried to compile in vertex shader 
stage. It`s better to make a separate file for each stage of shaders. Correct 
me if i wrong.

Thanks, Timur.

Original comment by timur.ku...@stripedarts.com on 9 Apr 2013 at 12:31

[GoogleCodeExporter]

The problem here is that Etay used the variables gl_Position and gl_in in the 
global function EmitLine. This means that each stage in the program got to see 
these variables. However, they're not valid for FS, and gl_in isn't valid in VS 
either.

The whole point of GLFX was that all stages could be kept in a single file for 
readability and sharing. However, writing global functions that access 
per-stage specific variables is asking for trouble. NVIDIA's GLSL does 
optimizations, and then checks for link problems. That's why it works there. 
Most compilers don't work that way, AMD's included. AMD's compiler sees 
gl_Position in FS during the initial stages of the link and automatically fires 
an error.

The best way around this issue is to manually inline the function EmitLine into 
the GS.

When GLFX will do real GLSL parsing (and that isn't going to happen anytime 
soon), then it might remove unused functions, but until then the best way to 
ensure correctness is to use per-stage specific variables only in the shader 
function.

Original comment by max.snif...@gmail.com on 9 Apr 2013 at 12:52

[GoogleCodeExporter]

Again big thank you, for the explanation.

Thanks Timur.

Original comment by timur.ku...@stripedarts.com on 9 Apr 2013 at 6:55

[GoogleCodeExporter]

You're welcome

Original comment by max.snif...@gmail.com on 9 Apr 2013 at 10:08

• Changed state: WontFix