Ruthless dropping of backward compatibility is a good thing in certain circumstances. I'm not saying this blog post is one of those cases, but for example Microsoft Windows pays a huge price in complexity, cruft, bloat and performance to obsessively maintain backward compatibility. Python 3 has dropped backward compatibility and experiencing significant pain for the decision but after getting to Python 3 it looks arguably like a better, cleaner, more consistent language.
If you were involved in the OpenGL ES specification, you are an idiot
11–20 of 225 posts
Re: If you were involved in the OpenGL ES specification, you are an idiot
#12OpenGL 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…
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.
Re: If you were involved in the OpenGL ES specification, you are an idiot
#13:) Back in 2008 I helped JWZ port daliclock to the iPhone and once that was working I proposed a port of xscreensaver. He couldn't imagine ever wanting screensavers on an iPhone at the time. Guess he changed his mind.
I also was the one that opened his eyes to the differences between OpenGL and OpenGL ES it seems. I apologize.
Re: If you were involved in the OpenGL ES specification, you are an idiot
#14Earlier quoted context omitted.
Isn't that precisely what he did here? (note, I know nothing about nothing when it comes to graphics/OpenGL stuff)
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.
Re: If you were involved in the OpenGL ES specification, you are an idiot
#15This rant should probably say "my iPhone could run a full OpenGL implementation, and instead I'm provided a subset. I proved that it could run full OpenGL by writing most of the missing parts".
"(OpenGL ES) is a subset of the OpenGL" according to http://en.wikipedia.org/wiki/OpenGL_ES
Re: If you were involved in the OpenGL ES specification, you are an idiot
#16OpenGL 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…
Core APIs and languages do not expand at an "unfathomable rate". How long as the Berkeley sockets API been with us? TCP/IP? Twos-complement arithmetic? Do you honestly think that those are going to go away for the sake of some vaguely hand-waved "wider implications" and "idea promotion"?
OpenGL has been, like it or not, the only open, widely-adopted, non-proprietary 3D graphics API around for quite some time now. Enabling it on mobile devices wasn't exactly a sea-change requiring tossing all compatibility with the past in order to make progress (especially not as mobile GPUs continue to get more powerful).
jwz's point was that this could have very simply been included as an optional compatibility layer, which he then went and did.
[edited to put in the "not" in the first sentence that my fingers skipped over, which kinda changed the whole argument]
Re: If you were involved in the OpenGL ES specification, you are an idiot
#17OpenGL 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…
>It has a different set of constraints. The point is to prune back the API for small devices
I came here to say something along these lines, but right now I'm limited on time so I don't have time to go into specific examples.
In OpenGL, there might be 5 ways to do something. Three of them are very much suboptimal, one way worked but was incredibly kludgy to write, and one was performant and pretty clean.
With OpenGL ES, they got rid of all the suboptimal and kludgy methods. The benefit today is if you write an OpenGL ES application, porting it to OpenGL nowadays is pretty easy. The other way around? Yes, that can be tremendously difficult. Honestly, I wish a lot more in OpenGL 3.x and 4.x was deprecated. Working with ES and the reduced extension hell is a big step up from the mess the full OpenGL API can be.
Re: If you were involved in the OpenGL ES specification, you are an idiot
#18Related interesting read if you haven't, the brouhaha a few years ago over OpenGL 3.0 preferring to support CAD/CAM programs over games.
http://www.tomshardware.com/reviews/opengl-directx,2019.html
Re: If you were involved in the OpenGL ES specification, you are an idiot
#19One committee, ten years. One jwz, three days.
This is the stuff "10X" is made of.
Re: If you were involved in the OpenGL ES specification, you are an idiot
#20Earlier quoted context omitted.
Isn't that precisely what he did here? (note, I know nothing about nothing when it comes to graphics/OpenGL stuff)
I believe the authors original point is why not provide the shim support as part of OpenGL ES in the first place? Stick a big red sticker on it saying here be dragons, but it's obviously not an impossible task. The funny thing is, his shim is actually useful for speeding up code (in theory, this may already be done) on normal OpenGL. (For anything using these interfaces)
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 device manufacturers and low level app developers. As soon as they adopt 100% compatability at their core or even offering an additional adapation layer they will be taking time and effort from their focus.
In this instance any OpenGL shim is an Apple responsibility as they are the SDK and environment provider. Apple and Videologic need to nut that one out themselves.
As to a shim speeding up code its essentially comes down to any impedance mismatch that may occur between an application writer and the API. This is identical to buffered versus non buffered IO and whose responsibility is it to filter idempotent operations.
When you look at a typical call stack. You'll see an application (potentially caching and filtering state), calling a library shim (potentially caching and filtering state), queuing and batching calls to a device driver (potentially caching and filtering state), dispatching to a management layer (potentially caching and filtering state), and so on, eventually getting to a graphics card processor potentially caching and filtering state and finally to a pipeline or set of functional blocks (which may have some idempotent de-duping as well).
Again how this is communicated to the developer or structured is an issue of the platform provider.
Apple can choose to say we optimize nothing (ie add no fat, waste no extra cycles) its up to you to dispatch minimal state changes, or we optimize a,b & c... - don't repeat this work, but maybe add optimizations for d, e &f... Thats something they need to document and advise on for their platform. Its not part of most standards.