5 ms·

It's not like there's this massive base of OpenGL code just waiting to be ported to embedded devices if there were just a few more API calls. Yes, there's glxge

It's not like there's this massive base of OpenGL code just waiting to be ported to embedded devices if there were just a few more API calls. Yes, there's glxgears, screensavers, and handful of open source games. You could probably get some old CAD programs to run on your Android. But 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. As he so ably demonstrates, it's just not that hard to port the older apps either. This "All you engineers are idiots because I had to work THREE WHOLE DAYS to port this 20 year old code to an iPhone" just sounds childish and silly. The OpenGL board made the right decision for ES.

malachismith 14y ago
You kind of miss the point. This is a philosophical argument ILLUSTRATED through OpenGL and a port. To quote, "thou shalt not break working code"
- debacle 14y ago
  If your architectures are completely different, you're going to have to break some fucking code. That's just the way it is.
  - justinhj 14y ago
    The article showed the opposite. That there was no need to break existing code.
    - jbrechtel 14y ago
      Wasn't there? There were a number of functions he didn't port. He ended up with a subset of OpenGL 1.3. Maybe that subset wasn't worth the effort?
      - marshray 14y ago
        That's just what OpenGL needs right? Yet another incomplete ad-hoc extended subset of OpenGL 1.x functionality lacking documentation, regression and performance tests, a stable and committed team of maintainers, ...
    - msbarnett 14y ago
      It showed that some existing code with a shim containing a reimplementation of a small subset of OpenGL 1.3 could be made to run acceptably fast on a rather beefy example of 2012's mobile hardware. It certainly did not show that there was no need to exclude those calls back in 2003 when they were originally not included in OpenGL ES.
- marshray 14y ago
  No, I understand that point. I just don't agree with it in this case. * "thou shalt not break working code". That's not some Universal Code of Software Engineering, that's just something he made up. * No one in their right mind would expect you could port 20 year old C using OpenGL 1.x code to an iPhone with no effort. * There are plenty of reasons APIs can benefit from breaking changes. Security fixes, major architectural improvements, platform porting, even general evolution and modernization. The question is always one of cost/benefit, relative pain vs relative gain. * Sorry JWZ, but your X screensaver project is actually not an overriding concern driving the evolution of OpenGL ES. * I didn't mention it again because so many other have pointed this out, but this isn't even the same API. OpenGL ES is not the same thing as OpenGL 1.x. * Changing the major version number is a common and accepted way to indicate breaking changes are present in an API. The OpenGL board went even farther and gave it a different name and a different versioning scheme specifically because it is different.
  - kevinpet 14y ago
    "Sorry JWZ, but your X screensaver project is actually not an overriding concern driving the evolution of OpenGL ES." Seriously, if you think that's a valid response, then you did not understand his point. Repeating something does not make it any more valid an argument.
    - marshray 14y ago
      OK I re-read his post. I think I understand his point. He has a something of a valid point, but what he is raising are considerations, not overriding principles. If he wants to write his code by treating these as "thou shalt not" type laws, that's fine. He can criticize others for not following the same principles. But calling a bunch of top graphics engineers "idiots" because they looked at a vastly different engineering problem with different priorities and arrived at a different design is rude and ignorant and it reflects poorly on JWZ. JWZ makes this statement: "Your users have code that works." He is simply wrong about this. * No one had working OpenGL ES code before OpenGL ES was standardized. This is by definition and one cannot argue the definition of OpenGL ES with the OpenGL standardization body itself. * Even if you wanted to accept the mistake of thinking of the existing OpenGL 1.x codebase was supposed to be forwards compatible with ES, it's not true in the main. The amount of existing OpenGL 1.x that could plausibly benefit from being ported to embedded devices is insignificant. Seriously, JWZ may have just ported most of it. This is what I mean by "X screensaver project is actually not an overriding concern driving the evolution of OpenGL ES." JWZ seems to think that his principles of software engineering are the only correct way to look at it. He goes so far as to say "If you don't agree with that, then please, get out of the software industry right now. Find another line of work. Please." To support such absolute claims and broad sweeping statements he uses a toy porting project that takes three days. The vendors who participate in the OpenGL ARB are concerned with projects that take 3 years and APIs that persist for more than 20! Don't you think they actually might know a thing or two about APIs and engineering them for software? Don't you think they might know extremely well what the costs of failed backwards compatibility are? But that's OK, everybody scratches their head for a bit trying to sort out the different flavors of graphics APIs. Even single-vendor Direc3D has similar issues. If this is the most confusing thing about OpenGL to him and he can do something useful with OpenGL ES in his first three days of messing with it, he is a really really smart guy.
- rphlx 14y ago
  That is a noble goal, but it's one of hundreds of often-conflicting noble goals. It's not inherently wrong to design a toaster that fails to work as a refrigerator.
