3 ms·

OpenGL ES was a way to pass the buck to developers so companies could save money. Since the OpenGL fixed function pipeline could have been implemented to some

OpenGL ES was a way to pass the buck to developers so companies could save money. Since the OpenGL fixed function pipeline could have been implemented to some degree above OpenGL ES (but never was), it forced developers to learn the entirety of rendering from modelview projection matrices, to setting up render buffers, to compiling shaders, and so on and so forth. The small one-page examples that made OpenGL great are now project downloads and video tutorials and blog posts full of errata and workarounds. To me, something of great value was lost in the transition, probably forever. What I see now are the great failures of OpenGL ES. Having to specify line widths in the shader. Inconsistent support for points. Not being able to predict if a shader will have one instruction too many and fall off the fast path. I've learned it to great depths but the mental pollution I had to absorb in the process has caused lasting damage in the form of resentment and exhaustion. If it was up to me, I would scrap the whole thing and just give developers full DSPs so they can write their own renderer in a language like a hybrid between Go and Matlab, but with exact specifications and basic hardware guarantees.

masklinn 13y ago
> OpenGL ES was a way to pass the buck to developers so companies could save money. Since the OpenGL fixed function pipeline could have been implemented to some degree above OpenGL ES (but never was) Wasn't the fixed-function pipeline in OpenGL ES 1, and removed from 2.0 following the OpenGL 3.0 -> 3.1 transition?
- zackmorris 13y ago
  Ya you are right. I was startled to see I got down voted for my comment, but realized that there is quite a bit of context I skipped over. I've rewritten things for OpenGL 3 times now: once for Mac OS, once for iOS ES1 and once for iOS ES2. Then I scrapped it all and wrote some small wrappers so I could use the same code between iOS and Mac OS. We have everything defined in macros, for example MY_glGenFramebuffers() to map similar code to glGenFramebuffers() and glGenFramebuffersOES(). Unfortunately there are some iOS-specific calls that tie a render buffer's backing store to a UIView's memory so it's difficult to make a perfect wrapper. It feels like most of my day to day work now is just slogging through subtle issues with render and stencil buffers, and tweaking the shaders to even get 15 fps on older iOS devices. I get very little "actual work" done on any given day with OpenGL anymore. I don't think that it's gone the direction that it was originally intended to go. I just mean, I think OpenGL started with a scientific or mathematical approach and it's become kind of a catch-all or least common denominator for wherever the industry is going. So for example you really have to use one giant texture and one shader to do all of your work, because context switches are incredibly expensive on iOS. This doesn't make sense to me though because reading from a different texture address should be practically a free operation. My hunch is that they left off some critical piece of hardware, maybe a memory controller, or they didn't write a very good driver, so changing textures or shaders has to move a lot of data in and out of registers. I realize this is for cell phones and the hardware really is puny, but I don't think it would have been that expensive to give the hardware/drivers just that little bit of extra power to take the burden off developers. So that's what I meant about passing the buck. It's hard to explain my reasoning for all of this so I guess I came across as trollish.

masklinn 13y ago

> OpenGL ES was a way to pass the buck to developers so companies could save money. Since the OpenGL fixed function pipeline could have been implemented to some degree above OpenGL ES (but never was) Wasn't the fixed-function pipeline in OpenGL ES 1, and removed from 2.0 following the OpenGL 3.0 -> 3.1 transition?

zackmorris 13y ago
Ya you are right. I was startled to see I got down voted for my comment, but realized that there is quite a bit of context I skipped over. I've rewritten things for OpenGL 3 times now: once for Mac OS, once for iOS ES1 and once for iOS ES2. Then I scrapped it all and wrote some small wrappers so I could use the same code between iOS and Mac OS. We have everything defined in macros, for example MY_glGenFramebuffers() to map similar code to glGenFramebuffers() and glGenFramebuffersOES(). Unfortunately there are some iOS-specific calls that tie a render buffer's backing store to a UIView's memory so it's difficult to make a perfect wrapper. It feels like most of my day to day work now is just slogging through subtle issues with render and stencil buffers, and tweaking the shaders to even get 15 fps on older iOS devices. I get very little "actual work" done on any given day with OpenGL anymore. I don't think that it's gone the direction that it was originally intended to go. I just mean, I think OpenGL started with a scientific or mathematical approach and it's become kind of a catch-all or least common denominator for wherever the industry is going. So for example you really have to use one giant texture and one shader to do all of your work, because context switches are incredibly expensive on iOS. This doesn't make sense to me though because reading from a different texture address should be practically a free operation. My hunch is that they left off some critical piece of hardware, maybe a memory controller, or they didn't write a very good driver, so changing textures or shaders has to move a lot of data in and out of registers. I realize this is for cell phones and the hardware really is puny, but I don't think it would have been that expensive to give the hardware/drivers just that little bit of extra power to take the burden off developers. So that's what I meant about passing the buck. It's hard to explain my reasoning for all of this so I guess I came across as trollish.