Announcement

Collapse
No announcement yet.

DirectX...for X

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

  • DirectX...for X

    I've been thinking about this for a while now, and if I have my facts wrong, please feel free to correct me.

    Currently, gaming on Linux falls into two categories:

    1) native implementation
    2) Windows binary using WINE

    As far as I am aware, X uses OpenGL as its 3D renderer, and therefore something like Cedega or vanilla WINE essentially puts a DX9 library "in front of" the native OpenGL library and does the conversions back and forth.

    Or worse yet, does the whole thing in software. Of course, this conversion is slow and affects framerates.

    So my question is this: in the same way that I have a /usr/lib/libGL.so.169.12 which is built for my nVidia card, why can I not have a /usr/lib/libDX.so.169.12, which implements DX9 (or 8, or 10 or whatever), and is built for my card (since the GPU has hardware support for DX8,9,10 operations)

    Other DirectX stuff such as sound and networking is already handled nicely by WINE, so it's really the graphics stuff that needs to be plugged in.

    Is this possible? Would it require loads of work inside the X server? Is it worth petitioning nVidia to do something like this?

    Obviously there's no point in asking the games companies to support Linux natively because they won't.

    There's no point in asking the games companies to implement an OpenGL renderer if they haven't already done so, because they won't.

    So, the the only option I can see is to petition the hardware guys (nVidia, ATI, Intel etc) to produce a native DirectX renderer, since they know the APIs anyway.

    Opinions?

  • #2
    graphics stuff is steadily getting there.

    you cannot have a linux directx library, because you cannot link windows programs with linux libraries. that's why wine is necessary.

    Comment


    • #3
      Originally posted by alurien View Post
      So my question is this: in the same way that I have a /usr/lib/libGL.so.169.12 which is built for my nVidia card, why can I not have a /usr/lib/libDX.so.169.12, which implements DX9 (or 8, or 10 or whatever), and is built for my card (since the GPU has hardware support for DX8,9,10 operations)
      Because you're still talking about an API layer and NOT the driver layer. In this case, you're talking about basically the same thing WINE's doing right now.

      That's not the way to get there from here.

      And saying, "why don't we just make the driver layer, and use WINE for the API layer" won't get you there either. The driver layer for Direct3D is intrinsically tied to Windows and you'd have to implement a BUNCH of stuff from Windows exactly like it's done in XP/Vista/etc. to accomplish that. (Uh, shades of WINE here...again...)

      What you need to do is get the abstraction layer from WINE to be thinner and better or you need to get the studios to make MacOS or PS3 titles- and then convince them that it's a good idea to publish a Linux version to get what you're looking for.

      Comment


      • #4
        Thanks for the replies people. I guess I was elated by the fact that I saw windows/system32/d3d9.dll in my WINE installation, and was thinking that a d3d9.dll-->/usr/lib/libDX9.169.12.so (or ATI equivalent ) connection would be fairly simple to implement.

        If however as you say, the driver layer is glued into loads of other crap in Windows, then implementing a Direct3D layer would be ineffficient and problematic.

        Unfortunately, I also think the chances of the big titles (Age of Conan, WoW, Halo, Call of Duty etc) having native GNU/Linux versions are kind of remote. I suspect much of this is due less to market share, and more to fragmentation (and the support issues that go with it).

        Microsoft Windows is Microsoft Windows. Apple MacOS X is Apple MacOS X. GNU/Linux is...RedHat...SUSE...Ubuntu...I myself run Gentoo...


        With this in mind, I think the most sensible ways forward are either

        1. Microsoft untangles Direct3D from Windows, and publishes all the APIs for it, allowing Direct3D to be implemented natively on other platforms - if SGI, Sun, HP and 3D Labs (remember them?) can do it for OpenGL, I'm sure Microsoft can do it for Direct3D. In fact they could do it for the whole DirectX suite, but I'll take the graphics for now. This would then allow the likes of nVidia to ship both OpenGL and Direct3D implementations with their driver packages.

        The d3d9.dll in WINE could then call down directly to the native D3D9 implementation and pass the data structures directly. I think this'd be about as thin as WINE could get. Or nVidia actually supply a d3d9.dll that does the job directly - installing it into the WINE file structure could be tricky though.

        Of course this scenario is unlikely to happen.

        2. Petition the games companies to create OpenGL renderers for their games. The Windows version of World of Warcraft has both Direct3D and OpenGL renderers - obviously the OpenGL one is the one which works best under WINE/Linux. MacOS versions will use OpenGL, obviously.

        3. MINE...for want of a better term. A MacOS compatibility layer. MacOS X is much closer to GNU/Linux than Windows will ever be, is compiled nowadays for an Intel x86 instruction set, and uses OpenGL the same way that GNU/Linux with X-Window does. Such a layer would be (or should be) much thinner than WINE. Of course such a project is predicated on the fact that Apple won't sue...but is such a project technically possible?

        In all honesty I think Option Three is best. Even with OpenGL renderers, there are other stumbling blocks with Windows games - the .NET stuff used in Lord of the Rings Online, for example.

        I just hope we see some progress soon. I don't relish the idea of having to have a separate Windows machine just to game on...

        Comment


        • #5
          For a while I tossed around the idea of a Mac OSX compatibility layer. But why bother when the games aren't there either.

          And WINE is still api layer level so seeing libdx9.dll.so doesn't make a directx library for Linux any better than WINE's. In theory, if you wrote this, you could get Windows apps to use this library by re-routing the function calls into the lookup addresses of your loaded shared object, but this is already how WINE does things.

          I think it's much better to have developers develop for Linux/Mac OSX. I think it's the only route, really. And I don't mind the manner in which guys like id Soft and Bioware have released their Linux clients.

          They just have to come and companies have to start caring. Emulation? I think it only harms in the long run.

          Comment


          • #6
            Originally posted by niniendowarrior View Post
            They just have to come and companies have to start caring. Emulation? I think it only harms in the long run.
            I think he was thinking along the lines of making Direct3D the API for 3D graphics on Linux. All well and good if it was something sane (which it ISN'T, really...) and something that Microsoft fully published the API and expected behaviors...aaand then had everyone not misuse the bugs they invariably have in the stuff.

            If you had all the above, you could have cross platform games. Unfortunately for those wanting games and wanting to leave Windows, Bill and Co. have you solidly trapped. They have NO desire whatsoever to make it easy for you to leave. That should be an indication that you want to do so anyhow.

            Comment


            • #7
              I don't like emulation either, it only serves to slow things down. Unfortunately it's most likely the only route - at least for the short-to-medium term. That's the price for being part of the enlightened minority.

              As for the libD3D9.so concept, let me clarify my thoughts. As far as I am aware, the libGL implementation for nVidia cards basically calls on the hardware functions of the card, rather than making the CPU do the work, like this:

              Application->libGL.169.12.so->nvidia.ko

              My idea for Direct3D was this:

              Application->libD3D9.169.12.so->nvidia.ko

              In both cases "Application" is a native Linux app. For games running on WINE, it would look like:

              Game->d3d9.dll(WINE)->libD3D9.169.12.so->nvidia.ko

              In this case the d3d9.dll is little more than a "shell" DLL that internally passes the calls to libD3D9.so, which of course is a symlink to libD3D9.169.12.so.

              The point I'm trying to make is that there would be no conversion from Direct3D to OpenGL, just a straight pass-through, which I think would be faster, because the data structures wouldn't have to be modified.

              Obviously there's other stuff going on in WINE too, but my idea is predicated upon MS untangling DirectX from Windows, which is unlikely.

              I was doing some more research on this, and it seems direct-to-device pass-through is in the Xen development roadmap. Of course running Xen means running a copy of Windows, but assuming Direct3D-to-OpenGL conversion can be avoided, i.e Xen-aware gfx drivers on the Linux side, this would be fantastic - no I'm not a Windows fanboy...

              There's other work going on like VMGL, but that is only for X-Window based operating systems, however they claim up to 87% FPS of native, which isn't at all bad.

              Of course, I would love to see native versions of the big titles on GNU/Linux, but the sad fact is that the games companies' intellectual investment is in DirectX - at least if there were more OpenGL titles (or DirectX wasn't welded to Windows) we'd have more of a chance.

              Comment


              • #8
                Originally posted by alurien View Post
                Unfortunately, I also think the chances of the big titles (Age of Conan, WoW, Halo, Call of Duty etc) having native GNU/Linux versions are kind of remote. I suspect much of this is due less to market share, and more to fragmentation (and the support issues that go with it).
                There ISN'T any real fragmentation to speak of- at least not any that would be any different than Windows once you stop and think about all the OS versions, etc. that you have to deal with with them, especially Vista versions. All intrinsically different even though they have the "same" API, etc. It's a perception of the unknown that is keeping them from doing anything. They think there's no market to speak of, so they do nothing. It's more of a chicken and the egg problem really.

                Microsoft Windows is Microsoft Windows. Apple MacOS X is Apple MacOS X. GNU/Linux is...RedHat...SUSE...Ubuntu...I myself run Gentoo...
                Done right, Linux is largely that- ONE OS target. I know, I've developed commercial applications that handle that concept readily.

                1. Microsoft untangles Direct3D from Windows, and publishes all the APIs for it, allowing Direct3D to be implemented natively on other platforms - if SGI, Sun, HP and 3D Labs (remember them?) can do it for OpenGL, I'm sure Microsoft can do it for Direct3D. In fact they could do it for the whole DirectX suite, but I'll take the graphics for now. This would then allow the likes of nVidia to ship both OpenGL and Direct3D implementations with their driver packages.

                The d3d9.dll in WINE could then call down directly to the native D3D9 implementation and pass the data structures directly. I think this'd be about as thin as WINE could get. Or nVidia actually supply a d3d9.dll that does the job directly - installing it into the WINE file structure could be tricky though.
                Heh... The Direct3D API is published enough to code to it. That's actually sufficient to do porting and emulation/abstraction against. This is the very reason WINE/Cedega can DO what they do right now. The problem is that DirectX is a byzantine API with myriads of things to implement- something Microsoft has taken quite some time to build up to. It's part of why WINE's incomplete. Probably always WILL be that way because you're always playing catch up with a company that has NO desire whatsoever to make it easy for you to do that- it would take people out of their cash-cow status from them.

                Of course this scenario is unlikely to happen.
                Heh... Funny that...

                2. Petition the games companies to create OpenGL renderers for their games. The Windows version of World of Warcraft has both Direct3D and OpenGL renderers - obviously the OpenGL one is the one which works best under WINE/Linux. MacOS versions will use OpenGL, obviously.
                If they offer a MacOS version or have a porting interest have a MacOS version, then they're already doing it. It's not TOO difficult to make a port of a game, but all the same it's easier if you make it portable from the start. Now, having said this, what you need to have is a situation where you have the studios reserve the right to allow alternate OS ports or to have the publishers willing to allow them, both without insane royalty requirements to accomplish this.

                That, my friend, is the main reason we don't have as many games on Linux as we ought to.

                3. MINE...for want of a better term. A MacOS compatibility layer. MacOS X is much closer to GNU/Linux than Windows will ever be, is compiled nowadays for an Intel x86 instruction set, and uses OpenGL the same way that GNU/Linux with X-Window does. Such a layer would be (or should be) much thinner than WINE. Of course such a project is predicated on the fact that Apple won't sue...but is such a project technically possible?

                In all honesty I think Option Three is best. Even with OpenGL renderers, there are other stumbling blocks with Windows games - the .NET stuff used in Lord of the Rings Online, for example.
                One would suppose a WINE-like layer for MacOSX could be possible, especially considering that we sit on X86 and PowerPC in the same manner they do.

                In the end, though, it's still really emulation. Not the right answer in the medium to long term.

                Comment


                • #9
                  Originally posted by alurien View Post
                  As for the libD3D9.so concept, let me clarify my thoughts. As far as I am aware, the libGL implementation for nVidia cards basically calls on the hardware functions of the card, rather than making the CPU do the work, like this:

                  Application->libGL.169.12.so->nvidia.ko

                  My idea for Direct3D was this:

                  Application->libD3D9.169.12.so->nvidia.ko

                  In both cases "Application" is a native Linux app. For games running on WINE, it would look like:

                  Game->d3d9.dll(WINE)->libD3D9.169.12.so->nvidia.ko

                  In this case the d3d9.dll is little more than a "shell" DLL that internally passes the calls to libD3D9.so, which of course is a symlink to libD3D9.169.12.so.

                  The point I'm trying to make is that there would be no conversion from Direct3D to OpenGL, just a straight pass-through, which I think would be faster, because the data structures wouldn't have to be modified.

                  Obviously there's other stuff going on in WINE too, but my idea is predicated upon MS untangling DirectX from Windows, which is unlikely.
                  If you wanted to do that, here's a better idea.

                  libSDL -> nvidia.ko
                  libSDL -> fglrx.ko

                  I wonder of the performance impact of the work though. Possibly negligible.

                  Comment


                  • #10
                    Originally posted by niniendowarrior View Post
                    If you wanted to do that, here's a better idea. libSDL -> nvidia.ko libSDL -> fglrx.ko I wonder of the performance impact of the work though. Possibly negligible.
                    I'm not familiar with SDL, although I've compiled software against it. Why do you mention it? Is it comparable to DirectX? Do Windows games also make use of it? Or is it a cross-platform equivalent of DirectX?


                    EDIT:

                    I've just don some preliminary research on SDL and basically answered my own question. So the question is: why aren't more games companies using SDL, as well as contributing to it? Strategically, it's in their interest - it'll work out a lot cheaper than paying Microsoft for DirectX (which I'm sure they do), and they get to pick up licenses on the other platforms i.e. GNU/Linux and MacOS X.

                    POSIX, OpenGL and Java have already proved the value of cross-platform. However, SDL, by introducing another layer, will have a certain effect on performance - the Windows version calls down into the appropriate DirectX libraries, rather than hitting the drivers directly. I think the GNU/Linux version calls on X-Window + OpenGL, OSS, USB (i think) for input.
                    Last edited by alurien; 12 March 2008, 10:11 PM.

                    Comment

                    Working...
                    X