Bug: PVRUniSCoEditor gives false GLSL error

PowerVR Insider
1

Hi. I’m using PVRUniSCoEditor v1.5 (SDK build 2.08.28.0607)
with the following GLSL ES Compiler: OGLESWindows_x86_32PVRUniSCo_SGX53x.exe

My apologies if this has been brought up before but


the compiler incorrectly gives the following error message with the following code samples:



’"’ is an invalid character in GLSL.


I also get the same error when running my PC GLES program using the PVR provided GLES libraries.

Sample 1:
#if 0
#include “file.h”
#endif

Sample 2:
#ifndef GL_ES
#include “file.h”
#endif

The same code compiles successfully on iOS.

Could a fix be included for the next SDK release?
In the meantime, is there a workaround, quickfix, etc that I can use?
Thanks in advance.



2

Hi.


Apologies for the time taken to reply. I can verify the issue you’re having and I’ve logged the bug in our tracker system with ID BRN34644.





Thanks.

3

Thanks for the follow up Arron! 
Out of curiosity, is the bug tracker database publicly viewable? I couldn’t find a link to it on Imagination Technologies’ site.

4

Unfortunately not: the tracker system is internal. I posted the BRN number so that you can use it for reference against future SDK releases as we post a list of fixed BRNs.





Best regards.Arron2011-10-13 10:58:00

5

Hi.


I’ve just received an update regarding this issue.





The GLSL specification states that quotation marks are invalid characters outside of comment blocks even inside pre-processor blocks that will not be processed. This is detailed in section 3.1 here: http://www.opengl.org/registry/doc/GLSLangSpec.4.20.8.clean.pdf





Moreover, the #include directive you are using in your preprocessor block is also not part of the specification (hence why the quotation marks is not supported). This is detailed in section 3.3.





The above specification also applies to GLSL:ES.





Best regards.Arron2011-10-19 12:42:32

6

Hi Arron.  Thanks for posting the update!
I'm not expert but there are a few observations I'd like to share.

1. There happens to be a separate specification for ES version of GLSL which can be found here:
http://www.khronos.org/registry/gles/specs/2.0/GLSL_ES_Specification_1.0.17.pdf
If that link ever breaks in the future, a link to the latest version of the GLSL ES specification should be found on this webpage http://www.khronos.org/registry/gles/


2. If you look at the appropriate section for "Prepocessor" commands in the GLSL ES document that I linked to (3.4) and GLSL document that you linked to (3.3), they both more or less say that "#if, #ifdef, #ifndef, #else, #elif, and #endif are defined to operate as (is standard) for C++"  (The exclusions that the GLSL ES doc then goes on to mention don't seem relevant for this conversation.)

In C++ I can write the following code in one of my files and still compile it successfully.
#if 0
4this is not valid code
#include
#endif

I assume this works because before the compiler runs and checks what characters are valid against the "Character Set" section of the specification, and before other preprocessor commands are evaluated, the #if and related preprocesser commands have been evaluated and any characters inbetween #if 0 and #endif have been removed.  Thus the compiler never even knows they were there.  Hopefully that made sense and you can still see the validity of my original bug report.

Thanks again for taking the time to share an update!
WhatsInAName2011-10-19 13:35:33
7
  1. Sorry, I didn’t mean to imply that the GLSL spec is also the GLSL:ES spec. I just linked to the GLSL spec as it’s slightly more verbose the relevant sections.





    2. Indeed I can see the validity of your original report (hence why I filed it against our compiler), alas the preprocessor checks for valid characters just as the compiler does - hence why your examples don’t compile.





    As a workaround you could easily strip out the offending line/characters before passing it to GL - simple pre-processors are easy to write :).





    Best regards/