3 ms·

* It costs money to document. * It costs money to implement. Three days for a lone coder, much more than that for a careful consistent development process. *

* It costs money to document. * It costs money to implement. Three days for a lone coder, much more than that for a careful consistent development process. * It costs money to develop regression and validation tests. * It costs money to test, including collecting all the different hardware it needs to be tested on. * It costs money to fix bugs in it. * It costs money to answer questions from developers about it. * These costs are multiplied by every future version that will continue to support it. * These costs are multiplied by the many vendors that will be required to implement it. * Some of these costs are multiplied by every language that will support bindings to the API. * It costs code space in embedded devices. * It costs as much as a vendor wants to spend trying to make it perform as fast as possible. * It costs conceptual complexity in developers' heads. * It costs developers when they inadvertently do things the old inefficient way. * It costs reputation when somebody compares benchmarks of your product using the old inefficient way against another vendor's product using the new recommended way. * Requirements to continually support it at the same level of performance constrain your choices when developing new hardware. * Sometimes it costs precious die space which could be better used for other things. * The inefficiency sometimes increases power consumption and reduces battery life. * Users are disappointed if every version of new hardware doesn't run the old inefficient code even faster than the previous version. So if it doesn't have a real need to be there in ES 1.0 then, yes, it is actively damaging and should be thrown out in the rewrite.

bigiain 14y ago
While that's all true - it completely ignores the externalities. It cost Jamie 3 or 4 attempts and eventually 3 days work to get his unbroken code running on the new OpenGL version. What's the multiplier needed to account for the cost this change incurred for all the other developers who wrote code using OpenGL before ES? Sure, maintaining backwards compatibility is costly for a project like OpenGL. But if you choose _not_ to maintain backwards compatibility, for whatever reason, and then someone shows that your reasoning is bogus by reimplementing the old API calls in 3 days, you should expect to get called "idiots". (And you then should either be sure enough in your convictions that you know jwz is wrong, or take it on the chin and say "Hey, we fucked _that_ one up. Mind if we include your code in our next release?")
- deleted 14y ago
  [deleted]
- marshray 14y ago
  This is a good question, and if you look a few posts up I started this comment tree by addressing it: > if we compare the massive number of newly written OpenGL ES applications to all the old OpenGL 1.x fixed pipeline apps, the latter seem insignificant. It was a design judgment they made and I think it was the right one. > by reimplementing the old API calls in 3 days JWZ did not produce a complete production-quality set of OpenGL 1.x compatibility APIs in 3 days. I'm going to guess without looking at his code that he didn't even write regression tests for the calls that he did implement. What JWZ did was 3 days of possibly great coding, but that's only a tiny part of what needs to be done to ship new APIs in something like OpenGL.
- msbarnett 14y ago
  > While that's all true - it completely ignores the externalities. It cost Jamie 3 or 4 attempts and eventually 3 days work to get his unbroken code running on the new OpenGL version. What's the multiplier needed to account for the cost this change incurred for all the other developers who wrote code using OpenGL before ES? This is ignoring an awful lot of reality. Like, that OpenGL isn't a project that ships one software stack, but a standard managed by a group and voluntarily implemented by graphics vendors. The Khronos group exists to negotiate between vendors and create a spec they're willing to implement, not to dictate to them a spec they hate and will ignore. There was a near riot when the OpenGL (non-ES) 3.0 was announced; many vendors were seriously pissed off that it didn't drop Immediate Mode and the the fixed pipeline and that they had to sink enormous amounts of time into writing and maintaining a compatibility layer on top of modern GPUs for shit that had been deprecated for damn near a decade. That meant not just writing an Immediate Mode shim for a tiny subset of OpenGL 1.3 like JWZ (and like countless other have done in the past), but doing shit like generating shaders on the fly based on the current state of the emulated fixed function pipeline, and making sure to cover all of the bizarre corner case interactions between all of that old fixed function garbage and threading and any new calls the program happened to mix in. Vendors were ready to walk away from OpenGL over this. That's why the OpenGL 3.1 spec dropped the fixed pipeline like a hot potato and doesn't require that vendors ship a compatibility profile for the old crap. Now, what if, back in 2003 when the decision to not include this stuff in OpenGL ES 1.0 was made, they'd released a spec requiring mobile vendors to do the same thing? What would the cost to JWZ and his project, and all other developers who wrote OpenGL before ES, have been if the mobile vendors had collectively told Khronos to fuck off? If OpenGL ES didn't even exist as a target for a shim, because there was no way in hell mobile vendors were going to ship a multi-meg driver that had to generate code on the fly, on the off chance anyone ever wanted to ship AutoCAD for hardware that barely had enough RAM to fit the driver? Because there was certainly no guarantee, at the time, that OpenGL ES was going to become the standard for mobile graphics. It happened only because the standard that was proposed was something that the vendors were willing to ship. > Sure, maintaining backwards compatibility is costly for a project like OpenGL. But if you choose _not_ to maintain backwards compatibility, for whatever reason, and then someone shows that your reasoning is bogus by reimplementing the old API calls in 3 days, you should expect to get called "idiots". (And you then should either be sure enough in your convictions that you know jwz is wrong, or take it on the chin and say "Hey, we fucked _that_ one up. Mind if we include your code in our next release?") Oh come off it. He didn't reimplement ALL of OpenGL in 3 days. He reimplemented the tiny subset of calls, with the precise semantics (and only the precise semantics) his program needed, in 3 days. That's a far cry from shipping the entire behemoth that is a fully back-compatible OpenGL stack. And he's not the first guy to do this, or the 5th. I've got books on the shelf behind me with small Immediate Mode shims in their appendixes for people who want to do it "the old way". I've seen code to do it in forums and in repos. It's dead easy. The Khronos group doesn't see this shit and think "damn, we fucked up". They think "Good. We gave vendors a decently small spec that they were willing to implement, allowing OpenGL ES to become the standard in mobile graphics, but we still managed to base it on well-chosen primatives that people like JWZ can use to build higher-level interfaces around if they choose".

