Quote:Original post by Ademan555
However, I'm quite reluctant to give up the bind-unbind system because I was under the impression that that was part of why OpenGL draw calls are quicker than d3d ones. Since you can render, and when you call the render function, OpenGL doesn't move around any texture objects, or any shaders, or any vertex buffers, its all been set in place beforehand, which was a big advantage imho(but I don't actually know anything, so its really just an opinion).

No, the reason OGL's draw calls were/are quicker than D3D's was down to the user-kernel switch which had to take place when you issued the draw commands for D3D, which is a MAJOR killer on time. This is now gone in D3D10 (huzzah!) effectively removing OGL's advantage in that department.

From my understanding of the new object model and how things will work instead of doing bind-set-bind-set-etc-etc-draw you'll now produce a vertex object which contains the bind points for the various attributes and when you go to draw you basically pass this in and tell it to draw things. This is a good thing as it removes CPU overhead of multiple bind-set pairs at draw time as well as the overhead the drivers have when setting up data (for example as i recall NV do a fair amount of validation work on a glVertexPointer() call, this work could be moved to one single place thus removing this overhead from draw to setup).
(nb: this could be wrong and it could change, but thats the impression I've got atm)

As for the design being brain dead, when it was concieved and for some time afterwards OGL's design wasn't, infact it pretty closely mirrored hardware from my understanding, it's only since the shader revolution that things have started to get icky and it's getting further from the hardware. Of course with backwards compatiblity being a major OGL feature it's hard to 'fix' this problem without breaking things. The compatibility layer over the top of the fast layer seems like the best idea, gives new projects the speed while not breaking the old ones.

I'd like to comment on the "braindead" SGI designs...

The names model was designed at a time when the CPU overhead of a hash table lookup was insignificant relative to the cost of display list execution. Simply sending data across the wire from the host to the graphics adaptor was expensive! The lookup wasn't even close to a bottleneck. Meanwhile, names provided some valuable properties:

1) Push model - object creation does not require a round trip; the new object model as currently proposed requires a round trip per object. Does this matter in practice? It sure did in 1992. Nowadays the majority of implementations are direct renderers, but thin clients threaten to bring back the client-server model.

2) Robustness - an opaque pointer is an invitation for the application to corrupt the driver heap. Again, does it matter? Maybe, and some implementations will likely continue to use names for robustness.

Bear in mind that each step taken through the evolution of the API was considered the best course of action at the time. The binding model was introduced in EXT_texture_object to maintain the OpenGL 1.0 texture APIs. Every extension thereafter followed the precedent, for better or worse - but these were ARB designs, not SGIs, so not all of the mistakes can all be blamed on the original design.

Hindsight is 20-20, and given fourteen years of hindsight I feel comfortable changing the model based on what we've learned. Certain DX benefitted from these lessons, but MS had a simpler task, as they serve a narrow market segment and have never prioritized backward compatibility.

Are we making the right decisions in the new design? Time will tell. High latency connections are uncommon but they still exist, and robustness is always a concern. We walk in the footsteps of giants, and these are pretty big shoes to fill.