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. >