bigiain 14y ago

While that's all true - it completely ignores the externalities. It cost Jamie 3 or 4 attempts and eventually 3 days work to get his unbroken code running on the new OpenGL version. What's the multiplier needed to account for the cost this change incurred for all the other developers who wrote code using OpenGL before ES? Sure, maintaining backwards compatibility is costly for a project like OpenGL. But if you choose _not_ to maintain backwards compatibility, for whatever reason, and then someone shows that your reasoning is bogus by reimplementing the old API calls in 3 days, you should expect to get called "idiots". (And you then should either be sure enough in your convictions that you know jwz is wrong, or take it on the chin and say "Hey, we fucked _that_ one up. Mind if we include your code in our next release?")

deleted 14y ago
[deleted]
marshray 14y ago
This is a good question, and if you look a few posts up I started this comment tree by addressing it: > if we compare the massive number of newly written OpenGL ES applications to all the old OpenGL 1.x fixed pipeline apps, the latter seem insignificant. It was a design judgment they made and I think it was the right one. > by reimplementing the old API calls in 3 days JWZ did not produce a complete production-quality set of OpenGL 1.x compatibility APIs in 3 days. I'm going to guess without looking at his code that he didn't even write regression tests for the calls that he did implement. What JWZ did was 3 days of possibly great coding, but that's only a tiny part of what needs to be done to ship new APIs in something like OpenGL.
msbarnett 14y ago
> While that's all true - it completely ignores the externalities. It cost Jamie 3 or 4 attempts and eventually 3 days work to get his unbroken code running on the new OpenGL version. What's the multiplier needed to account for the cost this change incurred for all the other developers who wrote code using OpenGL before ES? This is ignoring an awful lot of reality. Like, that OpenGL isn't a project that ships one software stack, but a standard managed by a group and voluntarily implemented by graphics vendors. The Khronos group exists to negotiate between vendors and create a spec they're willing to implement, not to dictate to them a spec they hate and will ignore. There was a near riot when the OpenGL (non-ES) 3.0 was announced; many vendors were seriously pissed off that it didn't drop Immediate Mode and the the fixed pipeline and that they had to sink enormous amounts of time into writing and maintaining a compatibility layer on top of modern GPUs for shit that had been deprecated for damn near a decade. That meant not just writing an Immediate Mode shim for a tiny subset of OpenGL 1.3 like JWZ (and like countless other have done in the past), but doing shit like generating shaders on the fly based on the current state of the emulated fixed function pipeline, and making sure to cover all of the bizarre corner case interactions between all of that old fixed function garbage and threading and any new calls the program happened to mix in. Vendors were ready to walk away from OpenGL over this. That's why the OpenGL 3.1 spec dropped the fixed pipeline like a hot potato and doesn't require that vendors ship a compatibility profile for the old crap. Now, what if, back in 2003 when the decision to not include this stuff in OpenGL ES 1.0 was made, they'd released a spec requiring mobile vendors to do the same thing? What would the cost to JWZ and his project, and all other developers who wrote OpenGL before ES, have been if the mobile vendors had collectively told Khronos to fuck off? If OpenGL ES didn't even exist as a target for a shim, because there was no way in hell mobile vendors were going to ship a multi-meg driver that had to generate code on the fly, on the off chance anyone ever wanted to ship AutoCAD for hardware that barely had enough RAM to fit the driver? Because there was certainly no guarantee, at the time, that OpenGL ES was going to become the standard for mobile graphics. It happened only because the standard that was proposed was something that the vendors were willing to ship. > Sure, maintaining backwards compatibility is costly for a project like OpenGL. But if you choose _not_ to maintain backwards compatibility, for whatever reason, and then someone shows that your reasoning is bogus by reimplementing the old API calls in 3 days, you should expect to get called "idiots". (And you then should either be sure enough in your convictions that you know jwz is wrong, or take it on the chin and say "Hey, we fucked _that_ one up. Mind if we include your code in our next release?") Oh come off it. He didn't reimplement ALL of OpenGL in 3 days. He reimplemented the tiny subset of calls, with the precise semantics (and only the precise semantics) his program needed, in 3 days. That's a far cry from shipping the entire behemoth that is a fully back-compatible OpenGL stack. And he's not the first guy to do this, or the 5th. I've got books on the shelf behind me with small Immediate Mode shims in their appendixes for people who want to do it "the old way". I've seen code to do it in forums and in repos. It's dead easy. The Khronos group doesn't see this shit and think "damn, we fucked up". They think "Good. We gave vendors a decently small spec that they were willing to implement, allowing OpenGL ES to become the standard in mobile graphics, but we still managed to base it on well-chosen primatives that people like JWZ can use to build higher-level interfaces around if they choose".