Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

The thing that particularly bothers me about this post:

> 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.



And what I've understood he's done is not to retransmit static geometry every single frame, but to use an array to send batches behind the scenes.

This is, the exposed API doesn't force any particular implementation.

And that makes a lot of sense.


If he's reimplemented the OpenGL 1 API, then he must be retransmitting geometry every frame, because the API is not sufficiently expressive to allow for retained state of that nature. He describes glBegin and glEnd as accumulating an array to batch out, but that batch gets re-accumulated and transmitted every single time the glBegin/End block is executed, i.e. every single frame.


Question from ignorance: Couldn't you internally buffer the geometries and, say, send them to the GPU every 5 frames or so?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: