Announcement

Collapse
No announcement yet.

Wine 3.3 Brings First Vulkan Bits, D3D CSMT By Default

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

  • #21
    Originally posted by Hi-Angel View Post
    Why is it btw? It was always surprising me to see such commits in wine releases. I'm not a fan of doing manually things that looks like they can be automated.
    The video card it table its the first to kill you dead. But with the number of dependencies wine has non backward compadible API/ABI updates in libraries also hit old versions of wine a lot. Doing regressions tests with wine on items where people are not regularly reporting causes a lot of backport work make locating problem a lot harder.

    The video card table is one of those nasty things where you cannot extract from opengl or even if you had raw hardware access the information applications demand.

    1) You have like opengl have 1 text description for a video card and direct x having a different one. Of course you find windows applications that do strings operations on the video card description to decide on what optimisation it should use.

    2) due to copyprotection/anti cheat stuff. You have to report the right dll and version numbers for the video card in use of course there is no way to automatically guess that. This is information that has to be manually collected from windows installs or if lucky out of windows driver install packages..

    3) There has to be a list of opengl quirks maintained. What are these quirks it where we know the opengl drivers says I can do X feature. But you attempt to use X feature and complete opengl stack collapses on top of you because that feature does not in fact work this first set of quirks.

    4) There is a direct x list of quirks that has to be maintained where if you tell application that it has X card and display extra features you can end up with programs going down impossible code paths again this is not something that can be purely automatically collected.

    5) Now wine has allowed by registry for you to set a particular card but if that is having quirk applied that you don't need that hurting performance but that also does not prevent applications probing for anti-cheat/copyprotection/registration and getting upset because graphics card and reported information does not match yes you see games saying please update drivers.... At this point you are in totally stuffed with old version.

    Of course if you are able to avoid all the above problems this does not avoid the other issues like when freetype updated and the result was all versions without the patch to support that no longer worked. With the number of dependencies wine has something will get you sooner or latter if you attempt to stay on a old version for too long.

    Doing a regression test where really old version reported working and new don't at times means backport a lot of different wine patches and hoping that they are not the cause. Its way better if reports are early and tested at the time.

    Comment


    • #22
      Originally posted by debianxfce View Post
      wine-staging is better, it runs most of the games with a single wine prefix. Sometimes you need to have 32-bit wine prefix in a 64-bit system. With playonlinux you waste your drive storage with many prefixes and playonlinux increases the maintenance complexity when something goes wrong. Keep it simple.
      Here goes the clueless. The first maintainer of staging also recommend application per WINEPREFIX not using a single one. This is not due to winetricks workarounds this is due to applications having automatic updates and at times they update shared parts resulting in program 1 failing because program 2 updated.

      Just because you have been lucky doing something does not mean it recommend. Lets use a selling point that is invalid.

      Comment


      • #23
        Originally posted by oiaohm View Post

        Here goes the clueless. The first maintainer of staging also recommend application per WINEPREFIX not using a single one. This is not due to winetricks workarounds this is due to applications having automatic updates and at times they update shared parts resulting in program 1 failing because program 2 updated.

        Just because you have been lucky doing something does not mean it recommend. Lets use a selling point that is invalid.
        You need wintericks only once, to install all dlls that games need. Then with wincefg configure dll overrides and other settings per .exe file. winehq appdb and other forums give configuration instructions.

        Does Origin and Uplay games work with vanilla wine? If not, make them work instead of hanging here.
        Last edited by debianxfce; 03-03-2018, 06:40 AM.

        Comment


        • #24
          Originally posted by debianxfce View Post
          You need wintericks only once, to install all dlls that games need. Then with wincefg configure dll overrides and other settings per .exe file. winehq appdb and other forums give configuration instructions.
          Yes people do the same stunts with vanilla wine and get bitten sooner or latter. Nasty fact here more winetricks dlls does not equal better in many cases.

          That something works does not change that the recommendation for testing is 1 game per WINEPREFIX that the reason why the game is not work is not interaction. What you have just told me that your test results are worthless.


          Originally posted by debianxfce View Post
          Does Origin and Uplay games work with vanilla wine? If not, make them work instead of hanging here.
          Reality I don't have a single Origin or Uplay game. So I cannot perform any testing. You are not doing bug report correct so you are absolutely worthless. You are not willing to do per application per WINEPREFIX so your worthless.

          Really if someone wants Origin and Uplay to work we need someone is willing to do proper bug reports and proper testing when developers ask. Not idiots like debianxfce who love giving invalid advice.

          I am support person I am not a coder for wine. So tell me to go fix it is going to get you absolute no where. Only way to get somewhere will be submit correct test and bug reports and suggested patches.

          Comment


          • #25
            Originally posted by debianxfce View Post
            You need wintericks only once, to install all dlls that games need. Then with wincefg configure dll overrides and other settings per .exe file. winehq appdb and other forums give configuration instructions..
            Does not make this useful process. All it tells me is there is no point asking debianxfce to test out prototype patches because he will have a stack of applications mixed in one prefix so could be giving no false reports that something does not work when its fully functional and the reason its not working is that debianxfce is disobeying recommend process.

            Originally posted by debianxfce View Post
            Does Origin and Uplay games work with vanilla wine? If not, make them work instead of hanging here.
            Reality I am support I am not coder for wine. So give people advice on how to submit valid bug reports and valid testing and valid bug assocations to give the best odds of something being fixed. The reality is not me who has to-do anything. I don't own any Orgian/Uplay games I cannot do testing for developers.

            So reality here you have the games debianxfce. You have the possibility of doing correct bug reports and performing tests as requested by developers. So the one who should not be here if you want Origin and Uplay games to work in vanilla wine is none other than you debianxfce.

            Its about time debianxfce stops attempting to get other people to-do tasks that debianxfce should be doing.

            Comment


            • #26

              Originally posted by Xaero_Vincent View Post

              It doesn't. This is the official ChromeOS with Android support. It required a bit of fiddling to get it running on a Windows laptop. At first there was no wifi nor sound and dmesg was spamming errors but I got those taken care of. However, I'm playing with things to see if I can get the container working on Chromium OS Special Build, which runs on-top the 4.14 kernel.
              Hi Xaero_Vincent,
              I followed your efforts on github related to gvt-g+dma_buf+androidx86.. you seem to pick good pet projects..
              now seeing your ChromeOS Android efforts, I'm very interested in knowing "required a bit of fiddling".. can you please post some gist on github with details for others to replicate..
              if not at least can you answer two things about ChromOS Android test:
              1) ChromeOS works with GVT-g on QEMU+dma_buf similar to Android-x86..
              2)ChromeOS Android supports Android Vulkan apps.. is working also in your laptop (i.e can you for example run VulkanCapsViewer)..
              thanks..

              Comment


              • #27
                Friendly advice for Codeweavers: Hire Immediately those who develop DXVK / VK9 / MoltenVK and remake WineD3D upon universal Vulkan dropping the old OpenGL api. You will cut development time by 5-10x and wile dropping non Vulkan Gpus you will still open Wine to more users supporting today's low end and middle range systems. You should know that there is a danger to go out of business.

                Comment


                • #28
                  Originally posted by artivision View Post
                  Friendly advice for Codeweavers: Hire Immediately those who develop DXVK / VK9 / MoltenVK and remake WineD3D upon universal Vulkan dropping the old OpenGL api. You will cut development time by 5-10x and wile dropping non Vulkan Gpus you will still open Wine to more users supporting today's low end and middle range systems. You should know that there is a danger to go out of business.
                  Everything is lock stepped. Building on top of Vulkan would not alter the need to implement CSMT and buffer controls and other fragments to suit Direct X. So workload swapping from opengl to vulkan would be less than 10 percent alteration in development time cost. Going after personal from MoltenVK might be useful. But going after DXVK and VK9 that have taken the point of view its fine to cut corners in development may not be a good move long term.

                  Before wine can start major work building on Vulkan the interfaces from wine to platform native Vulkan have to be sorted out.

                  https://www.khronos.org/registry/Ope...DX_interop.txt

                  Also it might be impossible to drop opengl support and support all DX8, 9,10,11 applications. Yes welcome to the mega nasty curve ball. Its perfectly valid for applications to be using a hi-bred of opengl and direct x.

                  The devil is in the details artivision. So unless you have a plan that includes opengl working with direct x and more done on vulkan you are kind of in trouble.

                  This is the problem with DXVK and VK9 when you start getting the details of dropping the opengl path completely comes hard because direct x and opengl are not always separate things under Windows due to the extensions that were added to opengl.

                  Its really simple to say do X without in fact knowing the complete list of requirements to have as many applications as possible work.

                  Comment


                  • #29
                    Originally posted by pinguinpc View Post
                    Why you have disabled fog there, is nvidia driver after near decade still broken for the case?

                    https://forums.geforce.com/default/t...hin-fog-issue/

                    Comment


                    • #30
                      Originally posted by edwaleni View Post

                      Have you tried BlueStacks?
                      Does Bluestacks work on Linux?

                      Comment

                      Working...
                      X