Thursday, June 21, 2012

If you defend those involved in the OpenGL ES specification, you are an idiot

Jamie Zawinski (jwz), famed hacker and nightclub owner, has called a lot of people idiots over the years.  Just now he called out those who wrote the OpenGL ES specs.  I wholeheartedly agree with him; I’ve run into the same hassle before e.g. OpenGLES I want my quads back

Who’s an idiot?

The reception to Jamie’s sentiment on-line has been blistering.  There’s a very vocal bunch on Hacker News and reddit who disagree strongly (with whatever they understand Jamie’s point to be).

Its hard to say if its a minority or majority because the non-vocal ones don’t get counted.  Most who read these sites don’t comment; I have stats.  So lets give everyone the benefit of the doubt and think its just a misguided, inexperienced minority who are idiots ;)

Why are they idiots?

Jamie’s argument is that OpenGL ES, being a big pruning-down of OpenGL, has stopped old OpenGL apps running on new platforms and that this is a stupid, stupid thing.

This isn’t that Jamie is mistaking OpenGL ES for OpenGL!  I was on the sidelines when OpenGL ES was hatched and the whole point is that we shouldn’t have OpenGL ES!  We should just have had OpenGL.

I used to be a graphics stack architect and then technical product manager for graphics at a smart-phone platform back in the mid 2000s.  I’m not going to argue from authority - I was a super-small side-sitter who was in no way ‘in’ nor involved with the Khronos committee members.  But I did know a few members (whom I should apologise in advance to) and had quite a few more visit me.  Khronos Group is where these committees thrash out these standards.

There is only one reason that these industry committees threw out OpenGL backwards compatibility: the interests of the committee member companies.

The reason that the apologists trot out is technical though, so I’ll elaborate on that at the end.

Committee member company self-interest:

Surprise surprise the committee members are overwhelmingly representing the interests of the GPU makers.  Their mission is to subtly improve their position with regards the competition they are sitting around a table with e.g. by pushing things slightly in a direction that their hardware does well and pushing away from - by deprecation, omission - those areas that would require investment.

OpenGL ES was hatched to ensure that the devices could be labeled “OpenGL” without actually having to those mobile phone GPU companies having to invest engineering time in making it so! 

And the motivation was money, not technical purity nor vision.

And the kind of people who get sent to committees are often not the pragmatic get-things-done type of people.  Companies quickly build “system architecture” teams to put the dangerous architecture astronauts as far away from the get-things-done teams as possible, and give them tasks like sitting on standards committees to occupy them.

So you end up with a bunch of people sitting around conference tables and in email chains who are not the kind of people trying to actually ship 3rd party software nor even the next iteration of the actual mobile phone OS.   If those doers ever turn up at the table, they’d be treated as a curiosity at best and dangerously short-sighted at worst.

The thing is, the people participating probably don’t see their bias.  They probably think they contribute for the greater good.

Now these architecture astronauts may have brought the technical argument that Jamie thinks so weak.  They may believe that the old way of doing things is slow:

But isn’t there an insurmountable technical problem?

Well, hmm, `glVertex3f` is a call into a DLL provided by the GPU maker (or OS platform).  The key thing is, some code can do something with that vertex in local code.  It doesn’t have to be an expensive syscall or something at that point.  It can be put into an array to be shipped somewhere when swap-buffers is called.

Chrome’s native client does just this.  And the only problem you have with this model is `glGetError`.

Symbian moved from immediate-mode drawing to retained-mode drawing, which is analogous, with very few bumps.

Jamie’s code for stuffing OpenGL draw calls into arrays and such did it too.  And it took him 3 days to write.

The gap between supporting the old, legacy, deprecated OpenGL and the new way of doing things is astonishingly small and the barriers are largely imaginary.  And the performance - given that these programs are by definition built to run on a previous generation hardware - is actually very good.

The drivers have to pick the right shaders to optimise the fixed-function pipeline based on what you’re doing.  But that’s the kind of problem that’s quite solvable.

You can take any insurmountable problem with supporting OpenGL 1.x well and work out how to overcome it without sacrificing performance, I promise you.

So really OpenGL ES can be seen as a variation on the CADT development model, although the age-group and motives might not align.

Now let me rip into the GPU maker’s approach to software; I have to pick that out as a third dynamic here:

I look at the current driver stacks from all the manufacturers and shake my head in dismay.

I’m never going to get an invite to look around an NVidia offfice (after this) but I can imagine how its run.  I’ve seen it a gazillion times at various hardware and driver suppliers I’ve met in the past, and I’ve worked for some really dysfunctional companies in this regard like the old Motorola.

There will be schedules, there will be plans to leverage previously written code and contracted-out code.  And, interestingly, there’ll be too many programmers.  But they’ll all be viewed as interchangeable cogs with little real deep wider respect for them.

What there won’t be programmers being allowed to be in the zone and do things properly.  There won’t be programmers allowed to excel.

The driver in upper management will be to have a driver for the next card.  There’ll be no interest in actually making the drivers for existing, already sold, cards better.

You’ve gotta respect any programmers fighting the good fight for us 3rd parties in these companies.

What’s the big deal?

Jamie says it great:

If there are old features that you would like to discourage the use of, then you mark them as obsolete — but you do not remove them because thou shalt not break working code.

If you don’t agree with that, then please, get out of the software industry right now. Find another line of work. Please.

But don’t think its the its programmers at fault; I blame their companies.  And the sad thing is?  OpenGL support across phones, desktop and so on is in really bad shape.  However much I find Direct3D to actually run 1.6x slower than OpenGL, its not flaky, and its not nearly as moving a target.

But we still got 3D on the first smart-phones, right?

Who was to be the very first ‘customer’ of OpenGL on the mobile?  The game ports!

And when OpenGL did turn up on the mobile, it wasn’t actually OpenGL; it was OpenGL ES.

Suddenly ports were more like rewrites and the costs changed dramatically and you didn’t get to play great 3D games on your phone after all.

I recall much swearing and teeth gnashing behind closed doors with phone manufacturers.  Bloody standards bodies, who do they think they serve?  Oh, right…

Notes

  1. mobile-phone-specifications reblogged this from williamedwardscoder
  2. williamedwardscoder posted this

 ↓ click the "share" button below!