Live data from Hacker News

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

jwz.org

41–50 of 225 posts

Re: If you were involved in the OpenGL ES specification, you are an idiot

#41
post #12

Earlier quoted context omitted.

An incremental only approach to design is non-design in my view. Nearly all design is incremental. That's how design works. That's partly why chairs are still recognizably chairs, and other useful stuff like that.

Quite true. But there is another word there "only".

I don't think jwz would have had a problem with it if you called it EmbeddedGL or PhoneGL instead of trading on the name of OpenGL. Like jwz I thought "Oh its OpenGL I've got code already that does most of what I want." only to find none of that code worked.

Re: If you were involved in the OpenGL ES specification, you are an idiot

#42
I don't think xscreensaver is a good example of valuable OpenGL 1.3 code that users want running on the iPhone. I think a person ought to have such an example before they start calling people idiots. Not to say that porting xscreensaver to the iPhone isn't cool, but it's only cool because it is anachronistic and whimsically impractical, like playing GameBoy games in a vintage arcade chassis in 2012.

There are a few things I couldn't figure out how to implement:

This after a year of percolation and three days (plus a few hours) of intense work by jwz. Given jwz's reputation as an insanely good programmer, I think this says a lot. As in, there's a nontrivial amount of work to do to claim near-compatibility with OpenGL 1.3, and an undetermined amount more work to claim true compatibility. Plus there may be more functionality from 1.4 and 1.5 to claim backwards compatibility with all of OpenGL 1.x. And all that to grant a (deservedly) dead desktop API new life on a mobile platform. No wonder they didn't bother.

Re: If you were involved in the OpenGL ES specification, you are an idiot

#43

OpenGL ES is not designed to be OpenGL. It has a different set of constraints. The point is to prune back the API for small devices - NOT - to make make migration of legacy code simple. For sure it would be nice if it came with a client side library to emulate OpenGL to assist in migration where people dont care about foot print size or perf. JWZ is a very smart guy and I respect his opinion, but he is coming from a…

Now that smartphones and tablets have respectable GPUs in them, is there any reason why they shouldn't implement the full OpenGL spec?

I thought the issue with immediate mode which prevented its inclusion (in ES) was that immediate mode is very inefficient for the CPU, resulting in increased battery drain on smartphones and tablets.

Re: If you were involved in the OpenGL ES specification, you are an idiot

#44
post #39

Earlier quoted context omitted.

Disclaimer: I've dabbled as a driver writer in a past life - but not OpenGL ES. The problem is a 100% compatibility layer is not necessarily easy nor valuable. The makers of OpenGL ES don't want a lifetime of maintaining someone elses problem. Also there is a line where you cross and you lose hardware acceleration and the mapping breaks down. Their charter is to make a new lightweight API that meets the needs of devi…

Warm fuzzies for calling us Videologic instead of Imagination or PowerVR. Your description of the layers between an application and execution on the graphics core on iOS is pretty good. There's nothing between driver and hardware though. As for why OpenGL ES is different to OpenGL, it's documented in myriad places. The resulting API might be bad in many ways, but it was never designed to allow easy porting of OpenGL…

Long live mgl/sgl! The mention about hardware dedupe/filtering was more a hat tip to culling sub pixel triangles and early culling of obscured primitives that seems to happen on many chips these days :)

Re: If you were involved in the OpenGL ES specification, you are an idiot

#45
The thing that particularly bothers me about this post:

> People defend this decision by saying that they "had" to do it, because the fixed function pipeline is terribly inefficient on modern GPUs or some such nonsense. These people don't know what they're talking about, because the contour of the API has absolutely fuck-all to do with what goes over the wire.

As far as I can tell from what he's written, all he's done is forcibly enact the same inefficiencies that the paradigm shift away from immediate-mode rendering was intended to eliminate. The contour of the API in this case has a great deal to do with what goes over the wire: most critically, correctly-designed OpenGL ES programs will not retransmit static geometry to the GPU every single frame.

