Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: Direct3D on GNU/Linux

  1. #1
    Join Date
    Aug 2008
    Posts
    11

    Default Direct3D on GNU/Linux

    I just saw this thread in the nVidia driver section, and it peaked my interest...

    http://www.phoronix.com/forums/showthread.php?t=8298

    After reading the article and the replies, I think it would be fantastic if Linux had a native implementation of Direct3D - at the end of the day, it's the most popular gaming API in use, and it would mean

    a) not having to use a separate Windows machine for gaming

    b) not having to put up with crap framerates in WINE due to the data structure conversions.

    The process chain would now be Windows Game->WINE(d3d9.dll)->libDirect3D.so.xxx->kernel_module.ko

    c) not having to wait until 3000AD for a native implementation of a mainstream title - think Crysis, World of Warcraft, Age of Conan. I don't live in a perfect world where the major titles are on every platform, so I'm looking at realistic options.


    I posted this in this driver section because

    a) if anyone is gonna be in a position to produce such software, it's gonna be a graphics card manufacturer, and that's basically AMD/ATI and nVidia. Their business is selling hardware, and they shouldn't care to whom they sell it, so a project like this would be an investment for them, not an expense.

    b) Having read the article on Crossfire X under Linux, it is plain that the scaling under Linux is far superior than the nVidia SLI equivalent, and this has gotten my interest with regard to my next upgrade.

    Of course the other way could be to install Windows under Xen and run the game that way, assuming the Linux video drivers are made Xen-aware - it would probably result in a smoother gaming experience than under WINE, but it would mean having to install Windows.

    I know AMD are in in the early days of support for GNU/Linux, compared to their Windows software, but I'd be interested to know their vision for GNU/Linux in the gaming market, and since we have an AMD/ATI rep here...

  2. #2
    Join Date
    Aug 2007
    Posts
    437

    Default

    Your are being too optimistic.

    If you've done some/any M$ programming stuff, you will know than any part of Microsoft "Technology" is tightly coped with Windows.

    Direct3D is purely based on COM object interface. You want D3D? fine, implement COM and all that crap in Linux, pls.


    Oh, and don't forget prepared for patent trolls

  3. #3
    Join Date
    Jan 2008
    Posts
    772

    Default

    I think you're conflating two separate issues:

    - Windows PE loader vs. native executable: Wine already supports both approaches. You can load a Windows executable via "wine" or you can compile a Linux binary with winelib.

    - DirectX-to-OpenGL translation vs. a "real" DirectX implementation: as a practical matter, a "native" implementation would probably need Gallium to be stable for a while so that someone could implement DirectX on top of it, and it would only make sense to do it as part of Wine/winelib, since pretty much any app using DirectX will need other Windows stuff as well.

  4. #4
    Join Date
    Aug 2008
    Posts
    11

    Default

    Quote Originally Posted by Ex-Cyber View Post
    I think you're conflating two separate issues:

    - Windows PE loader vs. native executable: Wine already supports both approaches. You can load a Windows executable via "wine" or you can compile a Linux binary with winelib.

    - DirectX-to-OpenGL translation vs. a "real" DirectX implementation: as a practical matter, a "native" implementation would probably need Gallium to be stable for a while so that someone could implement DirectX on top of it, and it would only make sense to do it as part of Wine/winelib, since pretty much any app using DirectX will need other Windows stuff as well.

    So which approach is likely to yield results in the near to medium future? DirectX isn't going to go away, and neither is Windows, and as long as both exist, games companies will continue to use them.

    Some games, like World of Warcraft, have an OpenGL renderer, which helps a great deal in terms of performance under WINE (although I suspect the OpenGL renderer was included for the MacOS X). However, OpenGL handles 3D and nothing else, like sound, input etc.

    Companies that have made an investment in DirectX aren't suddenly going to drop it and use SDL + OpenGL, as much as it'd be nice so see them do so, and very few of the major publishers will do a native GNU/Linux port.

    Also, if DirectX is so awkward to implement natively under GNU/Linux, nobody's going to bother.

    So it looks like we're left with three solutions:


    a) Continue using WINE, and take the performance hit - buy the fastest hardware you can possibly afford and hope it makes up the practical difference.

    b) Petition the graphics card manufacturers to support Xen in their GNU/Linux drivers, then go ahead and install a copy of Windows

    c) Petition the games companies to, at minimum, support OpenGL in their games - at least then we can partially lump ourselves in with the Mac crowd...

  5. #5
    Join Date
    Jun 2007
    Posts
    260

    Default

    I'd also agree that this could be done on Gallium. If I understood it correctly, it could be added as a rendering path to Gallium.

  6. #6
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,187

    Default

    ewww... just imagine if even a single distro will use --enable-directx-ugly-ugly-ugly-path when getting their gallium ready

  7. #7
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,584

    Default

    You guys have to remember that this potentially have all kinds of legal patent issues as well. Sometimes it's best not to wake the sleeping giant.

  8. #8
    Join Date
    Jun 2007
    Posts
    260

    Default

    Quote Originally Posted by curaga View Post
    ewww... just imagine if even a single distro will use --enable-directx-ugly-ugly-ugly-path when getting their gallium ready
    You're missing one ugly

    @deanjo: Wouldn't MS have already closed down Wine if they wanted to?

  9. #9
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,584

    Default

    Quote Originally Posted by Extreme Coder View Post
    You're missing one ugly

    @deanjo: Wouldn't MS have already closed down Wine if they wanted to?

    Right now wine is a hit or miss and doesn't really make any kind of a dent on windows sales. You start adding functionality to start making a dent in the marketshare and you can rest assured that wine and such projects will be the first thing MS will come after. There is a reason why in the Novell/MS deal OpenOffice, Wine, and OpenXchange were named and excluded from it's agreement. It would be far wiser for opensource community to put out a product that can compete and exceed on ever facet of DX instead of having a fragmented piece here and there hoping they will all combine to make a complete solution.

  10. #10
    Join Date
    Aug 2008
    Posts
    11

    Post

    Quote Originally Posted by deanjo View Post
    Right now wine is a hit or miss and doesn't really make any kind of a dent on windows sales. You start adding functionality to start making a dent in the marketshare and you can rest assured that wine and such projects will be the first thing MS will come after. There is a reason why in the Novell/MS deal OpenOffice, Wine, and OpenXchange were named and excluded from it's agreement. It would be far wiser for opensource community to put out a product that can compete and exceed on ever facet of DX instead of having a fragmented piece here and there hoping they will all combine to make a complete solution.
    The next challenge of course is to get the major software manufacturers to use said product - we're facing inertia worthy of an aircraft carrier in dry dock.

    In the meanwhile, the demand for high-powered games is still there, and will grow. As a minority market, we have to accept the fact that the major manufacturers in this market (games) will not go out of their way to meet our needs (not yet anyway), and yet will be happy enough to take our money.

    We therefore have to be extra creative, and provide solutions for ourselves that meet our needs. WINE is an example of this - providing compatibility from the bottom upwards (Win32 environment for unchanged Windows binaries) as opposed to providing compatibility from the top downwards (targeting games for SDL+OpenGL on GNU/Linux, for example).

    On that note, and inspired from your comment regarding Windows market share, I'd like to run an idea past you guys.

    Earlier I mentioned about Xen-aware video drivers, and installing Windows under Xen, but what about a chimaera? What about making WINE Xen-aware?

    I would not know if this was possible, but the hoped-for end result would be that a user could install the game and the Windows-native video drivers under WINE. I suppose WINE would run as a kind of "single process domU" and would take advantage of VT-d (directed I/O).

    Assuming of course that the dom0 drivers were Xen-aware also, the Windows drivers could send instructions that would execute directly on the hardware.

    Initially it'd probably need a separate GPU (and corresponding X session), and would probably work best on an *X2-type card - one monitor output. Eventually, it would evolve so that you'd only need one X session, and perhaps even run a DirectX application in a window - here's hoping.

    Anyway, the upshot is that you get to run DirectX games at full speed, or as near to it as your going to get AND you don't have to buy a copy of Windows. How good is that?
    Last edited by parityboy; 08-27-2008 at 01:31 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •