Forgot your password?
typodupeerror
Graphics Wine Games Linux

Direct3D 9 Comes To Linux, Implemented Over Mesa/Gallium3D 138

Posted by Soulskill
from the and-so-soon dept.
An anonymous reader writes "Picking up the code from a failed Direct3D 10/11 implementation for Linux, a working Direct3D 9 state tracker has been implemented for Linux. The Direct3D 9 support works with open-source Linux GPU hardware drivers via Mesa's Gallium3D and can run games for the open-source Radeon and Nouveau drivers without simply converting the Direct3D commands into OpenGL. Unlike the experimental D3D10/11 code from the past, this D3D9 state tracker is already running games like Skyrim, Civilization 5, Anno 1404, and StarCraft 2. With Linux games not natively targeting D3D, Wine was modified for using this native Direct3D implementation."
This discussion has been archived. No new comments can be posted.

Direct3D 9 Comes To Linux, Implemented Over Mesa/Gallium3D

Comments Filter:
  • simply... (Score:5, Interesting)

    by wonkey_monkey (2592601) on Wednesday July 17, 2013 @06:59AM (#44306719) Homepage

    can run games for the open-source Radeon and Nouveau drivers without simply converting the Direct3D commands into OpenGL.

    Presumably "simply" isn't the right adjective, because it implies that converting from Direct3D to OpenGL is the better way of doing things - what's the problem with converting Direct3D commands to OpenGL? Slow?

    • Re:simply... (Score:4, Informative)

      by Tx (96709) on Wednesday July 17, 2013 @07:05AM (#44306753) Journal

      The last line of the TFA implies that it's a performance issue; "It will be interesting to see if this Direct3D 9 state tracker takes off for Linux and whether Wine developers will optionally support it for better performance.". It would have been nice to have some more info on why this is worth doing though, it seems to be one of those articles written for people who already follow the subject, rather than casual readers.

      • by DrYak (748999) on Wednesday July 17, 2013 @08:44AM (#44307241) Homepage

        it seems to be one of those articles written for people who already follow the subject, rather than casual readers.

        Yup, indeed, it's just a small quick news on phoronix.

        For the others:
        - Mesa is the opensource 3d graphics driver used on Linux for opensource drivers.
        (- the closed sourc drivers uses their own sauce instead)

        - the old classic mesa is just a plain big monolith exposing OpenGL (that's what Intel provide for their official opensource drivers.
        - the modern Gallium3D Mesa is a modular architecture for 3D API (that's what is used by modern opensrouce drivers, like the reverse engineered Nouveau for Nvidia, or the AMD-sponsored Radeon driver).

        The idea of the Gallium3D modular design:
        - on one side you have low-level drivers handling the hardware (or the CPU in the case of the LLVMpipe software driver) and exposing the basic GPU functionnality.
        - on the other side you have "state tracker" high-level interfaces speaking the various API (OpenGL, OpenCL, etc.)
        This make the whole development much faster and help code reuse.
        - If a new hardware comes, you only develop a new low-level drivers exposing the functionnality of this new GPU. And bam! you get automagically support for any API for which you provide the necessary functionnality. No need to write a complete new OpenGL driver from scratch.
        (That's how most of the newer opensource drivers, like all the new GPU for ARM SoC are implemented or are going to be implemented)

        -If you want an additionnal API, you only develop a state-tracker, the high level part of Gallium which speaks the API. And bam! you get automagically support for any hardware whose low-level provide enough functionnality. No need to write a full Direct3D stack for each single available hardware, just write a generic stack for Gallium.
        That's what is being done regarding DX3D9 in this news.

        Up until now, the way 3D worked for Windows software running under Wine, is that wine has a layer that intercepts all DX3D calls and retranslate them into OpenGL then sends those to the running OS (to Linux or Mac OS X).
        It works, but it's difficult, and it's slow: this translation layer comes at a cost. Even more so because OpenGL and DX3D do not function in the same way, so implementing some stuff requires quite a complicated translation.

        Now this Gallium stack is much more direct, it receives Direct3D calls and directly execute them using the low-level functionnality exposed by a hardware layer. It doesn't need to go throug a complex intermediate translation step.

        The advantages of this approach are:
        - It's much faster that way, because we directly call hardware function, instead of having to map to concept from another API (openGL) which doesn't work the same way.
        - It's quick to develop, specially because Gallium has already support for most of the needed functionnality to provide Direct3D 9 (unlike an older Direct3D 10/11 driver which were attempted earlier).
        - For older Radeon hardware, the opensource driver is what AMD recommand, they are stable enough, fast enough, and still maintained. So you're probably getting near native spead when running windows software on linux through wine, instead of slow down due to the opengl translation layer of wine.

        The problems of this approach are:
        - It only works with Gallium.
        - Intel official opensource driver don't use it (but there are attempts by 3rd parties to make gallium drivers)
        - AMD official drivers for current modern hardware is the closed-source catalyst (their own different stack).
        So either you get fast up-to-date Catalyst drivers, which only speak OpenGL and you have to put through with the wine translation layer. So you lose performance.
        Or you use experimental not-yet stable opensource drivers, which are gallium and thus do speak Direct3D 9, but they aren't perfected yet and are slower than Catalyst. So you lose performance too (albeit at a different level)
        (At least, on the radeon side, AMD is collaborating a

        • by snadrus (930168)

          Further:

          Positives:
          - Since this turns "A video card driver" into "a low-level hardware driver" + "state machines", and no part is intensively Linux-only, then it could be used to build drivers on other platforms.

          Negatives:
          - Intel thinks it'll be slower than a more integrated driver like what they build already.

          • by DrYak (748999)

            - Since this turns "A video card driver" into "a low-level hardware driver" + "state machines", and no part is intensively Linux-only, then it could be used to build drivers on other platforms.

            Saddly, the only current mainstream back-end relies on Linux' DRI2 architecture, so de-facto Gallium is currently Linux-only, even if the architecture has been touted as- and designed from the beging as- cross platform.

            Though, there is the LLVMpipe back-end (which instead runs on the CPU), and there are backend being developed for virtual machine (which forward the instructions from the guest's gallium to the host's gallium).
            This could very soon be adapted to windows with the present DirectX 9 state tracker

    • by pipatron (966506)
      It might also have issues with things "lost in translation", but that's just a guess, I know nothing about it.
    • Presumably "simply" isn't the right adjective, because it implies that converting from Direct3D to OpenGL is the better way of doing things

      No, it only implies simplicity and simplicity in and of itself does pose no implied quality -- something can be done simply, but it may still be the inferior choice in the long run as opposed to a more complex solution.

      - what's the problem with converting Direct3D commands to OpenGL? Slow?

      To put it short: yes. The arguments passed to D3D functions, for example, may be of different formats, number and lengths than those passed to OpenGL and therefore will require translation in the middle, ie. several extra steps. Obviously having to do extra steps in-between will result in a p

      • by ultranova (717540)

        The arguments passed to D3D functions, for example, may be of different formats, number and lengths than those passed to OpenGL and therefore will require translation in the middle, ie. several extra steps. Obviously having to do extra steps in-between will result in a performance hit.

        But isn't it even worse with Gallium? Now you need to translate arguments between the D3D/OpenGL/whatever state machine and the low-level state machine, and then again when the low-level state machine actually speaks to the h

        • But isn't it even worse with Gallium?

          Frankly, I do not know. I'm no expert here. But now that the thing is in place such tasks can actually be benchmarked and tested, and I would expect such benchmarks quite soon.

  • The closing line:

    "It will be interesting to see if this Direct3D 9 state tracker takes off for Linux and whether Wine developers will optionally support it for better performance."

    What is this, a high school paper? Need to fill space much?

    • What is this, a high school paper?

      No, a high-school paper would imply at least some sort of quality control.

      • by Khyber (864651)

        I guess you haven't read Twilight or Fifty Shades of Grey - both written on a high-school level (and TBH I could write better furry smut than the both of those combined in book and movie form could ever hope to achieve.)

  • by abies (607076)

    Ohhh, it is phoronix, not moronix... they could have chosen better font for logo...

    Anyway, I'm confused with the benefits here. From TFA

    [...]
    The Direct3D 10/11 state tracker excitement was ultimately shortlived as the upstream Wine development community wasn't interested in adding support for it since it's a Linux-only solution and at that it's *limited to those using Gallium3D*, which is basically the open-source *Radeon and Nouveau (NVIDIA) users*
    [...]
    Direct3D 9 state tracker can work so that the graphics

  • finally i can play those new games that came out... three to 11 years ago. [wikipedia.org]

    oh a serious note, progress is always good. it's really too bad transgamming killed cedega but didnt release any DX code. i really liked cedega and yes, paid the subscription fee for it.

    • by isorox (205688)

      finally i can play those new games that came out... three to 11 years ago. [wikipedia.org]

      oh a serious note, progress is always good. it's really too bad transgamming killed cedega but didnt release any DX code. i really liked cedega and yes, paid the subscription fee for it.

      Excellent, there have been very few games I've played in the last 13 years. My "current" CD collection includes Unreal Tournament and Klingon Honor Guard. Not that I've played them for years of course.

      I do play occasional things I my ithingy, usually ticket to ride.

    • by Khyber (864651)

      "i really liked cedega and yes, paid the subscription fee for it."

      That was your problem and the problem in general with the company. When you target a typically free software environment, you'd better offer your stuff for free or eventually someone else will come along and release a free alternative. And while said alternative might not be the best, it's free, and is 'good enough' that it will gain more support.

      • When you target a typically free software environment, you'd better offer your stuff for free or eventually someone else will come along and release a free alternative.

        you say that but there was no alternative if you want to play DirectX 9 and 10 games on linux. the difference between the WINE project and Cedega is that Transgaming targeted specific DX9/DX10 games and fixed their codebase until everything in the game worked. games on WINE never had "good enough" support to play the large majority or games and it's still like that. Cedega has been gone for many years and WINE still hasnt caught up.

  • by Anonymous Coward

    but Direct3D goes to eleven...

    next thing you know, we'll finally catch up to Windows 3.11 for workgroups.....oh wait

  • This is Microsoft's strategy to finally push XP off a cliff, and get longtime XP users to upgrade to something bett...well to something, at least.

  • by JustNiz (692889) on Wednesday July 17, 2013 @10:08AM (#44307977)

    Firstly, claiming that this is running natively is hardly accurate. Its running under WINE. Yeah I know Wine Is Not an Emulator blah blah, but running anything under WINE is a very hit-or-miss experience, certainly not what you would assume when someone says its running natively.

    What we REALLY need is for developers to switch from using any Microsoft-proprietary APIs at all. Technology such as this enables other developers to continue to backslide on change and continue down a bad Microsoft road as a (bad) way to get things onto Linux. That isn't the solution that anybody wants (except Microsoft because they know trying to run through copied Microsoft APIs shoots Linux in the foot so performance comparisons etc. cant even be a fair fight to begin with).
    The only right way (and the only thing that should e called "Native" ) is to switch to using native (i.e. non-microsoft) APIs such as OpenGL. That is the only good approach. everything else will always be a compromised mess.

    • much of that is due to the horrible support for direct x. this fix a lot of that problem. i wonder if react os will use this.

    • by nhat11 (1608159)

      Someday it might evolved into something more open but currently it works well and the majority of users are running windows. My only worry is fragmentation and having to buy multiple devices just to play a game I want to play.

    • by tepples (727027)

      The only right way (and the only thing that should e called "Native" ) is to switch to using native (i.e. non-microsoft) APIs such as OpenGL.

      OpenGL for graphics and what for input, audio, asset loading, saved games, and networking?

      • by JustNiz (692889)

        Even if DirectX did those things, the proper way for Linux would be:
        input: xf86-input-joystick or one of the many other input libraries.
        audio: alsa or one of the many other audio libriares.
        asset loading: libxml maybe? no idea.
        saved games: just dump it as a file to the file system like most games already do.
        networking: just use sockets like everyone else does.

        • switch to using native (i.e. non-microsoft) APIs

          xf86-input-joystick [...] alsa

          These APIs are not available on Windows. They are specific to Linux (or to UNIX in general). Or are you recommending making games exclusive to Linux instead of exclusive to Windows?

          just use sockets

          UNIX sockets work on UNIX, and Windows sockets work on Windows, but I thought key points of semantics differed between the two.

          • by JustNiz (692889)

            >> Or are you recommending making games exclusive to Linux instead of exclusive to Windows?

            If you're planning to releasing a game on Linux, then yes there should be a version that uses Linux's APIs not Microsoft's.

            • Let me try rephrasing this again: OpenGL is present on both Linux and Windows. But for a single game that has both Linux and Windows versions, what libraries present on both Linux and Windows should the developer use for things other than graphics? Or does each developer need to write its own wrapper library around the corresponding Linux and Windows APIs?
              • by JustNiz (692889)

                There are actually several different projects that do what you're asking.
                Perhaps the most well-known one is SDL:

                http://en.wikipedia.org/wiki/Simple_DirectMedia_Layer [wikipedia.org]

                However if you were a large and/or commercial developer you probably would prefer to develop your own wrapper library rather than use such a project, as then you could have full control of it.

  • by voss (52565) on Wednesday July 17, 2013 @10:50AM (#44308411)

    How many people still like to play games that are 5..7...10 years old. A lot of people

    Even relatively modern games like Civ 5 and WOW are quite happy with direct x 9.

    • by Rob Bos (3399)

      Nail on the head. What about old games makes them bad? If anything, the time filter eliminates the bad ones.

      And for those of us who've always gamed on Linux, being a few years behind is fine with me. I get new-to-me games cheaper. :)

      So, better DX9 layer? Huzzah, my existing games run a little bit better, and maybe it opens up some new ones! That's a little exciting.

    • by Khyber (864651)

      I'm still playing Battletoads on my NES, because most games simply don't offer that challenge that I'm used to.

      The gaming industry has dumbed down a LOT. Where we should have had complex games with intuitive interfaces, bean-counters vs creative types, bean-counters always win, unless said bean-counters are also the developers and programmers.

  • So am I right in my understanding that this only benefits users with ATI GPUs?

    • by Osgeld (1900440)

      no you are wrong

      open-source Radeon and Nouveau drivers

      Nouveau is the crap open source nvidia drivers

  • Poor DX support is really the only thing that's been holding me back on dumping windows for the last 5-8 years(every year is the year of the linux desktop right?) But, with this, and with any luck DX10/11 eventually, it may very well be enough to push 'nix in whatever flavor into the mainstream market and out of the realm of geeks. And yes, I know there's the oddball non-geek who's using it, or have had someone set it up for them. This on the otherhand if done right will take a major bite out of the Wind

The clearest way into the Universe is through a forest wilderness. -- John Muir

Working...