Open thread for language extension poll responses

Tony will shortly be posting a new poll regarding compiler behavior with vendor-specific language constructs; this thread is reserved for responses. Please don’t post here until the new poll shows up.

I voted for outputing warnings into a log file. I don’t want to rewrite someone else’s code. But I do want to be informed that it’s a non-standard code so I would know which vendor’s shading spec I should read up on to understand the code. I would have prefered uniform way to write the shaders for ease of reading someone else’s code but I also understand the desire to change the specs to make life easier for shader writers. The make warnings into errors voting option would require me to know ihv specifics too well so that I could change it to get it to compile. Some command line kungfu:)

JD, refusing to compile nonstandard shaders would not force you to rewrite other people’s shaders, thats the whole point. If all implementations generate errors for nonstandard shaders then the erroneous code would never have been released in the first place.

Actually, given a nonstandard shader you would have to rewrite it regardless of compiler strictness if your implementation does not have the extensions the author used.

The problem with silently accepting nonstandard code is that it becomes easy to write incompatible shaders by accident. Warnings have the same problem since they may well be ignored (“it works, so it must be correct, right?”).

I voted for the ERROR aproach, much because “incompatible by accident” will be down to a minimum.

But i think the warning choice in the poll isnt as clear as it should be. You must be able to remove the warnings the same way you remove the error, by an explicit statement in the code, right? That way it could work as well. But it shouldnt always throw out warnings even it you know you want to use incompatiple ways…

I also put my vote for the Error-approach. As I said in the other thread, vendorspecific extensions will break the whole glsl apart as more and more of them will get added over time.

So I have another suggestion for the ARB : Why not make special GLSL-ARB Meeting every 6 months or so (cause that’s right now the pace at when new hardware with mostly new features gets released), where the ARB-Members decide on what to add to glSlang, and if necessary update it. That way, all new features would be approved by the ARB and could by exposed by a bi-yearly new extension.
To make it clearer : Right now we have GL_ARB_shading_language_100 with the basic glsl. And if on the next GLSL-ARB Meeting, the ARB decides that a new HW has features that should get added, a new extension in the style of GL_ARB_shading_language_xxx is released, where xxx is higher than 100 and the digits get increased according to the importance of the new features. And then you just could do a $ifdef GL_ARB_shading_language_110 (for example) in your shader to use those newer features.
I know that this approach would mean much more work for the ARB, but it would guarantee for a good glsl-standard, and in times where vendors such as ATI release a driverset every month, I wouldn’t see a problem in this approach.

Vendor-specific functions should be supported but only trough some sort of a compiler hint system.
kinda like this.

#ifdef nv40
    do ubercool new nv40 stuff
#else
    do stuff that all compilers can do
#endif

if any vendor-specific function is outside this then the compiler should produce an error.
well that’s just my $0.02

I think the error approach is the way to go. (my vote reflects this)
In my mind, the point of a standard shading language is that it is vendor independent, and having the possibility to accidently write vendor specific code in a standardized manner is just too much of a contradiction.

I think that vendor specific code should be permitted using the “normal” method of extending opengl (using vendor specific extentions)

my 2% of a buck

  • Freebe

I voted for warnings, because that’s consistent with the behaviour of C compilers. It should be good coding practice to check the info log for warnings and other messages during development. Explicitly activating a vendor-specific extension should be able to cancel the warnings.

I would, however, be happy with a spec that forced errors to be strictly upheld, unless a vendor-specific extension was explicitly activated. I would also welcome a method of strictly enforcing portable syntax, similar to GCC’s “-ansi -pedantic” flags, accompanying the “warnings by default” behaviour.

I agree that silently accepting unportable code is a recipe for disaster, and likely to be abused by IHVs (naming no names!) as an “embrace and extend” strategy. We’re already seeing problems of this nature, with a demo (developed on IHV “A” hardware) released with unportable shaders, consequently failing to run on IHV “B” hardware, and an “A” developer was then seen panning “B” for not supporting the (non-standard) “A” syntax!

I’m sure regulars will easily guess who “A” and “B” are in the above.

I voted for errors unless you ask for the extra functionality, the reason being that if I type in some C++ code which isnt valid to the C++ spec i expect the compiler to jump all over me, same goes for GLSL, if i or anyone else uses code which violates the syntax/spec (without having asked for the relaxed restricts) I would expect the compiler to jump all over me and tell me i’m wrong

I think one point that needs to be mentioned is that portability warnings for a shader cannot be treated the same way as warnings when compiling a regular program.

Regular programs are compiled once in a controlled environment. You are free to ignore any warnings since if the resulting binary is properly tested and found to work then it will keep working on all compatible computers, for the rest of eternity (sort of). Any compiler-specific extensions are translated to portable machine code.

This is not the situation we have with GLSL. Shaders are compiled every time they are used in a program, meaning that for a shader to be as portable as a binary program its source code has to be as portable as machine code.

This is the reason I think there should be no portability warnings, only errors.

Originally posted by Daniel Wesslen:
The problem with silently accepting nonstandard code is that it becomes easy to write incompatible shaders by accident.
Recently I had the notion of setting up a compile farm on opengl.org to which people could submit code samples through some email or web interface, and get back info logs for several different OS/driver/card combos. Would people be likely to use such a service if it were available?

In a similar vein, 3Dlabs has been working on a lint-like tool based on their open source parser, which will be a good precautionary measure for developers.

Recently I had the notion of setting up a compile farm on opengl.org

