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