As you use some bleeding edge features, you know you're in the front line, you find bugs, it's not surprising.
The only bugs I've found in cutting edge features are the following:
- Nvidia: When persistent buffers were first released, they had forgotten to remove the check to use the buffer while it was mapped (which was the whole point), so they were useless. (Fixed)
- AMD: BPTC texture compression works, but can't be uploaded with glCompressedTexSubImage() as that throws an error.
- Intel: glMultiDrawIndirect() does not work if you pass in an IntBuffer with commands instead of uploading them to the indirect draw buffer VBO.
All other bugs were in really old features:
- Intel: Rendering to a cube map using an FBO always made the result end up on the first face (X+), regardless of which face you bound to the FBO. (Fixed)
- Intel: Their GLSL compiler was pretty much one huge bug.
threw unrelated errors all over the place. (Fixed)
- Intel: 4x3 matrices multiplied with a vec4 resulted in a vec4 while it should result in a vec3. (Fixed)
- AMD: Sometimes on older GPUs the result of FBO rendering becomes grayscale. I have no idea. (Fixed in newer GPUs at least)
- AMD: Allocating texture mipmaps in reverse order (Allocate level 10, upload level 10, allocate level 9, upload level 9, ...) hard locks the GPU. You need to allocate all mipmaps before you start uploading to them.
- AMD: Not sure if this is a bug, but depth testing against a depth buffer with depth writing disabled and reading the same depth buffer in the shader causes undefined results on AMD cards only.
These are the ones I can remember right now anyway. This is why I like Nvidia's drivers, by the way.
Almost everyone on this forum have at at least one point in their life worked with OpenGL, either directly or indirectly. Some of us likes to go deep and use OpenGL directly through LWJGL or LibGDX
LibGDX is a middle-level API and there are other actively maintained Java bindings for the OpenGL and/or OpenGL-ES APIs including JGLFW (used in LibGDX), Android OpenGL and JOGL (JogAmp).
while others (a probable majority) prefer the increased productivity of abstractions of OpenGL like LibGDX's 2D support, JMonkeyEngine or even Java2D with OpenGL acceleration.
The build-in Java2D with OpenGL acceleration isn't very optimized and it drives Java2D performance inconsistent. Slick2D, Golden T Game Engine (GTGE) and GLG2D are more efficient.
Those examples were not meant to be exhaustive. I'm only saying that no matter how your render stuff, OpenGL matters to you since pretty much everything (except unaccelerated Java2D of course) relies on OpenGL.
OpenGL is used a lot in scientific visualization and in CAD softwares too.
Maybe you should mention that the situation is quite different in mobile environments. Intel hardware is still far behind when it deals with offscreen rendering.
I did mention that OpenGL's use in other places is what made them decide to add so much backwards compatibility.
Sadly, the existence of the compatibility mode has encouraged many important industrial customers of the graphics cards vendors (CAD programs and other 3D programs) to become dependent on the compatibility mode, so it's essentially here to stay.
I can't say much about the mobile market since I've never developed stuff for it, but I do know that OpenGLES 2 is essentially OpenGL 3 without compatibility mode. Is that what you meant?
I don't think about "market shares" and things like that but I have worked as an engineer in computer science specialized in 2D/3D visualization for more than 7 years and we are numerous to be mostly satisfied by the way OpenGL has evolved even though the slowness of some decision makers were really annoying. I prefer the evolution with a certain continuity rather than brutal questionable changes. Microsoft isn't a good example, it is very good at creating brand new APIs that only work with one or two versions of Windows and abandoning them. 2 softwares on which I worked already existed in the nineties and not all corporations can afford rewriting its rendering code every three years. OpenGL isn't only for games, it can't be designed only to please some game programmers.
I know that almost nobody agrees with me about that here but I prefer fighting against planned obsolescence. What theagentd wrote isn't apolitical. "Science without conscience is but the ruin of the soul" (François Rabelais
I'm not entirely sure I understood what you're saying. You're saying that I'm not taking all applications of OpenGL into account?
Spasi talked about regal. JOGL provides immediate mode and fixed pipeline emulation too in ImmModeSink and PMVMatrix which is very useful when writing applications compatible with both OpenGL and OpenGL-ES.
This is the exact reason why we don't need driver implemented immediate mode anymore. It took me just a few hours to write a decent clone of immediate mode with support for matrices, colors and texture coordinates. It even takes advantage of persistently mapped buffers to upload the vertex data if they're supported by the driver. Sure, it's probably not as fast as the driver optimized immediate mode, but frankly, if you're using immediate mode you don't care about CPU performance in the first place.
I believe that the OpenGL drivers have too many features which slows down development of them and increases the number of bugs. If the OpenGL spec only contained the bare minimum required to do everything it currently does, it'd shift the load away from the driver developers and let them focus on optimizing the drivers and more quickly adopt new functionality. The lack of older "features" can be easily implemented by for example open source libraries that expose an API that's more familiar for people coming from older versions of OpenGL, and I believe that it would not be a significant effort for them to implement the stuff that they need. The important thing here is that we'd at least get rid of the completely unused game related features, like fixed functionality multitexturing and lighting.
I think that it's clear that the game industry is pretty open to this mentality of quickly deprecating old features. See how quickly developers jumped on to Mantle for example. Maybe you're right though. Maybe what we really need isn't a new OpenGL version, but a version of OpenGL that is specifically made for games. But that's pretty much what OpenGL 5 SHOULD be. OpenGL 5 most likely won't have any new hardware features. If they completely drop backwards compatibility, it'd essentially be the same functionality as OpenGL 4 but with an API targeted for games. If the "game version" of OpenGL continued to build on the new OpenGL 5, we'd essentially get what we want from OpenGL 5. Non-game applications could still use OpenGL 4, with new features introduced as extensions over time. This wouldn't necessarily decrease the load on driver developers, but it would make the game version of OpenGL faster to develop and maintain.