Raspberry Pi's V3DV Vulkan Driver Can Now Run The Zink OpenGL Translation Layer

[oiaohm]

native dx is always faster when it has same quality of implementation. windows dx can have worse implementation and be slower, i'm talking about (potential)linux native dx

It does not work that way. We have already seen linux native dx vs to vulkan solution with d9vk vs gallium nine. With cases where d9vk beats gallium nine. The horrible part here programs don't all use DX the same way so Linux native dx could not be possible be optimised for all usage cases.

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.

[pal666]

It does not work that way. We have already seen linux native dx vs to vulkan solution with d9vk vs gallium nine. With cases where d9vk beats gallium nine.

"cases" is not enough, it has to beat in total. fwiw nine is not entirely native, it does conversion to gallium, though it should be much closer to dx since it was designed for it. and you also have quality of implementation issue, nine could just have less manpower

Native dx is not always faster in all cases even with the same quality of implementation because of the different ways you can optimise

it is always faster because worst case you can copy-paste piece of vulkan driver and do same stupid thing. but also you could do smarter faster thing

[oiaohm]

"cases" is not enough, it has to beat in total. fwiw nine is not entirely native, it does conversion to gallium, though it should be much closer to dx since it was designed for it. and you also have quality of implementation issue, nine could just have less manpower

Nine has had more power. Nine have also gone closer to the way Microsoft does things.

it is always faster because worst case you can copy-paste piece of vulkan driver and do same stupid thing. but also you could do smarter faster thing

This is in fact no because you have missed how big of bit you have to cut and paste. SPIR-V and the DXIL bytecodes in the shaders have different costs in CPU processing time to find same optimisations. This is a case of having to bite a bullet. Do you pay the price of converting the bytecode to SPIR-V so you can find particular optimisations fairly quickly or do you just not do those optimisations so you don't run out of processing time.

This is quite absolutely completely inserting a extra abstraction layer to get this extra performance in particular cases and cause a general loss in performance. Of course once you bitten the bullet todo that going the complete way does not change the results much.

https://www.khronos.org/blog/hlsl-first-class-vulkan-shading-language

As noted here some things that a valid in DXIL are not valid in SPIR-V as well. So there are a set of optimisations that are simpler to perform with the DXIL that are more costly to perform with SPIR-V.

pal666 like or not the there are limitations in the Microsoft DX design. Of course when it come to optimising shaders you don't have a unlimited amount of processing time. Result is when you design a graphical layer you have decide in advance what you are and are not going to optimise well. Remember game developers don't have to conform to what graphical layer developers designed for this results in some games poorly optimising if you stick to only the features the graphical layer provides.


pal666 the reality is you most likely want both Native and to vulkan with DX and use what ever one make the program perform the best.

[MamiyaOtaru]

dxvk is not that fast btw, it's fast compared to wine's dx on opengl, but native dx would be fastest

Sorry it not that straight forwards. There are some games where dxvk is faster than Windows DX11 and at the same time using less CPU

native dx is always faster when it has same quality of implementation.

It does not work that way.
...
Native dx is not always faster in all cases even with the same quality of implementation

LOL do you post stuff just to be contrary?

Yes and no do remember that wrapping over Vulkan does add overhead. So native DX or Opengl done well should be faster.

[oiaohm]

LOL do you post stuff just to be contrary?

No it is mixed results. There are benchmarks showing dxvk with particular games on windows being faster than Nvidia dx implementation.

The important point is not all implementations of DX/Opengl... are done well. Next is you can have two of the same quality implementations yet result in different performance when you benchmark them.

Its not me being contrary. Its the reality is when you look at the benchmarks of performance with dxvk and other things it gets quite contrary. There are games that end up 10% faster than native DX implementation using dxvk but then there are other games on the same version of dxvk that are like 30% slower than the Native DX.

Different implementations of DX/Opengl/Vulkan do end up choosing to optimise there code differently. Code of the same quality can be have different optimisations resulting is very different performance when you benchmark them.

Problem here this not a black or white answer question in this area shades of grey answer. There will be cases where native dx is the worst choice compared to dxvk just like there will be cases where dxvk will be the worst choice over native dx even on windows.

Native dx of equal quality implementation to dxvk you would expect a high probability of the Native dx being the faster one in benchmarks but its only a higher probability you would also be expecting to have benchmarks where dxvk wins as the lower probability outcome. Notice not a black or white answer.

Please note I said "So native DX or Opengl done well should be faster." Notice the key words in there "done well" the reality is every implementation will have its defects and weaknesses so you will have the cases where the benchmark/game its hitting area of the implementation that is not done well.

Horrible part is you optimise for X benchmark/applications workflow you can be crippling Y benchmark/application workflow.

Its not possible in fact to make a native DX or Opengl driver that is perfect in every single usage case with our current level of software development skill and it might be totally impossible to-do without having multi versions. DXVK gives you another version with different optimisation choices in the mix.