Announcement

Collapse
No announcement yet.

Wine 3.0 Released With Initial Direct3D 11 Support, D3D Command Stream

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

  • #61
    Originally posted by duby229 View Post
    I really hate to say this but, In that case then it's definitely time for gamer oriented fork of wine.
    Go right ahead and make the same mistakes trans-gaming did with Cedega/WineX. Over time they attempted gamer oriented fork forgot to remain test driven and end long term with the nightmare failures.

    There have been 8 different gamer attempts at forks of wine and all have died slow and painful death as they have attempted to take quick fixes instead of proper solutions. Of maybe you will listen to why wine project will not merge particular things and address those problems. If you start you own fork at least that should shut you up for a while.

    Comment


    • #62
      Originally posted by oiaohm View Post

      Really notice the pure weaselling words. Only AAA games lets ignore business applications or anything else using direct x that Gallium-Nine breaks.

      The metrics I use are solid on what percentage of applications and games can be run.

      Basically artivsion is saying I don't care who else workflow I break as long as the few programs I am interested in work. Of course that arguement means nothing to test driven development like wine. Wine project does not exist to service just 1 group of users exclusively.
      Not exactly my friend. You your selves have said before, that AAA games are the first priority of the project named WineHQ. Both Linux and Mac users in our majority we have agreed that we prefer native apps for our daily work and we need Wine only for the rare cases that we don't have an alternative, you have also agreed to that. As i see it you didn't achieve your own targets. As for my multi-thread code knowledge, D3D9 is as threaded OGL2-3 is and D3D11 as OGL4. I do agree with you that Vulkan is the easy solution, but are you willing to develop D3D state trackers for Vulkan?
      Last edited by artivision; 20 January 2018, 01:56 PM.

      Comment


      • #63
        Originally posted by artivision View Post
        Not exactly my friend. You your selves have said before, that AAA games are the first priority of the project named WineHQ.
        Please provide cite straight way. Because I think you will find no wine person has ever said that. This from my point of view is attempt to justify a totally invalid arguement.

        Gallium-nine put focus on having AAA games work but that is not the wine project.

        Comment


        • #64
          Originally posted by oiaohm View Post

          Go right ahead and make the same mistakes trans-gaming did with Cedega/WineX. Over time they attempted gamer oriented fork forgot to remain test driven and end long term with the nightmare failures.

          There have been 8 different gamer attempts at forks of wine and all have died slow and painful death as they have attempted to take quick fixes instead of proper solutions. Of maybe you will listen to why wine project will not merge particular things and address those problems. If you start you own fork at least that should shut you up for a while.
          How many of them were driven by open source ideology? The older attempts I'm aware of failed because they were commercially driven and were made with quick fixes. As I already said it would need to take the path of acknowledging that it is an emulator and then pursuing it for what it's worth. That or every library it needs would have to implemented natively on linux and then wrapped.

          Comment


          • #65
            Originally posted by oiaohm View Post
            Please provide cite straight way. Because I think you will find no wine person has ever said that. This from my point of view is attempt to justify a totally invalid arguement.

            Gallium-nine put focus on having AAA games work but that is not the wine project.
            Don't you think that is a major problem?

            Comment


            • #66
              Originally posted by artivision View Post
              I do agree with you that Vulkan is the easy solution, but are you willing to develop D3D state trackers for Vulkan?
              That how wine DX 12 is being done its the first of the D3D Vulkan in wine and there will not be a opengl form either DX12 apps will require Vulkan with wine or not work and that is vkd3d. Galluim nine never supported Mac Users or anyone using closed source drivers and broken applications/games wine supports. Even Vulkan is a problem on OS X.

              EGL work is required for wayland and android. OpenGL ES more multi thread friendly than your standard desktop opengl there might be some performance to be found there.

              vkd3d for DX12 is a good place to start without disrupting existing.

              Comment


              • #67
                Gallium-nine put focus on having AAA games work but that is not the wine project.
                Originally posted by duby229 View Post
                Don't you think that is a major problem?
                Long term these forms of narrow focus is how you end up with game updates failing more often and other major issues. History of the failed Wine forks tells you that if you focus on narrow class of programs and don't go after properly working you will be bitten by it sooner or latter. If you think it a major problem you lack the experience and history that tells you that its not.

                You are better to have people upset with under performance and a solution that works correctly for the most applications than have a solution that does not work at all for many applications. Why exactly what reason would there been for people to put in a corrected direct 9 if Gallium-nine got accepted. Its not the first time someone had the idea of making a faster direct x conversion. I remember winex direct x 8 totally not being able to work with direct 9 and over time that came more and more critical.

                Being upset could motivate a developer to fix it properly.

                Comment


                • #68
                  Originally posted by oiaohm View Post
                  Gallium-nine put focus on having AAA games work but that is not the wine project.


                  Long term these forms of narrow focus is how you end up with game updates failing more often and other major issues. History of the failed Wine forks tells you that if you focus on narrow class of programs and don't go after properly working you will be bitten by it sooner or latter. If you think it a major problem you lack the experience and history that tells you that its not.

                  You are better to have people upset with under performance and a solution that works correctly for the most applications than have a solution that does not work at all for many applications. Why exactly what reason would there been for people to put in a corrected direct 9 if Gallium-nine got accepted. Its not the first time someone had the idea of making a faster direct x conversion. I remember winex direct x 8 totally not being able to work with direct 9 and over time that came more and more critical.

                  Being upset could motivate a developer to fix it properly.
                  I think the trick is to emulate the behavior exhibited by windows itself. Wine doesn't attempt to do that at all. If a fork of wine was to be made I think a major factor in its success would be the acknowledgement that it must exhibit the same behavior at runtime as windows libraries themselves would on windows. That's something older attempts failed to do.

                  Comment


                  • #69
                    Originally posted by oiaohm View Post
                    The other thing is g++ does attempt at time to understand how MSVC encode its names. So wine switching to C++ would bring some major complications and require quite a few gcc and llvm c++ compiler modifications.
                    Sorry, I didn't get this one. Why does g++ attempt guessing, but only sometimes? Are you talking about mixing object files from MSVC and g++, or what?
                    Originally posted by oiaohm View Post
                    https://gcc.gnu.org/projects/cxx-status.html
                    http://www.open-std.org/jtc1/sc22/wg...2008/n2670.htm
                    There is a C++11 and newer the standard mandates that you include a GC to be fully to spec.
                    It's optional, see e.g. Bjarne Stroustrup's paragraph http://www.stroustrup.com/C++11FAQ.html#gc-abi
                    Originally posted by oiaohm View Post
                    Currently gcc has not implemented this interface. Instead you have the following interface.
                    https://gcc.gnu.org/onlinedocs/gccin...pe-Information


                    O yes g++ support garbage collection as a random-ally placed land mines of garbage collection that can cause you real trouble when you are needing to control the garbage collection to match up with MSVC method of garbage collection.
                    This is odd, I feel like there's some sort of confusion, it can't be that bad. I asked #gcc channel a few hours ago, nobody answered so far. Maybe because everybody on holidays, I'll try to write back on this when I get an answer.


                    Originally posted by oiaohm View Post
                    Dll files export C functions as one function and C++ functions as a C++ mangled name function so you can have the same function appearing twice and one is expected to obey garbage collection. Sanity would say isolate when you make dll but that is not what most C++ compiler have done with garbage collection. So something has been passed to your function you are done with it you need to report to garbage collection that you have released it if it being tracked by garbage collection.
                    Well, first, isn't there a way to disable exporting C++ version? Second — I do not observe that behavior. See:

                    Code:
                    $ cat test.cpp
                    extern "C"
                    int myone() { return 1; }
                    $ x86_64-w64-mingw32-g++ test.cpp -shared -o test.dll
                    $ rabin2 -s test.dll | grep myone
                    vaddr=0x6bec1430 paddr=0x00000a30 ord=000 fwd=NONE sz=0 bind=GLOBAL type=FUNC name=test.dll_myone

                    Comment


                    • #70
                      Originally posted by duby229 View Post
                      I think the trick is to emulate the behavior exhibited by windows itself. Wine doesn't attempt to do that at all. If a fork of wine was to be made I think a major factor in its success would be the acknowledgement that it must exhibit the same behavior at runtime as windows libraries themselves would on windows. That's something older attempts failed to do.
                      Then explain why backing galluim-nine the reason wine was rejecting it is that is does not exhibited the required behaviour to match how Windows Graphics stack required to work to make application happy.

                      Besides behavior exhibited by windows what the hell are you talking about.

                      XP 2003 Vista 2008 Win7 Win8 Win10 across the top is the referring to the operating system the wine testsuite has run under. Then the results of that test suite are compared to what wine does.\

                      So the claim that wine does not attempt to match behaviour exhibited by Windows is false. So really you are not talking about anything different to what the Wine project does now. Other than test suite how else are you going to confirm that behaviour matches.

                      Comment

                      Working...
                      X