Direct3D on GNU/Linux

[parityboy]

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...

[FunkyRider]

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

[Ex-Cyber]

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.

[parityboy]

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...

[Extreme Coder]

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.

[curaga]

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

[deanjo]

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.

[Extreme Coder]

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?

[deanjo]

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.

[parityboy]

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?