5 ms·

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 migra

• StavrosK 14y ago
  I'm not knowledgeable about OpenGL at all, but how hard would it be to write a compatibility layer so older apps continue to work? It could be released as a third party shim.
  • drivebyacct2 14y ago
    Isn't that precisely what he did here? (note, I know nothing about nothing when it comes to graphics/OpenGL stuff)
    • StavrosK 14y ago
      It sounds like it. He could just package it up a bit better, release it and render this whole discussion moot.
      • kennywinker 14y ago
        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.
        • msbarnett 14y ago
          > 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.
    • mey 14y ago
      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)
      • hermanhermitage 14y ago
        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.
        • 14y ago
  • greggman 14y ago
    http://code.google.com/p/gles2-bc/ http://code.google.com/p/gles2-bc/
• ktizo 14y ago
  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.
  • hermanhermitage 14y ago
    Quite true. But there is another word there "only".
    • ktizo 14y ago
      true. I think I read your meaning wrong anyway.
    • ChuckMcM 14y ago
      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.
      • marshray 14y ago
        So this whole rant was just about the name having a common substring of three or more characters? I hope nobody tells JWZ what Linux was supposed to sound like.
      • SoftwareMaven 14y ago
        Were people really surprised that Java ME, Java SE and Java EE were different APIs around the same core idea of write once, run everywhere?
• katabatic 14y ago
  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]
  • Ralith 14y ago
    But OpenGL ES does not enable OpenGL on mobile devices; that's the entire point of its existence. It enables OpenGL ES, which is intentionally designed to be a simplified subset. If mobile device manufacturers feel that full-on OpenGL is appropriate for their device, then they are free to implement full-on OpenGL. JWZ should be complaining to the manufacturer, not the spec authors. I believe that on modern hardware, OpenGL proper is simply OpenGL ES style features (and then some) with a software compatibility layer.
• MrFoof 14y ago
  >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.
  • CamperBob2 14y ago
    The point is to prune back the API for small devices I don't disagree with the general sentiment that it was time to clean out the cruft in OpenGL, but I find this part of the argument to be a bit humorous. These "small, constrained devices" we're talking about are probably 10x faster than a goddamned Reality Engine. I tend to agree that the API should have been renamed entirely once it was pared down this far, as 3Dfx did when they created Glide.
    • msbarnett 14y ago
      > I don't disagree with the general sentiment that it was time to clean out the cruft in OpenGL, but I find this part of the argument to be a bit humorous. These "small, constrained devices" we're talking about are probably 10x faster than a goddamned Reality Engine. OpenGL ES 1.0 was released in early 2003, IIRC. The decision to exclude Immediate Mode from OpenGL ES 1.0 was made sometime prior to that. 2002-2003's typical mobile hardware was pretty damn weak, in particular in the areas of CPU cycles and memory bandwidth, which is where Immediate Mode really bites you in the ass. And the RAM/ROM sizes on most of these devices were small enough that every byte you could shave off the driver was a win for application writers, so there was little desire on the part of mobile graphic hardware vendors to spend memory budget on redundant features that an application could rebuild on top of lower level primitives if they so chose.
• mcbridematt 14y ago
  Now that smartphones and tablets have respectable GPUs in them, is there any reason why they shouldn't implement the full OpenGL spec?
  • mattrobertso 14y ago
    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.
    • kevingadd 14y ago
      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.
      • greggman 14y ago
        Modern GPUs have to put the vertices in vram before they can render them. That means immediate mode emulation is effectively this everyframe: a) copy all vertices from user code to some cpu buffer b) at draw time, copy cpu buffer to vram c) ask GPU to draw steps A and B are very expensive CPU wise as well as waste memory. vs OpenGL ES 2.0 init time: put vertices in vram everyframe: ask GPU to draw
  • msbarnett 14y ago
    > Now that smartphones and tablets have respectable GPUs in them, is there any reason why they shouldn't implement the full OpenGL spec? To what benefit? OpenGL ES is basically OpenGL minus all of the bits you really really should have stopped using over a decade ago. Originally all of that crap was culled out because it was only realistic to write new software for such resource constrained devices anyways, so why burden driver authors and hardware with the need to support crap that should never be used anyways? Now that mobile device CPU/GPUs are powerful enough to start being appealing as targets for porting OpenGL-based applications, I think the proper response is less "great, slather back on all of the deprecated legacy cruft from the desktop version of OpenGL" and more "for the love of god update your rendering pipeline to reflect the last 15 years of progress".
• jes5199 14y ago
  > 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.
  • cpeterso 14y ago
    I think hermanhermitage meant that backwards compatibility makes development painful for the library developer.