Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by pal666 View Post
    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.

    Comment


    • #32
      Originally posted by oiaohm View Post
      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
      Originally posted by oiaohm 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
      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

      Comment


      • #33
        Originally posted by pal666 View Post
        "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.

        Originally posted by pal666 View Post
        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-fi...ading-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.

        Comment

        Working...
        X