This would be a great idea! If it supports all common GLSL implementations I think many people will use it.

BTW what about a whole shader section on opengl.org where people can upload shaders and so on? Like cgshaders.org

Recently I had the notion of setting up a compile farm on opengl.org to which people could submit code samples through some email or web interface, and get back info logs for several different OS/driver/card combos. Would people be likely to use such a service if it were available?
Well, maybe i would use it, if there will be portability-issues. However, actually i don´t WANT to use it. Or better said, i don´t want to BE FORCED to use it. I simply want to write my shader, knowing that i don´t use anything exotic and that it will run on every hardware.

I think it is nice of you, if you provide such a service, but actually, if this would have use for anybody, it would actually mean, that glSlang has failed.

I case someone wants to know, i voted for the error-approach.

Jan.

Originally posted by Jon Leech:
[b]
Recently I had the notion of setting up a compile farm on opengl.org to which people could submit code samples through some email or web interface, and get back info logs for several different OS/driver/card combos. Would people be likely to use such a service if it were available?

In a similar vein, 3Dlabs has been working on a lint-like tool based on their open source parser, which will be a good precautionary measure for developers.[/b][/QUOTE]

Something like Comeau’s Try It Out would be very cool.

I voted for generate errors.

I think it’s better that the application programmer take care to provide a standard substitue for vendor-specific shaders, than to have unexpected rendering results.

Originally posted by Jon Leech:
In a similar vein, 3Dlabs has been working on a lint-like tool based on their open source parser, which will be a good precautionary measure for developers.
In fact, this tool has been posted to our website today. It is called GLSLvalidate. You load your shader in the tool and it’ll parse it for you, reporting any errors back. It does this by running the shader through the open source parser we also make available on our website. This parser has had scrutiny from multiple IHVs, and therefore is considered a very close match to the OpenGL Shading Language specification.

We also released GLSLparsetest. This tool is more for IHVs that want to test how well their implementation of the OpenGL Shading Language follows the specification, as far as compiling shaders goes. It does this by compiling more than 100 shaders, and comparing the compilation result (success, failure) to what the compilation result should have been. The infolog for each compile can be viewed easily.

Both tools are open source. Try them out! They can be found at http://www.3dlabs.com/support/developer/ogl2/downloads/index.htm#tool

Barthold

I’m using the “OpenGL® Shading Language Front-End Compiler Open Source” from 3DLabs site to compile the shaders for finding errors before executing the application. It is working properly with the shaders I’ve developed. I have it integrated as a custom build in Visual Studio for my glsl files.
If you have the fragment and vertex shaders in individual files (.vert & .frag files accepted by default in this compiler) and you are using Visual Studio (Windows), you can add those shaders files to your project. Then use custom build to compile them and report compile problems to the Visual Studio output window before going to the application.
If you don’t know the custom build feature, it is easy: right click on your shader file in the Visual Studio solution explorer then select properties in the popup menu. In the dialog that opens, select the custom build folder and fill the command you want to do with the file. For example:

Comand Line: StandAlone.exe $(InputPath)
Description: Compiling the glsl file
Outputs: kk.kk
Aditional dependencies: StandAlone.exe

Note:

  • StandAlone.exe is the 3DLabs OpenSource compiler slightly modified for not doing the linker pass (if not, it allways reports error). (Note that I have this exe in my tools path.)
  • $(InputPath) is a visual studio build macro. There are other useful macros but this one refers to the complete file path of the shader file that you are changing its custom build properties.
  • kk.kk is a file that is never generated so the compile of the shader is made every time you build the project. It is necesary an output file because if not Visual Studio ‘thinks’ there is nothing to build and does nothing.
  • StandAlone.exe is added as an aditional dependencie for the case that you create a new executable. In this case it is not very useful as it always do the compile pass.

In fact, I have modified the compiler to accept my .glsl custom files (that can have more than one shader defined in them). It now reads my .glsl files, compile every shader and if it doesn’t report errors, copies the .glsl file to the directory where I have my program (with a little preprocess) and use this copied file as the name of the output file. This way, as Visual Studio test dependencies, it recompiles the file just if I canged the original file (or deleted the copied file). In this case I have something like:

Comand Line: StandAlone.exe $(InputPath) d:\workdir$(InputFileName)c
Description: Compiling the glsl file
Outputs: d:\workdir$(InputFileName)c
Aditional dependencies: StandAlone.exe

In this case adding the compiler exe to the aditional dependencies is useful as Visual Studio recompile all the shaders if I change something in the executable.

I don’t know the real limitations of the standalone compiler, but it has helped a lot when creating my shaders and solving syntax or not defined variables without executing the program, and the resulting shaderes are working properly in ATI and NVIDIA implementations.

Hope this helps.

I voted for warn, because you will be using some sort of validation tool, and you WILL check the log for compile errors warnings anyway. It’s like old iostreems are deprecated in VS. If you need quick solution for one task it’s better, if you’re commercial, than you’ll do nice error/crossplatform check anyway.

EDIT:
Just parsed my NV30 shaders and OH MY GOD how many stupid limitations GLSL has :eek:

Vote for warning!
Something like:
Warning: line xxx: Using nonstandard GLSL code.

yooyo

is it just me or is the error alternative missunderstod?
it does not stop vendor specific extensions. it just fail to compile them unless you specify in the source that you want them (and therefor break compatibility with the arb glsl) so it just stops you to use them by accident