OpenGL 2.3 to 3.0

Matthew Clark mclark4386 at charter.net
Tue Jun 5 17:20:32 CDT 2007


Ah, thank you for the clarification^^

Stefan Dösinger wrote:
> 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