Extensions to promote to ARB/core

Here is a list of extensions, that i use but have found not to be in core yet, some of them not even EXT or ARB. Those are GL 2.1 extensions, some of them have been included in GL3, but not all. I am not sure, whether the ARB plans to release a GL 2.2 for all those “lazy CAD developers” :wink: i am more concerned with GL3 development. Still it is a bit crazy that there are extensions, which are used by nearly every GL application for many years, but have not yet been promoted to core, ARB or even EXT.

Not in GL3, not in core, most not even ARB:

WGL_EXT_swap_control (!!!)
GL_S3_s3tc (!!!)
GL_EXT_texture_filter_anisotropic (!!!)

Included in GL3, but not ARB or in core in GL 2.x

Please correct me, if i got something wrong here.

Especially texture compression, anisotropic filtering and v-sync should become core soon, IMO.

There are certainly more extensions to be put on that list, but those are the ones, that i found in my code to be referenced.


Totally agree. Recently I was doing cleanup of my code and I was very surprised that there is no “core” alternative for GL_EXT_texture_filter_anisotropic.
This extension was done in 2000! It is impossible to use mipmaping (in real applications) without this extension. I think the extensions is supported by all vendors.

There are similar and more DSA-friendly functions in GL2.0 already.


Never heard of that specific one. Anything in this that isn’t in EXT_texture_compression_s3tc (provides DXT1/3/5 compression)? We definitely use that one, along with the other DXT-related compressions (e.g. LATC). If this isn’t core yet (along with anisotropic filtering), I too am kinda shocked.

Sorry, i just searched the registry for “s3tc”, yeah EXT_texture_compression_s3tc is the one i actually meant, but afaik it is not core. I did search the GL 3.1 spec, ARB_texture_compression is core, but those give only the entry points for uploading a compressed texture, no internal formats are defined. So s3tc isn’t core anywhere (except for D3D…).

AFAIK s3tc is not in core because of patent issues. Somebody (probably S3 Graphics if I remember correctly) holds patent for dxt compression, so putting this extension in core will require for OpenGL vendors to acquire licence for usage of patent (read - it will cost them lot of $).

But all of them do support the S3TC compression scheme, so they shoud already have corresponding licenses…

Except Mesa, I think.

Aren’t we forgetting EXT_direct_state_access? I’m wondering why that hasn’t been promoted in/since GL 3.1.

That was the major thing that let me down in 3.0.

Another reason for us to not want them to put S3TC support into core GL: It would lock out newcomers (which won’t ge a license) and thus work against innovation.


Btw, that obscure S3 extension was buried in the registry


Seems it was deprecated in 2003 in favor of EXT_texture_compression_s3tc, at a time when it seems no one even knew where the IP buck stopped. Talk about an IP ort cloud…

“Aren’t we forgetting EXT_direct_state_access?”

I have deliberately let that one out of the list, because that extension is very new and has a lot of quirks (immediate mode stuff, etc.). It’s simply not “done” yet. All the extensions i mentioned are OLD, really really old. They have proven to be working and most people use them all the time. So those can simply be promoted, whereas EXT_direct_state_access needs a major re-hauling (just as some other nice extensions, that i would like to see in core someday, but not right now in their current state).


besides EXT_direct_state_access is more of a workarround for stuff that currently doesn’t work that well, once these are fixed (like texturing) there would be no further use for EXT_direct_state_access.

I’d rather think of it as once we eliminate bind-to-edit there will be no further need for EXT_direct_state_access.

It’s not like b2e is a 1000 pound gorilla or anything, but striving for perfection is a worthwhile endeavor (even if we never actually reach it).

Direct state access is nice to have but not mandatory.

“Bind-to-edit” is actually a direct access internally…

EXT_direct_state_access would be a lot shorter if it was written against 3.1 core only…

Excuse me I just noticed that there is no similiar function
like the GL_EXT_texture_filter_anisotropic stuff in the
gl3.h header.

So I found this thread here and wonder how to enable
anisotropic filtering in OpenGL 3.2 because I always
used this improvement in old OpenGL 1.X programs.


Holy thread necromancy, Batman!

OpenGL 3.x core did not remove any extensions; only core features. So you can use any extension, so long as it doesn’t involve using functions that were removed.

I can’t see EXT_texture_integer getting to GL 2.2 (if such a thing was ever made) as native integer support only existed in GL3 capable hardware (for example GF 6 series, the ideal GL2 card of that generation, cannot do native integer support)… though there is the whole “backport GL extension thing” (like GL_ARB_framebuffer_object) for GL2.x world… but still given that we have the compatibility profile thing, I cannot see a GL 2.2 ever being made… seems odd to bother with such a thing, unless you like Intel GPU’s… giggles…

Yeah that’s clear but there is no
defined in gl3.h.

So atm I define it myself:


I hope that is the right way to do it although I would
prefer to include an official header instead of defining
such stuff myself, something like “gl3ext.h
similiar to the old glext.h.