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 4 123 ... LastLast
Results 1 to 10 of 36

Thread: extension string rules

  1. #1
    Super Moderator OpenGL Guru
    Join Date
    Feb 2000
    Location
    Montreal, Canada
    Posts
    4,256

    extension string rules

    There is some discussion on the mac mailing list about extensions being integrated into future GL versions and being removed from the GL_EXTENSIONS string.

    It causes problems for older programs. Isn't there rules governing what should be in the string and when a string can be removed?

    It comes down to *not* removing strings, thus the list becomes ever larger, or people write better code and make easy updates available.

    This is a weakness of gl that needs attention.

    V-man
    ------------------------------
    Sig: http://glhlib.sourceforge.net
    an open source GLU replacement library. Much more modern than GLU.
    float matrix[16], inverse_matrix[16];
    glhLoadIdentityf2(matrix);
    glhTranslatef2(matrix, 0.0, 0.0, 5.0);
    glhRotateAboutXf2(matrix, angleInRadians);
    glhScalef2(matrix, 1.0, 1.0, -1.0);
    glhQuickInvertMatrixf2(matrix, inverse_matrix);
    glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
    glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);

  2. #2
    Intern Contributor
    Join Date
    Sep 2002
    Location
    london, uk
    Posts
    63

    Re: extension string rules

    i think the idea with next gen opengl (or whatever its pet name is) is that the old (pre-2.0) functionality is emulated/provided by a separate component (subdriver, if you will)... the way 3dlabs' docs read, looks like there's no reason why it can't be - so you get backwards compatibility along with the new api. clean and invisible

  3. #3
    Senior Member OpenGL Pro
    Join Date
    Feb 2002
    Location
    Bonn, Germany
    Posts
    1,633

    Re: extension string rules

    This really shouldn't be an issue. You start running into problems if you copy the extension string into a fixed size buffer. But that's actually never necessary.
    If you really want to copy it you should call strlen first and allocate a buffer that's big enough. If you don't, well your app is broken

  4. #4
    Junior Member Regular Contributor
    Join Date
    Apr 2002
    Posts
    101

    Re: extension string rules

    Would it be safe to say that I think V-man was talking about future version of GL1.x?

    Say GL_ARB_MULTITEXTURE gets dropped from the extension string, which could possibly happen because it is now part of the core of OpenGL. And a program is written to use that extension (say Quake III). If it were to be removed from the extension list, even though its functionality is still available, then Quake III won't be able to use the multitexturing capabilities of your card because it can't find the extension string, and wglGetProcAddress (or glXGetProcAddress ) won't get glMultiTexCoord2fARB and whatnot. So Quake III turns your GF4 into a souped up Riva128

    My suggestion would be to make a change as to how the glGetString command retrieves the extension list (like a glHint). The default of the GL_EXTENSION_LIST_SIZE is to report all supported extensions (including those added to the core), and you can hint to it that you know how to handle core extensions and have the driver only report those extensions not in the core. If the default of it is set to return all extension, old apps work fine. And you can tell it that your new app written today doesn't need the 20+ added extensions that you know already exist as part of the core.

    just my $0.02

    Dan

  5. #5
    Senior Member OpenGL Guru
    Join Date
    Mar 2001
    Posts
    2,411

    Re: extension string rules

    I believe the rule is that all functions for GL level X is exposed in an implementation that claims to be version X, but extensions are only exposed if the hardware and drivers support it well.

    It doesn't make sense to support some extension that won't actually work well in the hardware.
    "If you can't afford to do something right,
    you'd better make sure you can afford to do it wrong!"

  6. #6
    Super Moderator OpenGL Guru
    Join Date
    Feb 2000
    Location
    Montreal, Canada
    Posts
    4,256

    Re: extension string rules

    Originally posted by jwatte:
    [B]I believe the rule is that all functions for GL level X is exposed in an implementation that claims to be version X, but extensions are only exposed if the hardware and drivers support it well.
    [B]
    You mean treat it as GL 1.1 + extensions?

    If level X is 1.4 then certain drivers return extensions that are now integrated into 1.4 which in some sense doesn't make sense.

    If they decide to remove the extension
    (Dan82181 got the point), then older games and apps are broken since they expect to find ARB_multitexture for example.

    If some vendors don't want to advertise certain extensions because they know it will lead to bad performance or crashes, then I dont know where that rule is written but Im aware of it thanks to Matt.

    The point is that some people are confused/unhappy/want the extension to stay/want a better solution to this.

    V-man
    ------------------------------
    Sig: http://glhlib.sourceforge.net
    an open source GLU replacement library. Much more modern than GLU.
    float matrix[16], inverse_matrix[16];
    glhLoadIdentityf2(matrix);
    glhTranslatef2(matrix, 0.0, 0.0, 5.0);
    glhRotateAboutXf2(matrix, angleInRadians);
    glhScalef2(matrix, 1.0, 1.0, -1.0);
    glhQuickInvertMatrixf2(matrix, inverse_matrix);
    glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
    glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);

  7. #7
    Junior Member Regular Contributor
    Join Date
    Sep 2001
    Location
    Wake Forest, NC, USA
    Posts
    171

    Re: extension string rules

    A few comments:

    There is no "official" policy on removing items from extension strings. It is certainly possible for a driver to screw with its extension string however it sees fit. Backwards compatibility is usually a good reason to keep supporting old extensions, particularly since there is little to no cost in doing so. Vendors generally keep the old stuff around for this reason.

    There is no official policy on supporting extension string entries for extensions sucked into the core. In recent revisions, NVIDIA has adopted an unofficial policy of exporting extension strings for features in the core if and only if the features are supported in hardware. Basically this comes down to the question: "if feature X wasn't in the core, would we expose it as an extension"? For software-only features, the answer is generally no.

    A few other appeals:

    (1) PLEASE don't copy the extension strings into a fixed-size buffer. You might think "2KB is big enough to hold any extension string", but you'd be wrong.

    (2) Make sure that when you query the GL version you consider the possibility of future OpenGL revisions, so you run your 1.3 path on 1.3 *OR BETTER*. Every time we rev our driver, there's usually a couple apps that see the new version and fall back to their "1.0" path (it's not 1.3, it's not 1.2, it's not 1.1, so it must be 1.0).

    I think the general tendency is to keep "old" extension strings in for the reasons that several of you mention. If this is important to you, make sure you lobby your OpenGL vendors not to make these sort of changes.

  8. #8
    Senior Member OpenGL Guru Humus's Avatar
    Join Date
    Mar 2000
    Location
    Stockholm, Sweden
    Posts
    2,345

    Re: extension string rules

    I find it scary sometimes how people code their apps. There are silly mistakes like (1) and (2) above even made by people I would recognice as quite skilled. For a long time S3TC didn't work in the OpenGL renderer for UT on ATi cards, until I digged into the source code of it. Instead of fully debugging it I made a quick hack to get it to work simply by setting SupportTC = 1; After I posted the "fixed" version on a few forums it didn't take long until Epic released an official fixed version. It turned out their extension checking routine refused to go beyond 1024 bytes.
    Another thing I've never understood why some people do, why copy at all?

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

    Re: extension string rules

    Another thing I've never understood why some people do, why copy at all?
    Well, actually, there is a good reason to do the copy. Granted, it happens to involve proven code that wouldn't cause this problem.

    If I were parsing the extension string, I would want to put it in a std::string rather than use the bare char *. Since std::string is a string-by-value, it would do a copy from the char*. Granted, it wouldn't assume a fixed maximum size, so you wouldn't get this problem.

  10. #10
    Senior Member OpenGL Pro
    Join Date
    Feb 2002
    Location
    Bonn, Germany
    Posts
    1,633

    Re: extension string rules

    Duh
    Code :
    const char* ext_string=NULL;
     
    bool
    is_supported(const char*const extension)
    {
    	if (ext_string==NULL)
    	{
    		ext_string=(const char*)glGetString(GL_EXTENSIONS);
    	}
     
    	uint ext_string_length=strlen(ext_string);
    	uint ext_len=strlen(extension);
     
    	uint o=0;    //offset into the extension list string
     
    	while (o<ext_string_length)
    	{
    		//skip spaces
    		while ((o<ext_string_length)&amp;&amp;(ext_string[o]==' ')) ++o;
    		//check current extension identifier
    		if (strncmp(ext_string+o,extension,ext_len)==0)
    		{
    			//check if this was the end of the extension identifier (GL_ARB_mu vs GL_ARB_multitexture)
    			char lim=ext_string[o+ext_len];
    			//space or zero termination characters are acceptable
    			if ((lim==' ')&amp;#0124; &amp;#0124;(lim==0)) return(true);
    		}
    		//skip identifier (non-spaces)
    		while ((o<ext_string_length)&amp;&amp;(ext_string[o]!=' ')) ++o;
    	}
    	//didn't find it
    	return(false);
    }
    [This message has been edited by zeckensack (edited 10-24-2002).]

Posting Permissions

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