Curious to who is sticking with OpenGL now...

[mhagain]

All I really want more than anything else is a way of detecting (a) when something will be hardware accelerated, and (b) when something (and what that something is) has dropped back to software emulation. Because right now the guessing game is too much. I don't particularly care for being able to write any code I like and so long as it conforms to the driver's GL_VERSION it will work; I want code that runs well and gives me (and my end-users) no nasty surprises, I want a big dirty red flag waving here.

And I want it backported to previous GL_VERSIONs by all major vendors too. No excuses - the driver has made a decision to drop something back to software, it knows what and why, I want to be able to query it and respond accordingly.

[malexander]

All I really want more than anything else is a way of detecting (a) when something will be hardware accelerated, and (b) when something (and what that something is) has dropped back to software emulation

That sounds a lot like what GL_ARB_debug_output with its GL_DEBUG_TYPE_PERFORMANCE_ARB type is supposed to report. Though last I checked, implementations of this extension were somewhat disappointing.

[Eosie]

I think standardizing an extension loader is comparable to standardizing an replacement for opengl32.dll - the HW vendors seem to be scared to death of that. The reason is complete mystery to me.

I think opengl32.dll will stay for quite a long time. Do you know what would happen if it went away? All OpenGL apps would stop working, complaining that opengl32.dll is missing.

opengl32.dll was developed by Microsoft, not ARB. Microsoft is fully in charge of it and is the only one who can change it.

The thing is even though we can't have a complete replacement for opengl32.dll, we can have at least an alternative to it. An alternative which only new apps would use and which would provide all the features people demand.

Here's my wishlist of what such an alternative should be capable of:
- enumerate all graphics devices in the system
- enumerate all connectors of a particular device (assume the first connector is always the first monitor that has been plugged in since the system started; also a set of connectors in clone mode would be reported as one)
- enumerate all resolutions of a specific connector and provide a modesetting API for fullscreen apps
- create a rendering context on a particular device
- assign the output to a particular connector (fullscreen only)
- ability to create a windowless rendering context for offscreen rendering
(NOTE: Fullscreen apps can be windowless too, you just have to assign one or two offscreen renderbuffers to a specific connector (or a CRTC) for single or doublebuffering, respectively, so that it gets displayed on the monitor. AFAIK you can point the connector to any (aligned) address in VRAM, but there are restrictions on renderbuffer formats and memory layouts. It's possible with EGL+OpenGL on Linux already, more info here. Such flexibility may not be terribly useful or even possible on Windows.)
- all the fancy stuff from other WGL extensions
- copy any goodness from EGL (e.g. support of multiple drawing APIs)
- it can be Windows-only, but the API must be the same across GPU vendors
- it can use opengl32.dll or something else, it doesn't matter, that's just an implementation detail really.

The idea is to provide an alternative to WGL for setting up OpenGL contexts that rocks. However I wouldn't hold my breath that anything will change. The only thing the ARB seem to care about is just creating more and more extensions and the features I mentioned above do not fit into WGL very well.

[mhagain]

... awesome stuff ...

A lot of that sounds like implementing OpenGL on top of DXGI on Windows, with would be a very good move, even if it's one that is highly unlikely to happen.