5 ms·

Opengl jumped from 2 to 3 because hardware changed. It doesn't mean the old API failed or was a mistake, it did the job it was intended to do, and then they ne

Opengl jumped from 2 to 3 because hardware changed. It doesn't mean the old API failed or was a mistake, it did the job it was intended to do, and then they needed it to do something radically different.

jfrunyon 5y ago
They failed to predict the future hardware. A failure isn't always a bad thing. Sometimes it's the best thing possible.
- Macha 5y ago
  Stating that they failed to predict the future hardware implies that they should or could have. Is this true? Maybe, maybe not, I'm neither a GPU driver write or a hardware writer, but I suspect no software writer in 1997 was going to predict the hardware of 2008.
- seoaeu 5y ago
  Predicting the future wasn't the objective. The hardware of that time couldn't have supported OpenGL 3 even if they'd wanted to
- ratww 5y ago
  Actually they didn't. It was still backwards compatible, so the number change would be unnecessary in semver.
badsectoracula 5y ago
OpenGL 3 is backwards compatible with 2 itself being backwards compatible with 1, etc. (ignoring the whole profiles thing which was a mistake and aside from Apple who went their own way with Metal, everyone else eventually agreed with that) as is 4. Also OpenGL 1.x didn't map to the underlying hardware even considering SGI, a lot of stuff was done on the CPU. The only time OpenGL matched the underlying hardware was around GeForce 2 and AFAIK that was really matching Nvidia's hardware - before and after that little window, OpenGL was its own abstraction. But of course OpenGL is a very good example of an API done right (especially before Khronos took over and made a mess out of it): it did a reasonably good prediction for the future while providing a good API for the present (at the time) and even when the underlying hardware changed considerably, it still remains a very useful API with a reasonable mapping and its extension system allows it to take advantage of new hardware features without breaking existing code. While i do not think Khronos did a good job on OpenGL, at least they did the right thing by making Vulkan a separate API instead of calling it "OpenGL 5", allowing the two APIs to coexist and not break any existing code. After all Vulkan is fine (even if not to my taste, it is unnecessarily oververbose and pretends to be a low level API when it isn't) if you absolutely want the best performance from a hardware abstraction API while OpenGL is still around when you do not need that and want something more user (programmer) friendly instead (though do not get me wrong, depending on what you do, you can extract a lot of performance out of OpenGL, though after some point you may need to switch to Vulkan).

jfrunyon 5y ago

They failed to predict the future hardware. A failure isn't always a bad thing. Sometimes it's the best thing possible.

Macha 5y ago
Stating that they failed to predict the future hardware implies that they should or could have. Is this true? Maybe, maybe not, I'm neither a GPU driver write or a hardware writer, but I suspect no software writer in 1997 was going to predict the hardware of 2008.
seoaeu 5y ago
Predicting the future wasn't the objective. The hardware of that time couldn't have supported OpenGL 3 even if they'd wanted to
ratww 5y ago
Actually they didn't. It was still backwards compatible, so the number change would be unnecessary in semver.

badsectoracula 5y ago

OpenGL 3 is backwards compatible with 2 itself being backwards compatible with 1, etc. (ignoring the whole profiles thing which was a mistake and aside from Apple who went their own way with Metal, everyone else eventually agreed with that) as is 4. Also OpenGL 1.x didn't map to the underlying hardware even considering SGI, a lot of stuff was done on the CPU. The only time OpenGL matched the underlying hardware was around GeForce 2 and AFAIK that was really matching Nvidia's hardware - before and after that little window, OpenGL was its own abstraction. But of course OpenGL is a very good example of an API done right (especially before Khronos took over and made a mess out of it): it did a reasonably good prediction for the future while providing a good API for the present (at the time) and even when the underlying hardware changed considerably, it still remains a very useful API with a reasonable mapping and its extension system allows it to take advantage of new hardware features without breaking existing code. While i do not think Khronos did a good job on OpenGL, at least they did the right thing by making Vulkan a separate API instead of calling it "OpenGL 5", allowing the two APIs to coexist and not break any existing code. After all Vulkan is fine (even if not to my taste, it is unnecessarily oververbose and pretends to be a low level API when it isn't) if you absolutely want the best performance from a hardware abstraction API while OpenGL is still around when you do not need that and want something more user (programmer) friendly instead (though do not get me wrong, depending on what you do, you can extract a lot of performance out of OpenGL, though after some point you may need to switch to Vulkan).