OpenGL 3 Updates

[Overmind]

Compare this to D3D where you can just include one header file and you have it all.

Compare this to D3D where you have to use a completely new API for each generation of hardware :P

There are people out there who care about backwards compatibility, at least one generation back. With the D3D method, it's an all or nothing approach. If you want older hardware, you have to use the older API. If you want newer features, you have to use the newer API. If you want both, you have to write two renderers. If you want to use hardware that's between versions (not all features of DX10, but some of them), you're simply out of luck.

The extension mechanism is not about MS controlling the DLL on windows (Hint: there is an extension mechanism on Linux). It's about being able to code fallbacks without getting "entry point not found" errors on old systems.

[Timothy Farrar]

Well, I seriously dislike the fact that I need to dynamically load most of the core API. Compare this to D3D where you can just include one header file and you have it all. But I guess there is nothing to do about this, since it's Microsoft who controls opengl32.dll on Windows.

Now you wouldn't want GL to require kernel calls would you (bad batch performance)....

[santyhamer]

ok.. the good news are that OpenGL 3 spec gonna be released this year then?

[Simon Arbon]

The good news is that pipeline 006 is due out, (Q4 2007)
so they will be able to give us an update in pipeline 005,
release OpenGL3,
and then use oo6 to tell us all about the release.

[dor00]

Happy new year people!!

I check daily the forum, I hope the release will be soon

/peace

[Jan]

Yes, a Happy New Year!

Would be nice to get some information about OpenGL's status.

Jan.

[Demirug]

Compare this to D3D where you have to use a completely new API for each generation of hardware :P

There are people out there who care about backwards compatibility, at least one generation back. With the D3D method, it's an all or nothing approach.

Yes. Direct3D doesn’t support an official extensions mechanism. Some drivers do it anyway with so called “API-Hacks”. But this is a somewhat ugly thing.

You criticize Direct3D for not being backward compatible for older hardware. This is right for Direct3D 10 and I have criticized this, too. But former Direct3D version work with older hardware. The runtimes can even work with older drivers. The Windows XP Direct3D 9 runtime needs a Direct3D 7 driver to work. If we look at the future the Direct3D 10.1 runtime will work with Direct3D 10 drivers. There is no official statement about Direct3D 11 yet but IMHO Microsoft will go back to the old road and make it work with Direct3D 10 compatible hardware.

If you want older hardware, you have to use the older API. If you want newer features, you have to use the newer API. If you want both, you have to write two renderers.

Not sure how you implement API independency. We don’t use two renderer only small layers above the native APIs to unify the interface. The renderer then work against this interface.

Now you wouldn't want GL to require kernel calls would you (bad batch performance)....

OpenGL requires kernel calls, too. The differences on Windows XP it that Direct3D runtime may produce more calls as the main decision point is in the kernel driver. For OpenGL most decisions can be done in the user mode driver. Windows Vista uses the same model now for Direct3D, too.

Yes using the old Windows 95 driver model for Windows 2K/XP was a bad decision even if it may sounds right at this time.

[HenriH]

There are people out there who care about backwards compatibility, at least one generation back. With the D3D method, it's an all or nothing approach. If you want older hardware, you have to use the older API. If you want newer features, you have to use the newer API. If you want both, you have to write two renderers. If you want to use hardware that's between versions (not all features of DX10, but some of them), you're simply out of luck.

If you really want to support legacy hardware, you still need to write two renderers (or at least renderer backends) even for OpenGL. Consider for example, how Carmack implemented multiple renderer backends for his Doom 3 engine. One for prior GL2, one for generic GL2, one for ATI and another for nVidia cards.

[Korval]

If you really want to support legacy hardware, you still need to write two renderers (or at least renderer backends) even for OpenGL. Consider for example, how Carmack implemented multiple renderer backends for his Doom 3 engine.

Not anymore. At least, not these days.

Remember: Doom3 was released at the beginning of the transition from configurable fixed-function to actual programmability. So writing entirely different backends for rendering was a requirement. Legacy hardware meant "GeForce2's, 3's, and 4's".

Nowadays, legacy hardware is R300's and NV40's; GeForce4's and Radeon 8xxx's are basically non-existent. These are GL 3.0-capable hardware. That's why the ARB is willing to set a minimum functionality for GL 3.0 (I guarantee that before they set that minimum, they asked developers what hardware it should be).

Nowadays, supporting legacy hardware means writing different shaders (and the meshes to go with them, of course). There is less need for having actually different rendering code, so long as your code can select shaders based on something detectable like functionality, etc.

The big problem now is just driver bugs/non-functionality. That's where 90% of the specialized rendering code comes from in a modern engine.

[sylware]

What's up with opengl 3?
Will it go through a public review before being frozen for good?