Forum

Extension string size for OpenGL 4.2?

Discuss programming topics that involve the OpenGL API.

Moderator: InsideQC Admins

Extension string size for OpenGL 4.2?

Postby Knightmare » Sat Nov 24, 2012 9:36 pm

I'm sure everyone here knows about the GL extension string overflowing the 4KB buffer in Quake's printf function and causing a crash. 3 years ago, I modified my Q2 engine to have an 8KB buffer for this and use vsnprintf instead of vsprintf.

I'd like to know what size this string is for the lastest cards and drivers that support GL 4.2. I'm currently using a GeForce GTX 285 with OpenGL 3.3 support, and the extension string is about 5.3 KB. If the extension string for OpenGL 4.2 is nearing 8KB, then I need to increase my VID_Printf buffer size to 16KB.
Knightmare
 
Posts: 61
Joined: Thu Feb 09, 2012 1:55 am

Re: Extension string size for OpenGL 4.2?

Postby Spike » Sat Nov 24, 2012 10:42 pm

opengl has depricated the extension string since gl 3. It is an error to query it within a 'core' context.

Here's the stuff that's relevent:
#define GL_MAJOR_VERSION 0x821B
#define GL_MINOR_VERSION 0x821C
#define GL_NUM_EXTENSIONS 0x821D

qglGetIntegerv(GL_NUM_EXTENSIONS, &gl_num_extensions);
for (i = 0; i < gl_num_extensions; i++)
printf("%s ", qglGetStringi(GL_EXTENSIONS, i));

GL_MAJOR_VERSION is only valid with gl3 too, of course, so be prepared to get an error from querying that with lower api levels, but if it does error then you know you got a gl1/gl2 context so GL_NUM_EXTENSIONS won't work either.

I don't have a gl4 driver/gpu, so the only other answer I could give is 'how long is a piece of string'.
Spike
 
Posts: 2853
Joined: Fri Nov 05, 2004 3:12 am
Location: UK

Re: Extension string size for OpenGL 4.2?

Postby mh » Sun Nov 25, 2012 2:02 am

On an NVIDIA Kepler (GL4.2) it's 6749 bytes but I don't have a GL4.3 driver (yet) which is going to add a few more bytes.

This is a fight you're not going to win. You increase the string buffer, new extensions get added, you increase it again, more new extensions, etc. It's an arms race, a war of attrition. Either use the newer method (as outlined by Spike) or just don't Con_Printf the extensions string. If you must print it, then break it out into individual extensions.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
User avatar
mh
 
Posts: 2283
Joined: Sat Jan 12, 2008 1:38 am

Re: Extension string size for OpenGL 4.2?

Postby revelator » Sun Nov 25, 2012 4:17 pm

Should probably kill that one in Doom3 to it still uses it :)
Edit: was wrong it uses something like spikes example but without the loop.
Productivity is a state of mind.
User avatar
revelator
 
Posts: 2497
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: Extension string size for OpenGL 4.2?

Postby taniwha » Mon Nov 26, 2012 2:46 am

Strings in QuakeForge have been considered to have unlimited length since very early on. This is why QF has dstring_t (thanks, snax!) and a nice mini-library for handling such strings, including centralized access to vsnprintf (due to the portability hassles, almost all formated printing goes through a tiny handful of functions, and va() is merely a wrapper around the dstring functions). [HCI]Maraakate copied the dstring code into his dos quake project and never looked back :) (once he got the hang of using it).

The rule I've heard for counts in programming: zero, one or infinite.
Leave others their otherness.
http://quakeforge.net/
taniwha
 
Posts: 399
Joined: Thu Jan 14, 2010 7:11 am

Re: Extension string size for OpenGL 4.2?

Postby mh » Mon Nov 26, 2012 6:13 pm

In practice you're also eventually going to hit the limit of the console text buffer (CON_TEXTSIZE) unless you work around that too.

The easiest option in the case of GL extensions is to just not print them.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
User avatar
mh
 
Posts: 2283
Joined: Sat Jan 12, 2008 1:38 am

Re: Extension string size for OpenGL 4.2?

Postby taniwha » Tue Nov 27, 2012 2:24 am

Oh, that's right, that existed too ;)

Actually, I think the conbuffer size is still limited, but it's now a ring buffer.

