Direct3D on GNU/Linux

[Extreme Coder]

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?

If only things would work the way you're saying

[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?

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

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

[curaga]

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

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

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

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

[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