View Full Version : Open thread for language extension poll responses
Jon Leech (oddhack)
04-13-2004, 10:11 PM
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:)
04-15-2004, 01:04 AM
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..
04-15-2004, 02:47 AM
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.
04-15-2004, 03:10 AM
Vendor-specific functions should be supported but only trough some sort of a compiler hint system.
kinda like this.
do ubercool new nv40 stuff
do stuff that all compilers can do
#endifif any vendor-specific function is outside this then the compiler should produce an error.
well that's just my $0.02
04-15-2004, 04:21 AM
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
04-15-2004, 08:25 AM
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.
04-15-2004, 08:33 AM
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
04-15-2004, 12:19 PM
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.
Jon Leech (oddhack)
04-15-2004, 12:59 PM
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.
04-15-2004, 02:12 PM
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.
04-15-2004, 02:21 PM
Originally posted by Jon Leech:
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.[/QUOTE]
Something like Comeau's Try It Out would be very cool.
04-15-2004, 02:47 PM
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.
04-15-2004, 08:45 PM
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
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
Aditional dependencies: StandAlone.exe
- 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
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.
04-16-2004, 02:59 AM
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.
Just parsed my NV30 shaders and OH MY GOD how many stupid limitations GLSL has :eek:
04-16-2004, 06:51 AM
Vote for warning!
Warning: line xxx: Using nonstandard GLSL code.
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
04-16-2004, 08:25 AM
Originally posted by Mazy:
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 accidentExactly!
04-16-2004, 02:54 PM
all the ones voting for warning are rather dump imho. why not force it to work the right way? i know enough c/c++ code wich is filled with warnings, and results in bugs if you port to other compilers. warnings should not even be supported. not, for the language. possibly putting warnings like "this will perform bad" or "this will run software on the current system", or something like that. but definitely don't allow non-standard code to get compiled if you use the standart opengl shading language.
if you use another language, something vendor specific, then FINE, DO SO. it's up to you. but if you use glslang, and only glslang, then you have to use it the way it has to be able to run EVERYWHERE DURING THE NEXT 10 YEARS.
where ever there are slight differences, that don't result in errors, but are non-standart, it results in bugs in the end.
you want an example? the wrong GL_CLAMP behaviour on nvidia hw over years. this was non-standard behaviour, and it went trough years due to legacy support. result is, i have still old apps from time to time, that don't run correctly on my radeon9700pro. why? becaues nvidia allowed non-standard code to pass the glError validation.
and this would be a very small thing, compared to allowing non-standard glslang to pass. the second home-made glslang demo, the one on delphi3d (first humus, then him.. sometimes this way, somethimes the other way around), this one of the first-demos online wich was homemade, showed the very first time what problems arise.
this has to be stopped. NOW.
04-16-2004, 03:04 PM
indeed, i'm glad to see Errors just about edging out warnings, but it is a tad silly to see if so close
(as a total side note to the voting I'd be intrested to see how it runs along card owner lines, are more Nvidia users voting for warnings because they want to use the extra stuff without the hastle it will cause them? or what.. )
04-16-2004, 03:51 PM
Well I vote that vendors be required to put their extensions in files that you have to include to use them or pragmas maybe (depends on if/when there is an extension specification in GLSL), or perhaps some other method. In that case, any use WITH OUT EXPLICITLY STATING YOU WANT IT would be an error.
Especially if they were put into files, they should also be encouraged to provide fallback paths (like half for instance). That way any vendor specific feature would be supplied in libraries/include files that could work with all compilers (or generate an error if you try to use it with a compiler that doesn't support it). Is there such any extension mechanism? I also don't know if that would be negative for performance aspects of the compiler (shouldn't be THAT big a deal...).
04-16-2004, 04:19 PM
I agree with the opiniont the best way of saving the standart is to through errors (I voted for that). But I also think that there should be an easy way for enabling non-standart language features. Always calling glEnable() is quite messy. I'd like to have either new shader targets (I think GL_EXT_cg_shader works this way) or easy in-code activation like #define or #pragma or something like that. But nevertheless if such extensions aren't explicitly enabled the shader compiler HAS TO return errors in my opinion if they are used.
05-28-2004, 08:10 PM
Compiler should fail on unenabled extensions.
Coders should enable the extensions they need before using them.
If this is done in the the source file, it makes the file independent of the build process.
If you want to make sure extensions have not been enabled then a compiler option can do that.
This allows an organization to check that source with enabled extensions isnt being slipped in by developers. If enabling extensions can be standardized in some reasonable way, then the compler option can allow some exceptions. For example, all extensions have a name. The compilier command can be given a list of names. The usual include/exclude all/name option schemes can apply.
Powered by vBulletin® Version 4.2.2 Copyright © 2016 vBulletin Solutions, Inc. All rights reserved.