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.
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.
-
Matthew Clark -
Stefan Dösinger