UCyborg wrote:
Edit: One more thing, shouldn't dgVoodoo automatically fallback to software rendering when appropriate hardware isn't available? In VMware virtual machine, you have to explicitly select WARP otherwise it doesn't work.
I'll install a Win7 into a vm then and have a look what happens. It should work.
lowenz wrote:Off-topic question for Dege.
I remember, when DX10 libraries have been introduced, that MS said "Every DX10 compliant GPU will be DX11 compliant and the missing features (of the 11.x feature level) will be off-loaded to the CPU.
Am I wrong?
No, I don't remember that.
I think, with the advent of DX11, MS said that all hw with DX10 (and lower, 9.x level) capabilities would be available through DX11, but of course with constraints, to avoid the need for coding against multiple API's (DX9, 10, 11),
so they introduced the term of 'feature level'. It was a nice step.
- DX1-7 had full software capabilites, for vertex and pixel processing (software D3D devices + software blitting in DDraw).
- DX8 was re-designed from scratch to get rid of DDraw and its more and more complicated usage due to the tons of cumulated flags and new resource types + the interfaces they added to DDraw with each major versions. They threw away too much things though, I still remember many people complaining about that back in 2003 on MS forums. 😀 DX8 only kept the software vertex processing, ditching software rasterization (except for the reference rasterizer), altough they left the possibility open for that, one could write a sw rasterizer for using that as a backend in a DX8 device.
- DX9 is roughly the same in that respect.
- DX10: MS got enough of the tons of hw capability flags present in all previous DX versions (to support various gpus from various vendors) and defined a standard (guaranteed features without any software-based support) that had to be supported completely by DX10-compatilbe hw's.
- DX11: update to DX10. But, if they had followed the DX10-way then DX11 could have only be usable for DX11-level hw, so no one would have used it when targeting DX10-level gpus. So, to avoid the strict 'DX API version ---> Hw feature level' binding, they added support for feature levels (much less granulated form of old capability flags). DX11 can use DX9/10/11 level drivers as its backend. Also, it was important for MS to support DX11 even on machines without DX10/11 level gpu, so they wrote a complete software-only DX11-level driver, WARP. It's not the same as the reference driver because WARP targets rendering speed, as much as possible.
- DX12: well, they opened up the hood of DX11, took the parts out of the engine room and gave them to the developers for direct control. This means the additional controller units responsible for the correct co-working of the parts are also ditched, the developer has to re-write them himself/herself. These controller units as I name them, were the background threading for building the command queue, managing virtual video memory page in/out, synchronization between cpu/gpu and such. When I use DX12 I always feel using a more direct DX11, the API itself very resembles DX11. I could say that I'm directly using the internals of DX11 and its not a big improvement, what is more, if one want to achieve the same as with DX11 for a traditional linear-driven rendering then he/she has to do the extra hard work. 😁 I must emphasize, DX12 is not an improvement at all (aside from some things), but only for linear-driven usage. For engines capable of rendering on multiple threads building multiple command lists however it is.
Oh, I've digressed. 😀