backward compatibility

[jide]

as this seems to be an important stuff on the other forums...

yeah, really, I'd like GL to stay 100% compatible with GL 1.2. Or GL 2.0 in 5 years...

This is really important to my point of view even if new releases only imply drivers changes not hardware changes.

I personally think we evoluate from the continuity not from brakings. And for speaking with things I do not really like, I guess that DirectX tried to be backward compatible with the previous major release.

For example, it's well to change the bindings into application-only-ids. But doing so, first, will only speed up things about 3% (too good...) in theory. And second, will oblige programmers to provide two different ways for those having GL 3 and those not having that release.

Finally, what's really wrong with current GL ? Does GL is too slow compared to D3D ? Can it be more than 10-15% faster if we change all the things ATI and nVIDIA propose ? Overclocking a GPU could be much more easier to gain about 5 up to 10% instead of obliging programmers to develop more complex and unstable programs.

This is what I think.

PS: if this is not the right place for this topic, please move it to the appropriate one. Thanks.

[Korval]

The problem with backwards compatibility ad infinitum is that people make mistakes. If the ARB was perfect, if OpenGL was a perfect API, then backwards compatibility could be maintained forever. However, it is not.

The inability to actually depricate and ultimately remove functionality has been one of the bigger problems with OpenGL. When the ARB makes mistakes, or is shortsighted about some bit of functionality, there's no way to rectify those mistakes.

And second, will oblige programmers to provide two different ways for those having GL 3 and those not having that release.

When you run a program that requires DirectX9.0c, and you only have DX8 installed, it will inform you of this and tell you to install DX9.0c. Then the program will exit.

This is no different. Except that it will tell you to install the latest drivers for your hardware.

[jide]

Yes you're right. But I didn't wanted an ad infinitum backward compatibility, but ensuring it at least for a long enough period and without loosing performance for those requiring that backward compatibility regarding new releases (layering can lead to performance losts).

I actually don't see much 'important mistakes' in GL. But of course I think that an API as GL should also fit the advances in hardware, this turns out.
However, and as I said, wanting to gain 3% in performance with changing for example all the bindings architecture for another one that is less secure (because it is let to the application instead of the driver), is at my point ov view, dangerous.

I didn't understood well all what they want to add/change/remove for the next major release (I'll need to read it several times for that). But there are also many other things to do, as things of the ARB 2.0 features that haven't been done (maybe they have been abandonned, or maybe they are left to a future, or so) like enhanced index arrays (sorry I can only remember this one from my head).
And this might also have some interrest.

[Korval]

However, and as I said, wanting to gain 3% in performance with changing for example all the bindings architecture for another one that is less secure (because it is let to the application instead of the driver), is at my point ov view, dangerous.

I think you misunderstood what they were saying.

The application isn't allocating any memory or anything. The way the old OpenGL object mechanism worked was 100% idiot proof. You couldn't actually cause a crash with it. Worst case is that you'd get some GL error or something. You could put any value inside a glBind* function call and the system would respond or throw a GL error.

Now, what they're doing is relying on the application to actually allocate the stuff that it needs. It requires that the application be "well formed".

Look at XML vs. SGML. SGML is ultimately a more powerful language that allows for more unusual styles of text markup. XML is much more restrictive. But writing an XML parser is pretty simple, while no one has ever written a fully compliant SGML parser.

If it saves 3-5% of the system's performance, and makes driver implementer's jobs eaiser (meaning more stable drivers for us), then so be it.