Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 1 of 3 123 LastLast
Results 1 to 10 of 26

Thread: Open thread for language extension poll responses

  1. #1
    Administrator Contributor
    Join Date
    Jan 2002
    Location
    Mt. View, CA
    Posts
    97

    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.
    Jon Leech
    Khronos API Registrar
    ARB Ecosystem TSG Chair
    GL/EGL/GLES Spec Editor
    ...and suchlike

  2. #2
    Junior Member Regular Contributor
    Join Date
    Dec 2000
    Location
    USA
    Posts
    201

    Re: Open thread for language extension poll responses

    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

  3. #3
    Junior Member Newbie
    Join Date
    Apr 2004
    Location
    Sweden
    Posts
    26

    Re: Open thread for language extension poll responses

    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?").

  4. #4
    Advanced Member Frequent Contributor
    Join Date
    Oct 2001
    Posts
    596

    Re: Open thread for language extension poll responses

    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..

  5. #5
    Junior Member Regular Contributor
    Join Date
    May 2003
    Location
    Germany
    Posts
    229

    Re: Open thread for language extension poll responses

    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.

  6. #6

    Re: Open thread for language extension poll responses

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

    Code :
    #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

  7. #7
    Junior Member Newbie
    Join Date
    Mar 2004
    Posts
    7

    Re: Open thread for language extension poll responses

    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

  8. #8
    Junior Member Newbie
    Join Date
    Aug 2003
    Posts
    5

    Re: Open thread for language extension poll responses

    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.

  9. #9
    Member Regular Contributor
    Join Date
    Apr 2004
    Location
    UK
    Posts
    420

    Re: Open thread for language extension poll responses

    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

  10. #10
    Junior Member Newbie
    Join Date
    Apr 2004
    Location
    Sweden
    Posts
    26

    Re: Open thread for language extension poll responses

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •