Announcement

Collapse
No announcement yet.

Gallium3D Direct3D 9 For Wine Revived, Again

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

  • #61
    Originally posted by Dukenukemx View Post
    I know a lot of people throw gaming to the side as unimportant, but consider this. The graphics card only exists for gaming. It wasn't made for anything else, but to play games.
    Umm, 3d graphics cards were made for CAD and visualization originally. SGI and Iris GL. http://www.codingunit.com/the-history-of-opengl

    Comment


    • #62
      Originally posted by Dukenukemx View Post
      It goes to show that a lot of people want Linux to be able to play their games, so they can move away from Windows for good. That's why it's just a heated discussion. If you can improve the frame rate by even 1 fps, then you better believe people want you to go for it. But the state tracker can improve that performance by a significant magnitude, and that's just enough to turn this thread into a flame war. Even though the Command Stream D3D Patch can probably produce nearly equal performance.
      There is a difference between a d3d state tracker and command stream patches:

      The D3d state tracker, if properly developed, could eliminate translation (d3d->ogl) overheads and provide the same or even faster performance using the SAME HARDWARE RESOURCES as Windows

      Command stream on the other hand, can provide the same performance, but by using MORE HARDWARE RESOURCES than Windows. At least one cpu core more...

      It is not the same. D3D state tracker could be much, much more efficient. The only downside is that it is available only for gallium...

      Comment


      • #63
        Originally posted by curaga View Post
        Umm, 3d graphics cards were made for CAD and visualization originally. SGI and Iris GL. http://www.codingunit.com/the-history-of-opengl
        The graphic cards we deal with, like 3DFX Voodoo, ATI Rage, and Nvidia Riva 128, were made for gaming. Every graphics card sold in retail stores like CompUSA, were for gaming. Todays graphic cards are based on that. Just so happens graphic cards are great for accelerating UI's and video decoding as well.

        SGI products were meant for servers and workstations, not home computers.

        Comment


        • #64
          Originally posted by TemplarGR View Post
          There is a difference between a d3d state tracker and command stream patches:

          The D3d state tracker, if properly developed, could eliminate translation (d3d->ogl) overheads and provide the same or even faster performance using the SAME HARDWARE RESOURCES as Windows

          Command stream on the other hand, can provide the same performance, but by using MORE HARDWARE RESOURCES than Windows. At least one cpu core more...

          It is not the same. D3D state tracker could be much, much more efficient. The only downside is that it is available only for gallium...
          Not saying state tracker won't be better, but with games hardly using multi-core CPU's, and we're up to what 8 cores for desktop CPU's, then the difference maybe negligible. But even something like 5 fps is enough to justify going state tracker. Especially since the most important part of fps is the minimum, not the average. Doesn't matter of the game can average 30 fps, when parts of the game dip down to 15 fps.

          Comment


          • #65
            Originally posted by TemplarGR View Post
            There is a difference between a d3d state tracker and command stream patches:

            The D3d state tracker, if properly developed, could eliminate translation (d3d->ogl) overheads and provide the same or even faster performance using the SAME HARDWARE RESOURCES as Windows

            Command stream on the other hand, can provide the same performance, but by using MORE HARDWARE RESOURCES than Windows. At least one cpu core more...

            It is not the same. D3D state tracker could be much, much more efficient. The only downside is that it is available only for gallium...


            I am glad that people understand the 90% of the truth. The other 10% is that the D3D state tracker is not only for gallium. A simple gallium patch, can allow to gallium it self to connect with closed drivers, and we can use the state tracker. Closed drivers can use Mesa libraries on Linux, Windowz and OSXxx, and the connection points are known for years. Closed drivers are not that far from Mesa as you thing they are.

            Comment


            • #66
              Originally posted by stefandoesinger View Post
              Ok, now that the flamewar has toned down a bit let me join the party

              I stand by my statement that writing a Mesa-specific d3d implementation is inferior to improving the platform independent code as long as the platform independent code has room for improvement. That statement has been discussed ad nauseam, so let's have a look at the wine patch that integrates gallium-nine:

              The integration is done by exporting an IDirect3D9-like interface from Mesa. This has the advantage that the interface between Mesa and Wine is quite simple and I guess relatively stable, but it won't do any of those things:
              • Support ddraw or d3d8
              • Properly handle window messages (wined3d_device_acquire_focus_window and device_process_message in wined3d)
              • Allow IDirect3DSurface9::GetDC to work
              • Report resolution changes properly to the application (another message handling fun)
              • Swapchain window overrides
              • Any of the new Win32<->d3d9 interaction features in d3d9ex.


              Also the code writes directly to the top level X11 drawable. If the application renders to a Win32 child window (e.g. the StarCraft II map editor), the GDI elements on the Window will just be overwritten by the gallium rendering output. This is difficult to fix because child windows are not X11 windows - they're just managed by Wine itself due to window management differences between X11 and Win32.

              There are plenty of applications that work fine without any of those things, but there's a whole set of applications that will never work without a major redesign. And with that redesign you open up an entirely new can of worms. You'll have to think about a common interface for all d3d versions and how to mix different Mesa and Wine versions.

              Don't get me wrong - Christoph Bumiller knew what he was doing when he wrote this thing. It avoids many pitfalls some of the "hello world" d3d and ddraw implementations out there have. But he also knew what he was doing when he made this a proof of concept research project.

              I welcome any efforts to maintain this code and make it run more games. Even if we don't include it in Wine anytime soon it is a useful benchmarking and debugging tool. And it allows users to choose and use whatever fits them best.

              If I can help by answering questions about the technical details of Direct3D I'm more than happy to do so - just contact me directly or mail wine-devel. If I may make a suggestion for the way forward: Try to make Wine's d3d9 tests work. Some of those tests may seem like they're testing unimportant details, but all of those were inspired by real application behaviors and debugging the tests is way easier than debugging binary blobs. Furthermore, making those tests run is the perfect way to show you mean business.

              Note that we don't believe that there are legal issues with this code. Those problems were about the d3d10/11 pipeline implementation attempt. The d3d1x authors used confidential headers from the Windows DDK to code their software. This is not the case for gallium-nine to my knowledge.
              Do you have any idea of how Valve's togl works? Just wondering. It has a very low overhead.

              Comment


              • #67
                Originally posted by stefandoesinger View Post
                Ok, now that the flamewar has toned down a bit let me join the party

                I stand by my statement that writing a Mesa-specific d3d implementation is inferior to improving the platform independent code as long as the platform independent code has room for improvement. That statement has been discussed ad nauseam, so let's have a look at the wine patch that integrates gallium-nine:

                The integration is done by exporting an IDirect3D9-like interface from Mesa. This has the advantage that the interface between Mesa and Wine is quite simple and I guess relatively stable, but it won't do any of those things:
                • Support ddraw or d3d8
                • Properly handle window messages (wined3d_device_acquire_focus_window and device_process_message in wined3d)
                • Allow IDirect3DSurface9::GetDC to work
                • Report resolution changes properly to the application (another message handling fun)
                • Swapchain window overrides
                • Any of the new Win32<->d3d9 interaction features in d3d9ex.


                Also the code writes directly to the top level X11 drawable. If the application renders to a Win32 child window (e.g. the StarCraft II map editor), the GDI elements on the Window will just be overwritten by the gallium rendering output. This is difficult to fix because child windows are not X11 windows - they're just managed by Wine itself due to window management differences between X11 and Win32.

                There are plenty of applications that work fine without any of those things, but there's a whole set of applications that will never work without a major redesign. And with that redesign you open up an entirely new can of worms. You'll have to think about a common interface for all d3d versions and how to mix different Mesa and Wine versions.

                Don't get me wrong - Christoph Bumiller knew what he was doing when he wrote this thing. It avoids many pitfalls some of the "hello world" d3d and ddraw implementations out there have. But he also knew what he was doing when he made this a proof of concept research project.

                I welcome any efforts to maintain this code and make it run more games. Even if we don't include it in Wine anytime soon it is a useful benchmarking and debugging tool. And it allows users to choose and use whatever fits them best.

                If I can help by answering questions about the technical details of Direct3D I'm more than happy to do so - just contact me directly or mail wine-devel. If I may make a suggestion for the way forward: Try to make Wine's d3d9 tests work. Some of those tests may seem like they're testing unimportant details, but all of those were inspired by real application behaviors and debugging the tests is way easier than debugging binary blobs. Furthermore, making those tests run is the perfect way to show you mean business.

                Note that we don't believe that there are legal issues with this code. Those problems were about the d3d10/11 pipeline implementation attempt. The d3d1x authors used confidential headers from the Windows DDK to code their software. This is not the case for gallium-nine to my knowledge.
                Thank you for this comment. Right now from studying the code and reading about the implementation, the gallium-nine wine patch falls back to the wine d3d->opengl pipeline in cases it can't handle, that's not to say more cases can't be handled going forward but limitations of dealing with the architectural differences between X11, win32 and gallium do make things interesting.

                Are there any plans for a Wayland port of Wine? gallium-nine itself is in no way tied to X11, might it be easier to implement some of the deficiencies if/when Wine is targeting a wayland backend?

                Comment


                • #68
                  Originally posted by Dukenukemx View Post
                  The graphic cards we deal with, like 3DFX Voodoo, ATI Rage, and Nvidia Riva 128, were made for gaming. Every graphics card sold in retail stores like CompUSA, were for gaming. Todays graphic cards are based on that. Just so happens graphic cards are great for accelerating UI's and video decoding as well.

                  SGI products were meant for servers and workstations, not home computers.
                  Certainly, but SGI graphics cards were made 6-7 years before the first consumer 3d cards such as the ones you listed. Saying that they are not graphics cards because of their target market is kind of weird, wouldn't you say?

                  Comment


                  • #69
                    Originally posted by andrebrait View Post
                    Do you have any idea of how Valve's togl works? Just wondering. It has a very low overhead.
                    To my knowledge it works just like wined3d. It skips some d3d corner cases we have to handle and doesn't care that much about compatibility with older GPUs. That buys it a few CPU cycles. But the real magic is that it enables Nvidia's __GL_THREADED_OPTIMIZATION and the fglrx equivalent. Nvidia's threading code is optimized for the source engine without compromises, which makes this combination very fast. Nvidia refuses to support glMapBufferRange in their multithreaded command stream because it would make the source engine run slightly less optimal.

                    Though in my testing wined3d beats Valve's d3d->gl wrapper in Team Fortress on my old GeForce 9600. Valve's code beats wined3d hands down on the newer GTX 460 however. That was about a year ago, and I didn't yet have my command stream implementation back then.

                    Also, the source engine is a very efficient engine.

                    Comment


                    • #70
                      Originally posted by s_j_newbury View Post
                      Are there any plans for a Wayland port of Wine?
                      No immediate plans. We'll see how Wayland progresses.

                      The code refactoring we did to support the mac driver allows us to add drivers for other windowing systems much easier than we used to. (There goes the "wine only cares about macs" conspiracy theory...)

                      There are some design choices Wayland made that might make it difficult to support Win32 as well as we can on X11. Some applications that e.g. depend on global window placements may only work in a virtual desktop.

                      Originally posted by s_j_newbury View Post
                      gallium-nine itself is in no way tied to X11, might it be easier to implement some of the deficiencies if/when Wine is targeting a wayland backend?
                      No. It won't fix the fact that Direct3D is tied into Win32, which is where most problems come from.

                      Comment

                      Working...
                      X