Originally posted by pal666
View Post
Native dx is not always faster in all cases even with the same quality of implementation because of the different ways you can optimise and the fact DX itself is abstraction from the graphics card.
15% better or worse sounds like a lot until you see the different choices.
Something that is easy to miss is different shader byte codes have different levels of processing complexity for finding the same optimisations. Yes so covering DX shader byte code to spir-v can in fact reduce the processing time to find particular optimisations more than the cost of the conversion.
There is more to this and native solution is always faster. DX and Opengl and Vulkan are all abstraction layers. Everything in abstraction layers is designed with trade offs. This is why converting from one abstraction layer to another at times can equal higher performance because the conversion removes one of the design trade offs because what you converted to did not have that tradeoff. Yes the common case is more abstractions layers worse performance but when you are talking 1 layer of abstraction vs a solution using 2 layers of abstraction there results that don't seam to agree with the common rule.
It like zink vs opengl native getting inside 95 percent. Its possible to get faster is because the spir-v bytecode does not have the same tradeoffs as the old glsl code. Also in time zink could decide to go less conforming for speed because you have the vulkan layers API to play with. Zink with Vulkan layers has picked up a feature a standard native opengl normally would not have. Same applies to dxvk vs normal dx sitting on vulkan dxvk has access to some extra features you don't have in normal DX that can give performance gains. Can give performance gains is not that it will always give performance gains.
Basically when you stack two abstractions layers done well you expect it to win over a single abstraction layer in some cases and lose in some cases that is just the way the results come out in the end.
Comment