Announcement

Collapse
No announcement yet.

Mesa 21.1 Addresses Issue Of Gallium Nine Often Hitting Memory Issues With 32-bit Games

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

  • Mesa 21.1 Addresses Issue Of Gallium Nine Often Hitting Memory Issues With 32-bit Games

    Phoronix: Mesa 21.1 Addresses Issue Of Gallium Nine Often Hitting Memory Issues With 32-bit Games

    For those using Gallium3D Nine as a Direct3D 9 state tracker when running Windows games on Linux rather than the likes of DXVK for going through Vulkan, next quarter's Mesa 21.1 will better handle 32-bit games with the Nine state tracker...

    https://www.phoronix.com/scan.php?pa...er-D3D9-32-bit

  • #2
    You no longer need to run a patched Wine, there is Nine Standalone which lets you replace the DX9 dll the same way DXVK works

    Comment


    • #3
      Originally posted by FireBurn View Post
      You no longer need to run a patched Wine, there is Nine Standalone which lets you replace the DX9 dll the same way DXVK works
      Indeed. And since it's a Wine DLL, it also gets automatically picked by e.g. symlinking it as d3d9.dll into the game's folder (also with Proton, at least it used to work).

      Comment


      • #4
        I didn't know about this memfd thing, it sounds like a very cool feature.

        Comment


        • #5
          Originally posted by Weasel View Post
          I didn't know about this memfd thing, it sounds like a very cool feature.
          Weasel you really do need to learn a bit about memfd it.
          https://dvdhrm.wordpress.com/2014/06/10/memfd_create2/
          https://lwn.net/Articles/591108/
          The file sealing bits around memfd are design for composting.

          Graphics-Servers: This is a very specific use-case of IPC and usually there is a one-way trust relationship from clients to servers. However, a server cannot blindly trust its clients. So imagine a client renders its window-contents into memory and passes a file-descriptor to that memory region (maybe using memfd_create) to the server. Similar to the previous scenario, the server cannot mmap(2) that object for read-access as the client might truncate the file simultaneously, causing SIGBUS on the server. A server can protect itself via SIGBUS-handlers, but sealing is a much simpler way. By requiring F_SEAL_SHRINK, the server can be sure, the file will never shrink. At the same time, the client can still grow the object in case it needs bigger buffers for growing windows. Furthermore, writing is still allowed so the object can be re-used for the next frame.
          Useful right protections of memfd were design particular way that is useful in these graphical cases. Not only is memfd shared memory but memfd secure shared memory and being a file process using memfd does not have to map the complete memfd into their address space..

          Yes the way gallium nine is is using memfd is exactly one of the use cases memfd was exactly made for being graphical things.

          Weasel there are a lot of things built into the Linux kernel it self that are there particular for memory management around graphical systems.

          You find memfd features used with open source GBM and DMA BUF as well. So yes memfd is quite a heavily used feature in large sections of the open source graphics stack for different things. So galluim 9 choosing to use memfd is not strange with different opengl drivers and other bits in mesa are also using memfd for same kinds of problems as well.

          Comment


          • #6
            Nice to see that the idea of directly supporting directX is not dead. Every layer of conversion feels like a waste of performance and additional complexity.

            Comment


            • #7
              Hi, sorry for intervening, but I'm trying to find out how to take advantage of this for my pre-GCN AMD card inside an older laptop. I can select oibaf repository for MESA on Ubuntu 20.04 to get the latest. Will I get the latest and matching developments in GalliumNine Standalone?
              Another question I always wanted to ask: what happened to GalliumTen (pointone)?

              Comment


              • #8
                Gallium Ten was dropped as no-one maintained it. It also had the disadvantage to need wine to be compiled, and I don't think it was able to do more than a hello word.

                Also Vulkan is probably a better solution to implement D3D10/11. Some D3D10/11 optimization include ways to reduce overhead by recording states and replaying them efficiently. You cannot do that with Gallium. I don't know if DXVK implements these optional features, but it is probably in a better position to implement them than Gallium.

                With the oibaf tree you get recent mesa, if it doesn't have the new patches yet, it's likely to come up soon.


                Comment


                • #9
                  sweetsuicide
                  The best way (for me) to get Gallium nine on Ubuntu 20.04 (or Kubuntu):

                  HTML Code:
                  sudo apt-get install libd3dadapter9-mesa
                  HTML Code:
                  sudo apt-get install libd3dadapter9-mesa:i386
                  and then select the Wine prefix and execute:
                  HTML Code:
                  winetricks -q galliumnine
                  mannerov
                  The failed Direct3D 10/11 State Tracker (the name was NOT Gallium 10) cannot be compared directly with Gallium Nine. These two are completely DIFFERENT. They share almost NOTHING. This starts with the code, Gallium Nine is mostly written in beautiful C while the other was written in C++ and relying therefore on "horrific multiple inheritance with templates hacks" (to make gcc generate COM-compatible vtables). Sorry, I am not a coder so I don't really understand what this exactly means. More interesting details can be found here: https://lists.freedesktop.org/archiv...ly/041900.html

                  Another point is that the original Direct3D 10/11 State Tracker was INCOMPLETE, UNSTABLE and therefore BUGGY. Out of an retrospective point of view, It should never (ever) have been merged upstream. This was a colossal failure. It looks that the Wine devs were so frustrated by that UNMAINTAINED code, that they develop a special form of "code phobia". (The original Direct3D 10/11 State Tracker was coded in a really remarkable hardcore-approach by just one guy.)

                  Whatever, that debacle then also closed the upstream doors for Gallium Nine. (This was out of mine view a really bad decision.) Whatever, Gallium Nine Standalone is the answer for that. It is still alive and active developed. Also "normal users" like me can get the advantages of this free and open-source DirectX 9 for Linux. Yes, DXVK is nice for systems which supports Vulkan. But there are still many who don't support Vulkan. So the solution for these would be a clean and stable Gallium Eleven. Then I will also get near 1:1 DX11 performance at my Radeon HD 6770M (which is built-in in my iMac 12,2 computer). Well, I am just a retro-gaming guy so I really don't need Vulkan.
                  Last edited by lorn10; 09 March 2021, 08:25 AM.

                  Comment


                  • #10
                    Originally posted by lorn10 View Post
                    You cannot compare the failed Direct3D 10/11 State Tracker (the name was NOT Gallium 10) with Gallium Nine. These two are completely DIFFERENT. They share almost NOTHING.
                    he probably knows it since he is author of subj

                    Comment

                    Working...
                    X