Extension string size for OpenGL 4.2?

Discuss programming topics that involve the OpenGL API.
Post Reply
Knightmare
Posts: 63
Joined: Thu Feb 09, 2012 1:55 am

Extension string size for OpenGL 4.2?

Post by Knightmare »

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.
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: Extension string size for OpenGL 4.2?

Post by Spike »

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'.
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: Extension string size for OpenGL 4.2?

Post by mh »

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
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: Extension string size for OpenGL 4.2?

Post by revelator »

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.
taniwha
Posts: 401
Joined: Thu Jan 14, 2010 7:11 am
Contact:

Re: Extension string size for OpenGL 4.2?

Post by taniwha »

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/
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: Extension string size for OpenGL 4.2?

Post by mh »

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
taniwha
Posts: 401
Joined: Thu Jan 14, 2010 7:11 am
Contact:

Re: Extension string size for OpenGL 4.2?

Post by taniwha »

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/
Knightmare
Posts: 63
Joined: Thu Feb 09, 2012 1:55 am

Re: Extension string size for OpenGL 4.2?

Post by Knightmare »

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.
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: Extension string size for OpenGL 4.2?

Post by Spike »

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.
Knightmare
Posts: 63
Joined: Thu Feb 09, 2012 1:55 am

Re: Extension string size for OpenGL 4.2?

Post by Knightmare »

Com_Parse in Quake2 uses a fixed size buffer, not any form of malloc.
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: Extension string size for OpenGL 4.2?

Post by Spike »

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.
Knightmare
Posts: 63
Joined: Thu Feb 09, 2012 1:55 am

Re: Extension string size for OpenGL 4.2?

Post by Knightmare »

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;
}
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: Extension string size for OpenGL 4.2?

Post by mh »

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
Knightmare
Posts: 63
Joined: Thu Feb 09, 2012 1:55 am

Re: Extension string size for OpenGL 4.2?

Post by Knightmare »

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