Direct3D 10/11 Is Now Natively Implemented On Linux!

[eternaleye]

What does "jive with" mean? The dictionary doesn't help me much, it seems to mean the opposite I think you're saying. For the record, you used the same expression in another thread talking about the same issue and I didn't reply for I wasn't sure what your position was.

I think he meant "jibe with". It means that a set of pieces of information are collectively consistent.

[Saist]

I didn't see it mentioned, but there is a triple AAA title already on the market that is leveraging OpenGL 3.x... right now.

City of Heroes.

Also, as a note, OpenGL 3.x support already works under Cedega with ATi drivers: http://www.gamenikkiinexile.com/g3/r...play.php?id=28

Anyways, I kind of wanted to go back to the original git commit. I guess I have a hard time accepting the idea that the DX10/11 API is a "cleaner" API than OpenGL 4.x

Against the OpenGL 2.x / 3.x branches, sure, Microsoft was able to create a cleaner API since they effectively dropped the DX9 API. However, in the run-up to OpenGL 3.x, even Khronos admitted the specification was a little messy: Longs Peak should ring a bell to anybody who actually keeps track of OpenGL development.

That being said, according to the actual coders, the guys writing the software, such as Carmack at IDSoftware and the devs at Paragon Studio's, there's no performance difference between DX or OpenGL API usage.

Given that the guys writing the graphics code that leverages the processors to begin with say there's no difference in how the code should respond, I'm honestly finding it hard to believe that a driver developer says that the DX10/11 API is automagically going to be faster than the OpenGL API.

I'm sorry, but this just reeks of something Miguel de Icaza would pull. Let's face it, Mono is never going to be .net. It's never going to be as good as .net, it's always going to be playing catch up to .net, and Novell wasted a metric ton of money supporting a bad idea from the start.

A D3D driver on Linux? Is going to be the exact same situation. It's going to distract developers and cause resources to be focused where resources have no reason to be focused. I'm sorry if people out there disagree with this, or somehow think a D3D driver is magically going to change commercial game developers points of view on Linux, but I'm just going to point to Mono as proof of just how catastrophically bad an idea a D3D state Tracker for Linux is. Mono has done nothing to convince .net developers to target Linux. Period. Stop. End of Story.

[Fixxer_Linux]

Sorry for my newbie question, but does this D3D means that binaries Windows games can now run on Linux ?
Or does it simply means that it would be more easier for games developpers to port to linux, using the same code, but having to compile a specific binary for windows and to compile another specific binary for linux ?

I guess the second option is the one : each one has its specific build, hasn't it ?

[Kazade]

Sorry for my newbie question, but does this D3D means that binaries Windows games can now run on Linux ?
Or does it simply means that it would be more easier for games developpers to port to linux, using the same code, but having to compile a specific binary for windows and to compile another specific binary for linux ?

I guess the second option is the one : each one has its specific build, hasn't it ?

This doesn't really mean anything.

Basically, if your aim is to run Windows games on Linux, you still have to go through Wine as D3D only forms a small part of a game.

This new state tracker is also pretty much useless to Wine, at least for the next few years, as Wine supports other operating systems and so is written for portability (e.g. to OSX). OSX isn't going to ship with Gallium drivers in the foreseeable future. Also this is currently only for Mesa drivers, Wine must support all capable drivers (e.g. fglrx, nvidia). Also, this doesn't fit well with the way Wine is structured, the Wine D3D code has no direct access to X, all X access is contained within a single Wine module called winex11, so the WineD3D stuff can't just call to this state tracker.

Finally, this doesn't really help porting games to Linux either, because again D3D is only a small part of the game, and porting that part to GL is normally relatively straightforward. Not having a native D3D isn't what's stopping game ports, that's a business decision.

[pingufunkybeat]

Sorry for my newbie question, but does this D3D means that binaries Windows games can now run on Linux ?

No.

Or does it simply means that it would be more easier for games developpers to port to linux, using the same code, but having to compile a specific binary for windows and to compile another specific binary for linux ?

No, it doesn't mean that either.

Unfortunately, it doesn't mean much. It just means that ONCE we get GPU drivers capable of accelerating OpenGL3/D3D10 stuff, people will be able to write Linux programs using the D3D API instead of the OpenGL API.

But only for the systems running the Gallium3d infrastructure and GPUs with good Gallium3d drivers.

[RealNC]

Unfortunately, it doesn't mean much. It just means that ONCE we get GPU drivers capable of accelerating OpenGL3/D3D10 stuff, people will be able to write Linux programs using the D3D API instead of the OpenGL API.

How does that differ from being able to port Windows games to Linux easier?

And also, if Wine would provide a means to use this, wouldn't there be less bugs and more complete support in D3D10/11 games?

[pingufunkybeat]

How does that differ from being able to port Windows games to Linux easier?

Like people have posted already, the D3D layer is not the major stumbling block in porting games, but a rather minor one.

You also have input, sound, timing, filesystem-dependent stuff, dependence on Windows DLLs for core functionality, and all sorts of other things.

So I still think that it does not mean much.

And also, if Wine would provide a means to use this, wouldn't there be less bugs and more complete support in D3D10/11 games?

I don't know. I have my doubts, though.

[phoreddit]

I was a bit disappointed when I began reading this article and found uncovered spot on bottom middle. http://i.imgur.com/gPB2m.jpg

[Remco]

How does that differ from being able to port Windows games to Linux easier?

And also, if Wine would provide a means to use this, wouldn't there be less bugs and more complete support in D3D10/11 games?

I don't think so:

Wine's own D3D10/11 implementation is further along than this new project.

The state tracker doesn't implement what Wine needs. Wine needs more than just basic D3D10/11 drawing commands. (That's the easy part)

The state tracker has legal issues (using MS source code) which prevent Wine developers from working with it. The fact that it has been merged into Mesa also means that at least one Wine+Mesa developer won't be a Mesa developer anymore.

[nanonyme]

The state tracker has legal issues (using MS source code) which prevent Wine developers from working with it. The fact that it has been merged into Mesa also means that at least one Wine+Mesa developer won't be a Mesa developer anymore.

Citation (or link) needed.