semanticist 14y ago
Except he didn't port his code to OpenGL ES - he ported the missing API from OpenGL 1.3 to OpenGL ES. If it takes one developer three days to implement the missing API, then perhaps it suggests that this API wasn't in any way damaging to the new system and could have been left in place originally?
- marshray 14y ago
  * 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?")

malachismith 14y ago

You kind of miss the point. This is a philosophical argument ILLUSTRATED through OpenGL and a port. To quote, "thou shalt not break working code"

debacle 14y ago
If your architectures are completely different, you're going to have to break some fucking code. That's just the way it is.
- justinhj 14y ago
  The article showed the opposite. That there was no need to break existing code.
  - jbrechtel 14y ago
    Wasn't there? There were a number of functions he didn't port. He ended up with a subset of OpenGL 1.3. Maybe that subset wasn't worth the effort?
    - marshray 14y ago
      That's just what OpenGL needs right? Yet another incomplete ad-hoc extended subset of OpenGL 1.x functionality lacking documentation, regression and performance tests, a stable and committed team of maintainers, ...
  - msbarnett 14y ago
    It showed that some existing code with a shim containing a reimplementation of a small subset of OpenGL 1.3 could be made to run acceptably fast on a rather beefy example of 2012's mobile hardware. It certainly did not show that there was no need to exclude those calls back in 2003 when they were originally not included in OpenGL ES.
marshray 14y ago
No, I understand that point. I just don't agree with it in this case. * "thou shalt not break working code". That's not some Universal Code of Software Engineering, that's just something he made up. * No one in their right mind would expect you could port 20 year old C using OpenGL 1.x code to an iPhone with no effort. * There are plenty of reasons APIs can benefit from breaking changes. Security fixes, major architectural improvements, platform porting, even general evolution and modernization. The question is always one of cost/benefit, relative pain vs relative gain. * Sorry JWZ, but your X screensaver project is actually not an overriding concern driving the evolution of OpenGL ES. * I didn't mention it again because so many other have pointed this out, but this isn't even the same API. OpenGL ES is not the same thing as OpenGL 1.x. * Changing the major version number is a common and accepted way to indicate breaking changes are present in an API. The OpenGL board went even farther and gave it a different name and a different versioning scheme specifically because it is different.
- kevinpet 14y ago
  "Sorry JWZ, but your X screensaver project is actually not an overriding concern driving the evolution of OpenGL ES." Seriously, if you think that's a valid response, then you did not understand his point. Repeating something does not make it any more valid an argument.
  - marshray 14y ago
    OK I re-read his post. I think I understand his point. He has a something of a valid point, but what he is raising are considerations, not overriding principles. If he wants to write his code by treating these as "thou shalt not" type laws, that's fine. He can criticize others for not following the same principles. But calling a bunch of top graphics engineers "idiots" because they looked at a vastly different engineering problem with different priorities and arrived at a different design is rude and ignorant and it reflects poorly on JWZ. JWZ makes this statement: "Your users have code that works." He is simply wrong about this. * No one had working OpenGL ES code before OpenGL ES was standardized. This is by definition and one cannot argue the definition of OpenGL ES with the OpenGL standardization body itself. * Even if you wanted to accept the mistake of thinking of the existing OpenGL 1.x codebase was supposed to be forwards compatible with ES, it's not true in the main. The amount of existing OpenGL 1.x that could plausibly benefit from being ported to embedded devices is insignificant. Seriously, JWZ may have just ported most of it. This is what I mean by "X screensaver project is actually not an overriding concern driving the evolution of OpenGL ES." JWZ seems to think that his principles of software engineering are the only correct way to look at it. He goes so far as to say "If you don't agree with that, then please, get out of the software industry right now. Find another line of work. Please." To support such absolute claims and broad sweeping statements he uses a toy porting project that takes three days. The vendors who participate in the OpenGL ARB are concerned with projects that take 3 years and APIs that persist for more than 20! Don't you think they actually might know a thing or two about APIs and engineering them for software? Don't you think they might know extremely well what the costs of failed backwards compatibility are? But that's OK, everybody scratches their head for a bit trying to sort out the different flavors of graphics APIs. Even single-vendor Direc3D has similar issues. If this is the most confusing thing about OpenGL to him and he can do something useful with OpenGL ES in his first three days of messing with it, he is a really really smart guy.
rphlx 14y ago
That is a noble goal, but it's one of hundreds of often-conflicting noble goals. It's not inherently wrong to design a toaster that fails to work as a refrigerator.

semanticist 14y ago

Except he didn't port his code to OpenGL ES - he ported the missing API from OpenGL 1.3 to OpenGL ES. If it takes one developer three days to implement the missing API, then perhaps it suggests that this API wasn't in any way damaging to the new system and could have been left in place originally?

marshray 14y ago
* 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?")