Announcement

Collapse
No announcement yet.

Grand Theft Auto Running On Direct3D Natively On Linux Shows Gallium3D Potential

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

  • #81
    The whole "It only works for a small subset of Linux users" could be easily overcome by having Nvidia and AMD support D3D9 (at the very least) in their binary drivers as well. Then the odd man out will be Intel, and then by a 2/3s majority, Wine might very well take the patches upstream.

    Then, once Intel implements D3D9 (eventually), Wine can literally cut out that entire part of their codebase and rely solely on the drivers, merely translating non-GPU stuff, which should make pretty much every application run through wine more stable and faster

    Some people keep screaming to keep D3D away from Linux, but it's not evil and it would definitely do more good than harm being over here.

    Comment


    • #82
      Seems to be this is an useless effort , due to this is never going to be mainlined.
      So, how can I install it?

      Comment


      • #83
        Open source community should just provide solid tools, open drivers and open standads to its users and developers. I personally don't want half baked and imitating technologies in my box.
        Porting closed source apps to linux is job of its owners not open source developers (see Steam). They would be fine in containers which wouldn't risk my security and privacy of my base system, though.

        Comment


        • #84
          Originally posted by edoantonioco View Post
          Seems to be this is an useless effort , due to this is never going to be mainlined.
          Not sure why you think this way because there was d3d1x state tracker before and VMWare have Gallium-based D3D state trackers internally. E.g they even merge some changes to support them into mainline: 5a12155503c9cd0cc77b0a0e52bc563c39631275) (2014-07-30).

          As some guy in this topic stated serious advantage of having D3D state tracker in Mesa it's not only useful for running games with Wine, but it's make possible to pass D3D commands from Windows VM without hardware virtualization. Considering Intel make their own implementation of this layer (XenG) which only work with Intel drivers) it's can be interesting to have alternative for Gallium drivers.

          Also few Mesa devs was quite positive about that, but obviously first there have to be maintainer for this code.

          Comment


          • #85
            Originally posted by Daktyl198 View Post
            The whole "It only works for a small subset of Linux users" could be easily overcome by having Nvidia and AMD support D3D9 (at the very least) in their binary drivers as well. Then the odd man out will be Intel, and then by a 2/3s majority, Wine might very well take the patches upstream.
            Hmm I dont know about that, I guess if they could do that by themself with wayland support without changing other lisensens and brake dependencies or forcing kernel devs to rape the gpl a bit more, it would be ok.

            But I think I would be more happy if it would stay gallium3d only and so free drivers only advantage. I just looked it up gallium3d is under the mid lisense so theoretical the proprietary drivers could be ported to gallium3d too as far as I understand it.

            But I guess it would be hard to port the big glunky monster drivers or rewrite em to gallium3d. And would take much longer than when u do port a free driver. Because this are basicly windows drivers with big junks from windows ported to linux.

            So for amd it would be more easy to make the free driver nearly feature and speed par with the proprietary driver than port the blob to a gallium blob?

            And to not make this dx layer as abstracted gallium state tracker or modul or whatever, would be the wine solution.

            Wine is btw also nativ linux not more or less than this solution, its maybe more lowlevel with one or 2 less layers between native but thats about it.

            If u would messure nativness by this category dx12 would be more native than the predecessors because its a more direct smaller layer to the hardware. (at least thats what I am reading)

            Comment


            • #86
              unigine valley (wine nine,opengl,wined3d) vs native opengl
              http://www.gearsongallium.com/?p=1406

              nine - 985
              opengl - 937
              wd3d - 482
              native - 940

              Comment


              • #87
                Originally posted by LiquidAcid View Post
                That does not make any sense. You either use DRI3, or you use DRI2. And DRI2 offloading works, you just have to have a DDX loaded for the secondary card.
                Sorry, this is not what I meant.

                I am using intel ddx with DRI3 as my main graphics driver.

                I can do LIBGL_DRI3_DISABLE=1 glxgears to render glxgears on intel with DRI2.

                I can use DRI_PRIME=1 glxgears to offload rendering to the radeon GPU with DRI3.

                But I can not do LIBGL_DRI3_DISABLE=1 DRI_PRIME=1 glxgears to offload rendering to the radeon GPU with DRI2 even if the X server loaded xf86-video-radeon. I just tested that...

                Comment


                • #88
                  Originally posted by RavFX View Post
                  Just found out that with Mesa-3D, now, normal wine (without d3d9 patch), crash:

                  r600_texture.c:413:si_texture_get_cmask_info: Assertion `0' failed.

                  returning to normal Mesa
                  That's weird. What's your GPU and version of DRM?

                  Comment


                  • #89
                    Originally posted by ChrisXY View Post
                    But I can not do LIBGL_DRI3_DISABLE=1 DRI_PRIME=1 glxgears to offload rendering to the radeon GPU with DRI2 even if the X server loaded xf86-video-radeon. I just tested that...
                    Check if you've set a offloadsink and if that doesn't help, file a bugreport.
                    Last edited by LiquidAcid; 31 July 2014, 11:01 AM.

                    Comment


                    • #90
                      Originally posted by ChrisXY View Post
                      Sorry, this is not what I meant.

                      I am using intel ddx with DRI3 as my main graphics driver.

                      I can do LIBGL_DRI3_DISABLE=1 glxgears to render glxgears on intel with DRI2.

                      I can use DRI_PRIME=1 glxgears to offload rendering to the radeon GPU with DRI3.

                      But I can not do LIBGL_DRI3_DISABLE=1 DRI_PRIME=1 glxgears to offload rendering to the radeon GPU with DRI2 even if the X server loaded xf86-video-radeon. I just tested that...
                      It works for me LIBGL_DRI3_DISABLE=1 changed dri3\dri2 offload rendering

                      Comment

                      Working...
                      X