• State Accepted Answer
  • Locked Locked
  • Replies 1 reply
  • Subscribers 136 subscribers
  • Views 3845 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Shader compilation issue with ARM GLES3.0 Emulator ver 1.4

SUNIL

I am working on GLES program using ARM GLES3.0 Emulator ver 1.4.

It gives shader compilation error ““Unexpected # directive '#include consts_value “”  if shader has the following directive #include

#ifdef MACRO_1
         #include consts_value;
#else
         uniform mat4 mvp;
#endif

I don’t face this issue with ARM GLES3.0 Emulator ver 1.3.

The MACRO _1 is never defined. So the program should use the #else. But why is there syntax error with “#include”?

Parents
  • 0

    Hi Sunil,

    According to the spec (http://www.khronos.org/registry/gles/specs/3.1/GLSL_ES_Specification_3.10.pdf) section 3.4 #include is not one of the supported preprocessor directives, so that's why that line is producing an error. The spec states "Any directive not listed above will cause a diagnostic message and make the implementation treat the shader as ill-formed", it doesn't mention whether the directive is inside a conditional block or not, so the current version looks to check the shader is well formed before evaluating anything. Not doing this in previous versions was actually a source of bugs which is why it's tightened up.

    Hth,

    Chris

Reply
  • 0

    Hi Sunil,

    According to the spec (http://www.khronos.org/registry/gles/specs/3.1/GLSL_ES_Specification_3.10.pdf) section 3.4 #include is not one of the supported preprocessor directives, so that's why that line is producing an error. The spec states "Any directive not listed above will cause a diagnostic message and make the implementation treat the shader as ill-formed", it doesn't mention whether the directive is inside a conditional block or not, so the current version looks to check the shader is well formed before evaluating anything. Not doing this in previous versions was actually a source of bugs which is why it's tightened up.

    Hth,

    Chris

Children
No data