Thats something they need to document and advise on for their platform. don't repeat this work, but maybe add optimizations for d, e &f. 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).Īgain how this is communicated to the developer or structured is an issue of the platform provider.Īpple 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. This is identical to buffered versus non buffered IO and whose responsibility is it to filter idempotent operations. Apple and Videologic need to nut that one out themselves.Īs to a shim speeding up code its essentially comes down to any impedance mismatch that may occur between an application writer and the API. In this instance any OpenGL shim is an Apple responsibility as they are the SDK and environment provider. 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. Their charter is to make a new lightweight API that meets the needs of device manufacturers and low level app developers.

Also there is a line where you cross and you lose hardware acceleration and the mapping breaks down. The makers of OpenGL ES don't want a lifetime of maintaining someone elses problem. The problem is a 100% compatibility layer is not necessarily easy nor valuable. Javascript without the bad parts for example.Īn incremental only approach to design is non-design in my view.Įvolution both promotes and retires ideas.ĭisclaimer: I've dabbled as a driver writer in a past life - but not OpenGL ES. Imagine if every API or language you ever used had features both added and removed over time to make it a better language. Otherwise APIs and languages expand at an unfathomable rate.

This is not to say backwards compatibility should not be provided in some form - but ejecting it from the core is a sane decision. In my experience, backwards compatible APIs and languages are what makes development a pain going forward. JWZ is a very smart guy and I respect his opinion, but he is coming from a narrow viewpoint and not considering the wider implications. The point is to prune back the API for small devices - NOT - to make make migration of legacy code simple.įor 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.

Opengl es 2.0 accumulation buffer