Announcement

Collapse
No announcement yet.

Direct3D 9 Support Released For Linux Via Gallium3D, Running Games

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

  • #41
    I'm still not convinced it will go well with Wine developers. They're a conservative bunch. Heck, they don't even have PulseAudio support yet. But I'd love to see that. It would probably mean that r600g would run faster than fglrx when playing certain games on Wine. It would also be nice to see benchmarks.

    Comment


    • #42
      Originally posted by BO$$ View Post
      Right now it's so much easier and less error prone to just boot windows when you wanna play.... For many years nothing will change in Linux when it comes to games. Things are starting to move but it will take many years before we will be able to play windows games on Linux at similar performance.
      You're doing it wrong.

      Comment


      • #43
        Not much to celebrate, DX9 is dead. This will probably be the last year of any real DX9 support, but most major titles don't have it.
        On the upside, many titles are getting linux ports.

        Comment


        • #44
          This has got to be one of the most epic news articles ever. Can't wait to try this out. One more reason why the OSS stack is better.

          Comment


          • #45
            Nor Nvidia, nor AMD, nor Intel or other company provide the D3D state_trecker with their Linux driver, only the OGL state_tracker. As you all know core drivers are unified and they accept state trackers for different APIs (libD3D32.dll - libGL32.dll). Also front-ends like HLSL to IL are not provided ether in order to support native HLSL compilers. The best solution is to have an D3D state_tracker for MESA that you can use with closed drivers as well in the future. In the beginning you can use MS_HLSL_compiler with the GLSL_backend (front-end for the driver) and a simple patch, you can have IL or HW code this way. Then you can have your own compiler. Wine today uses MS_HLSL_compiler to do D3D_asm (lower level vm bytecode), but not IL or HW code. Then they use D3D_asm to OGL_source. Then they give OGL_source to the GPUs_GLSL_compiler to make first vm bytecode and then IL or HW code. Emulation=Not good. State_trackers=Good. The same for everything else, for example Flash state_tracker for HTML5. That way you don't translate anything, you just add Flash scripting support to HTML5 and HTML5 mechanism does the rendering (with special rules).

            Comment


            • #46
              Originally posted by zhasha View Post
              You say this as if we didn't learn from Luca. Key differences:
              Hopefully it would be implemented into Wine. Cause honestly, it's the #1 reason to have DX9 in Linux.

              No, (at least) on newer cards there is no kernel support for reclocking, and thus your card is running at 1/10th its max speed, always. The 3D driver is very good.
              The driver maybe good if the reclocking issue is fixed, but it isn't. Unless the reclocking is a minor issue to fix.

              Comment


              • #47
                Originally posted by shmerl View Post
                CDPR said it several times in various interviews which they gave.


                If a game is written for DX11 can run on DX10 and DX9 Hardware. That's because the API can choose the rules 11.5, or 10.4, or 9.3 profile. The same can be done for the Mesa D3D state_tracker.

                Comment


                • #48
                  One of the problems for the D3D10/11 state tracker is that the Shader Model 4.0+ binary formats are undocumented. I've been on a couple of the DX team's asses about this; it's stupid. Their argument was "we don't want to have to maintain compatibility" which of course is silly since they have to anyway. I've also been told they've had trouble getting a big enough budget given how key DX is to the entirety of Windows these days so getting a technical writer to maintain quality docs is a problem, which is silly but more management's fault than their own. I think maybe I got the point across but if anything comes of it it probably won't be until 8.1 ships or likely even later. I'm told that at least the issue whre the compiler was considered a "developer tool" is being fixed in the next SDK and Windows Blue update, which helps Linux not at all, but at least means Windows Store apps can now compile shaders on the fly (not as useful for games, but handy for game editors or graphics toolsets/sandboxes).

                  Note that projects like MojoShader only work on SM3 or under files, for which the format is documented.

                  More (courteous!) pressure on Microsoft Connect might help resolve the documentation issue faster.

                  Comment


                  • #49
                    Originally posted by peppercats View Post
                    Not much to celebrate, DX9 is dead. This will probably be the last year of any real DX9 support, but most major titles don't have it.
                    On the upside, many titles are getting linux ports.
                    Not at all. WinXP is still the dominant OS in many parts of the world. Gl is still a horrible API with buggy-as-hell drivers commonplace. Companies that are smart enough to target more than just the US still want to target DX9 for at least a couple years until/unless China and the like starts pirating Windows 7 instead of XP.

                    Comment


                    • #50
                      DX9 3D is all about games. And Wine is about LEGACY/CURRENT apps.

                      Add those two, and you will get plenty of use cases for such integration, even if every and each FUTURE app would use DX10/11.

                      Comment

                      Working...
                      X