OpenGL 2.3 to 3.0

Stefan Dösinger stefan at codeweavers.com
Tue Jun 5 18:52:05 CDT 2007


Am Dienstag, 5. Juni 2007 22:17 schrieb Matthew Clark:
> Ah this makes perfect sense and is exactly what I was looking for, thank
> you for your response! My limited understanding from the article was
> that 2.3 was simply cleanup and putting some extensions in the official
> API that have been in drivers for a while just not in the official API
> and then 3.0 is where the real change will be, BUT that it will only
> activate the 3.0 functionality if it's on supporting hardware(i.e. DX10
> cards). Please correct me if my understanding is incorrect and again I
> think we all realize this is all in the future and is just fun to talk
> about^_^
They're takling more about codenames rather than 2.3 and 3.0, but I don't know 
the names currently.

2.3 will have all the functionality of 3.0 and be fully backwards compatible. 
This means you can use very old things together with the very new stuff. The 
drawback will be that you don't get the performance improvements of 3.0. This 
is somehow like d3d9. with d3d9.dll you can use the new d3d9 features, those 
will work on d3d9 cards only. But you can also use d3d9.dll to write an app 
that uses only dx7(or even earlier) level features, and those apps will run 
on dx7 cards - an example for that is the Source engine in hl2.

3.0 will be the complete rewrite. You'll have 3.0 only on cards that support 
it, and afaik you can't use the 3.0 API to program older cards(like a geforce 
2 that doesn't even support shaders). This is what happened in d3d10 too.

The advantage of the api cleanup is that you get rid of all the legacy stuff. 
The API is cleaner, drivers are simpler. The code is smaller and runs faster. 
If you look at wined3d you'll see that it is full of stuff to support even 
oldest cards(theoretically, in theory unsuccessful). Even though the state 
management keeps the most of the code sleeping until the app actually uses 
this features it makes everything more complex. A performance penalty is 
maybe the GL_EXTCALL stuff, which we use to be able to link against old 
opengl libs. Calling an address inserted by the dynamic linker at load time 
would be cheaper than finding a function pointer in a table and calling it.



More information about the wine-devel mailing list