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".
If you were involved in the OpenGL ES specification, you are an idiot
41–50 of 225 posts
Re: If you were involved in the OpenGL ES specification, you are an idiot
#42There 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
#43OpenGL 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?
Re: If you were involved in the OpenGL ES specification, you are an idiot
#44Earlier 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…
Re: If you were involved in the OpenGL ES specification, you are an idiot
#45> 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
#46OpenGL 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…
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
#47Earlier 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.
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
#48Lion 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
#49Earlier 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 :)
Re: If you were involved in the OpenGL ES specification, you are an idiot
#50Earlier 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.
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.