However, yeah, it's pretty useless printing the extension string every time (can be useful for developer prints, though).
Leave others their otherness.
http://quakeforge.net/
taniwha
 
Posts: 399
Joined: Thu Jan 14, 2010 7:11 am

Re: Extension string size for OpenGL 4.2?

Postby Knightmare » Thu Nov 29, 2012 2:26 am

I'm only printing it in developer mode (or if the gl_strings command is used).

So for maximum compatibility, should I check the GL_VERSION string, and then if it's 3.0 or higher, query GL_NUM_EXTENSIONS?
I'd like to be able to parse both an array of extensions and an extension string with the same code. Maybe I could use Com_Parse() on the extensions string for legacy drivers to build a similar extension array, and pass each extension through an single extensions check function.

Developer printing could be done by only printing 2 or 3 extensions at once in a single line.
Knightmare
 
Posts: 61
Joined: Thu Feb 09, 2012 1:55 am

Re: Extension string size for OpenGL 4.2?

Postby Spike » Thu Nov 29, 2012 2:43 am

you shouldn't be simply strstring extensions anyway, you can get false positives from doing that.
I'm not sure that I'd use Com_Parse myself. Its potentially a lot of mallocs. might be better to just count the spaces then split an strduped string.
Spike
 
Posts: 2853
Joined: Fri Nov 05, 2004 3:12 am
Location: UK

Re: Extension string size for OpenGL 4.2?

Postby Knightmare » Thu Nov 29, 2012 6:05 am

Com_Parse in Quake2 uses a fixed size buffer, not any form of malloc.
Knightmare
 
Posts: 61
Joined: Thu Feb 09, 2012 1:55 am

Re: Extension string size for OpenGL 4.2?

Postby Spike » Thu Nov 29, 2012 6:37 am

I was talking about using using an array of string pointers for easy querying of extensions. Which would need to be malloced somehow to avoid writing to a gl driver dll's read-only cdata section.

If you're not going to use VBOs+VAOs for everything then it won't work with a gl3core context anyway, and you might as well just use the depricated extension list anyway. You'd only need to malloc if you're preprocessing the list to keep both gl1 and gl3 extension lists in an identical memory representation for checking if extensions are supported.
Skip gl3 features and use Com_Parse to split it for debug printing, sounds like a solution.
Spike
 
Posts: 2853
Joined: Fri Nov 05, 2004 3:12 am
Location: UK

Re: Extension string size for OpenGL 4.2?

Postby Knightmare » Fri Nov 30, 2012 10:29 pm

BTW, here's my implementation of a function that will check the extension list while avoiding false positives. It's a drop-in replacement for the use of ststr() in Quake2's R_Intit().
Code: Select all
qboolean StringContainsToken (const char *string, const char *findToken)
{
   int         tokenLen;
   const char   *strPos;
   char      *tokPos, *terminatorPos;

   if ( !string || !findToken )
      return false;
   if ( (strchr(findToken, ' ') != NULL) || (findToken[0] == 0) )
      return false;

   strPos = string;
   tokenLen = strlen(findToken);
   
   while (1)
   {
      tokPos = strstr (strPos, findToken);

      if ( !tokPos )
         break;

      terminatorPos = tokPos + tokenLen;

      if ( (tokPos == strPos || *(tokPos - 1) == ' ') && (*terminatorPos == ' ' || *terminatorPos == 0) )
         return true;

      strPos = terminatorPos;
   }

   return false;
}
Knightmare
 
Posts: 61
Joined: Thu Feb 09, 2012 1:55 am

Re: Extension string size for OpenGL 4.2?

Postby mh » Wed Dec 26, 2012 9:47 pm

Just updating, on NVIDIA's recently released WHQL GL4.3 drivers the extension string is now 7492.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
User avatar
mh
 
Posts: 2283
Joined: Sat Jan 12, 2008 1:38 am

Re: Extension string size for OpenGL 4.2?

Postby Knightmare » Wed Feb 13, 2013 3:37 am

So it is as I expected, coming up on 8KB already. But I've got the Com_Parse splitting implemented, even in my RtCW 1.42 patch now, so the string size is pretty much irrelevant now.
Knightmare
 
Posts: 61
Joined: Thu Feb 09, 2012 1:55 am


Return to OpenGL Programming

Who is online

Users browsing this forum: No registered users and 1 guest