Extension string size for OpenGL 4.2?

[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]

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]

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.

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

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

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

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

[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]

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]

Com_Parse in Quake2 uses a fixed size buffer, not any form of malloc.

[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]

[mh]

Just updating, on NVIDIA's recently released WHQL GL4.3 drivers the extension string is now 7492.

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