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 2 of 2 FirstFirst 12
Results 11 to 20 of 20

Thread: GLSL Annotation Syntax

  1. #11
    Senior Member OpenGL Guru
    Join Date
    Mar 2001
    Posts
    3,576

    Re: GLSL Annotation Syntax

    Your inability and ultimate unwillingness to defend the construct you propose to a obvious and reasoned concern about it speaks to how much it is truly not needed in OpenGL. And your willingness to turn it into a personal matter rather than being about the issue in question shows how little factual need there is for this functionality.

  2. #12
    Senior Member OpenGL Pro
    Join Date
    Sep 2004
    Location
    Prombaatu
    Posts
    1,386

    Re: GLSL Annotation Syntax

    On the contrary. It's my style and enthusiasm that makes this thread worth reading in the first place

    It's your weightless prose that adds levity and entertainment value

    By the way, I am not under any contractual obligation to satisfy you or anyone else of the merits of a given proposal. I figure the good chaps ultimately responsible for the induction of new functionality are sufficiently capable of making up their own minds in these matters. Be it outright acceptance or the waste paper basket--I'll gladly leave it in their very capable hands to decide.

    However, I'll continue with this ridiculous quibbling, if you insist.

  3. #13
    Advanced Member Frequent Contributor yooyo's Avatar
    Join Date
    Apr 2003
    Location
    Belgrade, Serbia
    Posts
    872

    Re: GLSL Annotation Syntax

    @Leghorn:
    You can do this in application layer. This "feature" shouldn't go in driver. OpenGL is just a graphics library. Why driver should bother with slider, texture names (as strings), ...

    If you need such functionality, use comments like //[..] and parse comments in application.

  4. #14
    Senior Member OpenGL Pro
    Join Date
    Sep 2004
    Location
    Prombaatu
    Posts
    1,386

    Re: GLSL Annotation Syntax

    Well, now that makes a lot more sense when you put it that way.



    Thanks, Yooyo.

    P.S. It's a pipe dream, you know

  5. #15
    Senior Member OpenGL Pro
    Join Date
    May 2000
    Location
    Naarn, Austria
    Posts
    1,102

    Re: GLSL Annotation Syntax

    Perhaps someone here should really try to justify why this should go into the driver, instead of just saying "why not"

    What about this reason:
    This feature should go into the *compiler*. Why? Because you have to parse and semantically analyse the GLSL language to find out where this annotation belongs. The code is already there in the compiler, it just has to add the annotations to each symbol table object.

    The proposed solution as comments that are processed by a layer on top of GLSL (doxygen-style) would work as well. But you have to duplicate at least the GLSL parsing and the symbol list.

    So to sum up, annotations should go into the compiler, and because the compiler is in the driver they should go there, too.

    Of course it *can* be done as a layer on top of the driver. But with the same argument, the whole GLSL compiler should not be in the driver, but hey, it is already there.

  6. #16
    Senior Member OpenGL Pro
    Join Date
    Sep 2004
    Location
    Prombaatu
    Posts
    1,386

    Re: GLSL Annotation Syntax

    Thanks for your support, Overmind

  7. #17
    Senior Member OpenGL Guru
    Join Date
    Mar 2001
    Posts
    3,576

    Re: GLSL Annotation Syntax

    This feature should go into the *compiler*. Why? Because you have to parse and semantically analyse the GLSL language to find out where this annotation belongs.

    [...]

    So to sum up, annotations should go into the compiler, and because the compiler is in the driver they should go there, too.
    See, this is a justification. And a pretty decent one.

    However, it does seem that such functionality, literally storing information in GL that GL itself doesn't use internally for anything, is somewhat new for OpenGL. I don't recall another extension or feature where GL is specifically used as a data storage and retrieval device.

    Just something to think about.

    Something else.

    If this were going to happen, I would suggest that at least some of these have explicit intrinsic meanings to GL. Like the specifications of Sampler Object parameters. This is the kind of thing that a shader might need to assume or require (because it might be doing its own filtering on the texture, etc), and allowing the shader to explicitly force this would be useful.

    That way, at least you're getting a feature out of it.

    But with the same argument, the whole GLSL compiler should not be in the driver
    Hey, I agreed with nVidia that it shouldn't have been there in the first place. Obviously the ARB didn't see things that way. Thanks, 3DLabs...

  8. #18
    Member Regular Contributor
    Join Date
    Sep 2000
    Location
    Inside an xbox
    Posts
    279

    Re: GLSL Annotation Syntax

    This should not go inside the "driver". This should be part of the future OpenGL SDK helper classes. Exactly like D3D does with the D3DX library.

    So... need this to be in OpenGL? I think yes because will be useful and has been prvoed a good thing in D3D.

    Need to be in the driver? Nope, not at all. That will introduce more complexity to the driver and increase its size.
    Of course you could do yourself in your app and parse the /**/ and //comments but will be better if the official SDK supports basic things like this one with some "helper classes" like D3DX does.

    But with the same argument, the whole GLSL compiler should not be in the driver
    I think they should do that. The GLSL needs an offline compiler like D3D. Why? To protect your precious shader intellectual property, to be faster loading, to know what asm instructions are generated to see what messed the damm high-level shader compiler(ok you can do this with a 3rd party propietary and non-standard tool like NVShaderPerf ). I really don't see the point of GLSL begin compiled at realtime. It only increases driver size and after all does not optimize well.. only introduces incompatibility problems and ugly things like going software mode when founds a problem, etc...

    The D3D offline-precompiled approach is much more strict(does better validation), you can see the asm instructions it generates, obfuscates your IP and you can control the code much better. Also reduces driver size and improves shader loading times.

    In fact, I think somebody mentioned all this in the upcoming OpenGL 3.0 specification and now it's beeing implemented in that way.

  9. #19
    Advanced Member Frequent Contributor yooyo's Avatar
    Join Date
    Apr 2003
    Location
    Belgrade, Serbia
    Posts
    872

    Re: GLSL Annotation Syntax

    Well.. what if NVidia add such feature in compiler and AMD/ATI do that 6-12 months later? Your GLSL code will not work on AMD/ATI cards in that timeframe. At that time, your app have to detect driver and change shaders "on the fly" before compiling.

    Even if this suggestion goes directly to ARB and they approve this feature, it depens on OpenGL driver developers when they will support it. In short.. we can expect another mess.

    If you really need such feature do it yourself. I think it is quite easy to parse such code comments, or.. use XML for shaders, write your own shader library and store additional annotation in XML structure. When APP load XML it can generate clean GLSL code.

    To be honest.. this can be very usefull feature for shader development, but it should be in app layer. Maybe it can go in KHRONOS OpenGL SDK (if such project exist).

  10. #20
    Senior Member OpenGL Pro
    Join Date
    Sep 2004
    Location
    Prombaatu
    Posts
    1,386

    Re: GLSL Annotation Syntax

    Thanks a lot for the great feedback guys. You all raise some very good points.

    Everyone seems generally in favor of the basic idea, but unsure about where it belongs. All I'm suggesting is that this should be a part of OpenGL proper, be it in the driver, a layer, whatever makes the most sense, if and when the time comes.

    I really like the idea of exposing built in/intrinsic GL names, but my initial vision was of something embarrassingly simple to implement and spec. As it stands, this is a very simple "addition" to the parser, requires very little storage space or code complexity (a simple array of strings would do), and is completely orthogonal to the rest of the spec (zero interaction, except where a declaration is optionally decorated). I agree that it seems sorta weird to use GL as a storage bin, but perhaps the built-ins could be added later, or perhaps as yet unseen additions/changes in GL3 will make such an addition less awkward in that respect (lump it in with the IL meta type info, say). Dunno. Heck, you could add a full blown type system and go stark raving mad with this, as D3D did. Though personally, I think that's a bit overkill, but I'm not at all opposed to a little good natured insanity.

Posting Permissions

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