Announcement

Collapse
No announcement yet.

Wine's Vulkan Code Seeing Performance Improvements, Further Enhancing DXVK

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

  • #11
    Originally posted by oiaohm View Post
    So saying windows 64 bit applications don't need this structure conversion is wrong its just so rare that you will hit it you will more likely be more likely to win the loto by dumb luck picking up a random ticket on the street someone lost.
    Once again you're wrong and spout nonsense. The struct conversion is done for 32-bit VULKAN because the struct layout is different between the vulkan library on unix, and the vulkan library on Windows.

    DXVK (and D9VK) obviously are simple .DLL files that use the actual vulkan DLL, and it's the (fake) vulkan DLL that needs to convert from the "32-bit Windows struct layout" to the "32-bit Unix layout" before passing it to the system (unix) library.

    On 64-bit both Vulkan struct layouts are the same so there's no conversion needed: the fake wine Vulkan dll will just pass through calls to the unix library.

    This has nothing to do with D3D, it's Vulkan. It only affects DXVK because it uses Vulkan.

    Comment


    • #12
      Originally posted by Weasel View Post
      Once again you're wrong and spout nonsense. The struct conversion is done for 32-bit VULKAN because the struct layout is different between the
      Basically stop spout nonsense. struct processing in wine Vulkan is the same for 64 and 32 bit versions. None of this recent patches in fact changes that.

      https://github.com/wine-mirror/wine/...lls/winevulkan

      Basically there is no special code for 32 bit Vulkan in wine. If there is point it in the above links files. Guess what as normal you posted thinking you had a point but you had nothing Weasel.

      Comment


      • #13
        Originally posted by oiaohm View Post
        Basically stop spout nonsense.
        Yes, please stop spouting nonsense indeed and actually look at the code.

        https://github.com/wine-mirror/wine/...vate.h#L23-L26

        Comment


        • #14
          > Basically there is no special code for 32 bit Vulkan in wine.

          Like, did you even look at the code before making that comment? :v

          Comment


          • #15
            Originally posted by JoshuaAshton View Post
            > Basically there is no special code for 32 bit Vulkan in wine.

            Like, did you even look at the code before making that comment? :v
            The hammer has dropped. Though since you're here, could you comment on how useful it would actually be to have all MS graphical API's translated to vulkan or gallium? I want to say it would be most useful for mixed api applications (directdraw and dx8, say), or is this actually of little value?

            Comment


            • #16
              Originally posted by oiaohm View Post
              Basically stop spout nonsense. struct processing in wine Vulkan is the same for 64 and 32 bit versions. None of this recent patches in fact changes that.

              https://github.com/wine-mirror/wine/...lls/winevulkan

              Basically there is no special code for 32 bit Vulkan in wine. If there is point it in the above links files. Guess what as normal you posted thinking you had a point but you had nothing Weasel.
              Imagine making a clown out of yourself in front of the dev actually working on this patch series. (see Joshua himself)

              Comment


              • #17
                Originally posted by cute2dgirl View Post
                Yes, please stop spouting nonsense indeed and actually look at the code.

                https://github.com/wine-mirror/wine/...vate.h#L23-L26
                Interesting so something is proxied in different way to the opengl conversion code and that creates a code search bug.

                Originally posted by JoshuaAshton View Post
                > Basically there is no special code for 32 bit Vulkan in wine.

                Like, did you even look at the code before making that comment? :v
                Yes but I missed it due to a interesting search bug.

                Originally posted by Weasel View Post
                Imagine making a clown out of yourself in front of the dev actually working on this patch series. (see Joshua himself)
                No I have in fact found a very interesting little bug. The bug got me this time but it interesting.

                https://github.com/wine-mirror/wine/...ped_q=__i386__

                Go though what that returns there is no vulkan_private.h some of the time. Yes you get two different counts179 when its there and 178 when it not. Yes vulkan_private.h the only file that pulls the disappearing act when doing a search for __i386__ using area.

                Its also the only section of code where __i386__ is used in a header without any inlines or other functional code. So there is something slightly unstable about github search maybe it relates to using a system that has not be logged in and the file ending in _private.h. Maybe if github does not trust your system for some reason it hides stuff from search results? Its small enough that most of the time you would not notice of course it would have to be something that caught me out.



                Comment


                • #18
                  Originally posted by oiaohm View Post
                  No I have in fact found a very interesting little bug. The bug got me this time but it interesting.

                  https://github.com/wine-mirror/wine/...ped_q=__i386__

                  Go though what that returns there is no vulkan_private.h some of the time. Yes you get two different counts179 when its there and 178 when it not. Yes vulkan_private.h the only file that pulls the disappearing act when doing a search for __i386__ using area.

                  Its also the only section of code where __i386__ is used in a header without any inlines or other functional code. So there is something slightly unstable about github search maybe it relates to using a system that has not be logged in and the file ending in _private.h. Maybe if github does not trust your system for some reason it hides stuff from search results? Its small enough that most of the time you would not notice of course it would have to be something that caught me out.
                  Fair enough. Doesn't change the fact you love arguing with people who know what they're talking about because they're actual developers, unlike you. And obviously being wrong in the process.

                  Comment


                  • #19
                    Originally posted by Weasel View Post
                    Fair enough. Doesn't change the fact you love arguing with people who know what they're talking about because they're actual developers, unlike you. And obviously being wrong in the process.
                    Also you have done the same thing to me so I don't trust you either. Just because someone is a developer does not mean they don't make mistakes.

                    Comment

                    Working...
                    X