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; 03-12-2008, 10:11 PM.

                    Comment


                    • #11
                      SDL stands for Simple DirectMedia Layer and it was developed by Loki Games (maintained by Ryan AFAIK) as an API layer to easily port/develop games by providing interfaces to networking, audio, video, etc.

                      While SDL is not DirectX, it's a close equivalent and it did make Loki's task of porting DX games relatively more straight forward than without. At least that was the theory, hehe.

                      I reckon some commercial Linux games use this (all Loki ones, I think) as well as games like Neverwinter Nights.

                      SDL's video section, I think, kind of wraps to OpenGL. It's been a while since I've last handled SDL though so I could be wrong.

                      I'm sure Svartalf can provide more accurate info. I feel old already. hehehe.

                      Comment


                      • #12
                        Originally posted by niniendowarrior View Post
                        SDL stands for Simple DirectMedia Layer and it was developed by Loki Games (maintained by Ryan AFAIK) as an API layer to easily port/develop games by providing interfaces to networking, audio, video, etc.
                        Heh... I'm not sure what official/original relationship SDL had with Loki- my somewhat fuzzy recollection of things places SDL's existence a tad bit before Civ:CTP's start of development (i.e. the start of Loki...); that could be wrong, but I do know that SDL was actively maintained by Loki during it's existence- with varying parties maintaining it throughout it's existence, including Sam Lantinga and Ryan Gordon. I think Sam's still got some involvement in the whole thing, even.

                        The rest would be pretty accurate though. However, having said this, the sound support's VERY primitive and the network support's also that way- you'll want to probably consider using OpenAL-soft or Portaudio for sound and Grapple or OpenPlay (I'd vote for Grapple, myself- while it's an LGP originated LGPL library, there's a REASON we ditched OpenPlay and spent 4-6 months inventing Grapple...) for the networking.

                        While SDL is not DirectX, it's a close equivalent and it did make Loki's task of porting DX games relatively more straight forward than without. At least that was the theory, hehe.
                        Theory sometimes is the reality. Sometimes, it's not so- it's not always the impedance mis-match between the APIs that is the problem. It's the atrocious code that VC++ allows a studio to get away with that is the real bugbear in a porting project.

                        Keyboard and joystick is close enough to not be too much of an issue. Simple sound playback is also not an issue. Simple networking is not an issue. Basic threading as well. For positional and more complicated Audio, OpenAL was supposed to be the biggie- on MacOS and Windows, it still is. With OpenAL-soft, it should be back on track for Linux. Grapple should handle many of the network solutions- unfortunately, it's not interoperable with DirectPlay.
                        2D graphics is dealt with nicely so that differences in getting a framebuffer plane is simplistic- and in some cases, some functionalities are hardware accelerated on the platform where possible. 3D is handled by your system's OpenGL layer, but it provides a clean wrapper framework to tie into it portably.

                        All in all, if you WRITE a game with SDL, OpenAL, and Grapple, you'll end up with a title that will cleanly run on Linux, MacOS, Windows, and more. There may be some performance glitches on some platforms (On Windows, it wraps DirectX with a thin shim, but it's still there... And so on, and so forth...) but all in all, it's not a bad way to make a game if you want to target things easily.

                        I reckon some commercial Linux games use this (all Loki ones, I think) as well as games like Neverwinter Nights.
                        Pretty much every one of them that I know of brings in SDL to provide the threading handling, user input handling, and OpenGL abstraction handling. It makes life a bit easier.

                        I'm sure Svartalf can provide more accurate info. I feel old already. hehehe.
                        YOU feel old? Damn, I feel ancient.

                        Comment


                        • #13
                          Originally posted by Svartalf View Post
                          Heh... I'm not sure what official/original relationship SDL had with Loki- my somewhat fuzzy recollection of things places SDL's existence a tad bit before Civ:CTP's start of development (i.e. the start of Loki...); that could be wrong, but I do know that SDL was actively maintained by Loki during it's existence- with varying parties maintaining it throughout it's existence, including Sam Lantinga and Ryan Gordon. I think Sam's still got some involvement in the whole thing, even.
                          Yeah. Sam does have involvement in the project. Much of what I said, I'm basing on what I remember from Sam Lantinga's book before. I think Sam spear-headed SDL development when Loki was starting, or something like that. My memory is terrible with details though, so it's fudged with Rocky Roads and Black Forest cake.

                          Thinking about SDL, OpenAL and others makes me think of how I should have taken SDL a bit more seriously. But well, SDL is still a nice api to have to build games. If it directly interfaced with the GL procedures of graphics card, I wouldn't know how good would that do.

                          I tend to think the benefit of doing that is almost negligible.

                          Comment


                          • #14
                            Originally posted by niniendowarrior View Post
                            If it directly interfaced with the GL procedures of graphics card, I wouldn't know how good would that do.

                            I tend to think the benefit of doing that is almost negligible.
                            Direct acceleration of 2D functionality, even when a title is Windowed (which right now fubars hardware acceleration in many situations...). It's a definite benefit, esp. with us going to AIGLX, etc. How much of one, I couldn't tell you, but it's not negligible. I just don't know if the payoff would be worth the needed work.

                            Comment


                            • #15
                              Originally posted by niniendowarrior View Post
                              If it directly interfaced with the GL procedures of graphics card, I wouldn't know how good would that do.

                              I tend to think the benefit of doing that is almost negligible.
                              I'd assume the benefit would be great, but I suppose it depends on what you want the end result to be.

                              I might be wrong, but accelerating 2D stuff in hardware might not be worth it with a fast CPU - the desktop might be responsive enough that you could get away with it.

                              Obviously 3D stuff is a different kettle of fish, and needs to be done in hardware.

                              So the question is, for games and other 3D stuff is libSDL.so->nvidia.ko worth the effort over libSDL.so->libGL.so->nvidia.ko?

                              Are the SDL data structures that different from OpenGL ones?

                              Comment

                              Working...
                              X