Re: If you were involved in the OpenGL ES specification, you are an idiot

#46

OpenGL ES is not designed to be OpenGL. It has a different set of constraints. The point is to prune back the API for small devices - NOT - to make make migration of legacy code simple. For sure it would be nice if it came with a client side library to emulate OpenGL to assist in migration where people dont care about foot print size or perf. JWZ is a very smart guy and I respect his opinion, but he is coming from a…

> In my experience, backwards compatible APIs and languages are what makes development a pain going forward

That's the exact opposite of my experience! Libraries that are constantly changing their APIs produce the vast majority of my work.

Re: If you were involved in the OpenGL ES specification, you are an idiot

#47

Earlier quoted context omitted.

Now that smartphones and tablets have respectable GPUs in them, is there any reason why they shouldn't implement the full OpenGL spec?

I thought the issue with immediate mode which prevented its inclusion (in ES) was that immediate mode is very inefficient for the CPU, resulting in increased battery drain on smartphones and tablets.

All rendering is in some capacity incremental. Sometimes you keep that (incrementally constructed) list of vertices around, of course.

If you look at the old immediate mode API, fundamentally, you're just passing in some floats that it copies into a buffer. This is not an expensive thing to do. It's not free, sure, but CPUs aren't bad at it. It's just some overhead compared to if you were to hand an entire buffer (in a known format) full of floats to the GPU at once. Some extra function calls, etc. If your app is only drawing a few thousand vertices, the overhead difference here is trivial... and if your app is drawing a million vertices, you won't be using immediate mode anyway.

Re: If you were involved in the OpenGL ES specification, you are an idiot

#48
Just some numbers, based on my hardware:

Lion OS X install on disk: 7GB

iOS 5.0.1 install: 1.7GB

My MacBook's RAM: 8GB

iPod Touch: 512KB

MB's disk size: 100GB

iPod Touch: 8GB

So: Maybe they removed 80% of the API in general because the iPhone/iPod touch is only 10-20% of a normal computer? Something had to go.

Re: If you were involved in the OpenGL ES specification, you are an idiot

#49
post #39

Earlier quoted context omitted.

Warm fuzzies for calling us Videologic instead of Imagination or PowerVR. Your description of the layers between an application and execution on the graphics core on iOS is pretty good. There's nothing between driver and hardware though. As for why OpenGL ES is different to OpenGL, it's documented in myriad places. The resulting API might be bad in many ways, but it was never designed to allow easy porting of OpenGL…

Long live mgl/sgl! The mention about hardware dedupe/filtering was more a hat tip to culling sub pixel triangles and early culling of obscured primitives that seems to happen on many chips these days :)

We tip our hat right back! It happens to be pixel-perfect for us in this context, and it's a large part of why we draw so efficiently. Oh, and I still have a working m3D-based system that plays SGL games under DOS!

Re: If you were involved in the OpenGL ES specification, you are an idiot

#50
post #8

Earlier quoted context omitted.

It sounds like it. He could just package it up a bit better, release it and render this whole discussion moot.

And OpenGL ES only existed for 5 years before someone came along as was pissed off enough to do it! Edit: 5 years was OpenGL ES 2.0, can't seem to find a date for OpenGL ES 1.0, but suffice to say it was around for quite some time.

> And OpenGL ES only existed for 5 years before someone came along as was pissed off enough to do it!

Eh, he's hardly the first guy to do this. Appendix D of my copy of Graphics Shaders: Theory and Practice contains a simple reimplementation of Immediate Mode on top of VBOs for people with a burning desire to prototype their code as if it were 1998 again.

And in reality, in most modern OpenGL (non-ES) implementations, the actual hardware-backed bits basically look like the OpenGL ES API, and all of the legacy cruft is implemented in exactly the same kind of software shim.

Post reply on HN