Direct3D 9 Support Released For Linux Via Gallium3D, Running Games

[Serafean]

Yes but I don't see why you'd want to. You could just -lwine and compile. The idea of using D3D9 on linux is rather abhorrent and unless someone writes pipe_gl.so I refuse to even entertain the notion. There used to be an Xlib backend but I let it rot and eventually nuked it when it wasn't useful for testing anymore.

Why is it abhorrent? Enabling netively another graphics API is a pretty damn good thing for linux gaming... I'm not saying it should be used for future development, but it enhances the value of the entire graphics stack and proves the decisions that hurt developers and users were worth it.

Minor point but you're thinking of DRM. DRI is an X11 extension that allows X applications to authenticate and use DRM drivers with X11 surfaces. We've since gone to DRI2 and soon DRI3.

Right, sorry. I get those mixed up quite often.

[zhasha]

I is possible to use your dx9adapter native on Linux. E.g. some game company to port their existing DX windows title to Linux, using SDL as DX replacement but keeping d3d renderer?

Yes but I don't see why you'd want to. You could just -lwine and compile. The idea of using D3D9 on linux is rather abhorrent and unless someone writes pipe_gl.so I refuse to even entertain the notion. There used to be an Xlib backend but I let it rot and eventually nuked it when it wasn't useful for testing anymore.

[Drago]

Given that SC2 is pretty much the only game I'm playing lately, it's pretty celebration-worthy for me, hence why it exists.

It also proves that it's possible to actually write a D3D state tracker that works and is usable, and all that within a couple of months, given favourable circumstances.

In principle D3D11 is even easier to support because there is no fixed function pipeline and it's even closer to gallium. The problem is, no gallium driver supports the required feature set at this point, TGSI can't even handle SM4 yet, and there are no tests or an existing open implementation (wined3d) available to clarify how things are supposed to behave, so the time for it hasn't come.

Motivation is key, but as there are no motivating D3D11-only games/applications yet, neither the wine devs nor the mesa devs seem to care much. But the existence of a working D3D st should provide some hope should anyone ever think of reviving/rewriting d3d1x.

I is possible to use your dx9adapter native on Linux. E.g. some game company to port their existing DX windows title to Linux, using SDL as DX replacement but keeping d3d renderer?
I guess pipe drivers will not gain dx11 features, until Mesa's OGL reaches 4.x, so DX11 tracker would allow for drivers evolve up to SM 4. But yes, testing will be a problem.
Thanks for your work, Christoph.

[calim]

Not much to celebrate, DX9 is dead. This will probably be the last year of any real DX9 support, but most major titles don't have it.
On the upside, many titles are getting linux ports.

Given that SC2 is pretty much the only game I'm playing lately, it's pretty celebration-worthy for me, hence why it exists.

It also proves that it's possible to actually write a D3D state tracker that works and is usable, and all that within a couple of months, given favourable circumstances.

In principle D3D11 is even easier to support because there is no fixed function pipeline and it's even closer to gallium. The problem is, no gallium driver supports the required feature set at this point, TGSI can't even handle SM4 yet, and there are no tests or an existing open implementation (wined3d) available to clarify how things are supposed to behave, so the time for it hasn't come.

Motivation is key, but as there are no motivating D3D11-only games/applications yet, neither the wine devs nor the mesa devs seem to care much. But the existence of a working D3D st should provide some hope should anyone ever think of reviving/rewriting d3d1x.

[mrugiero]

Right now it's so much easier and less error prone to just boot windows when you wanna play.... For many years nothing will change in Linux when it comes to games. Things are starting to move but it will take many years before we will be able to play windows games on Linux at similar performance.

Last time I used AMD's blob, I had around the same performance (around because I wasn't benchmarking, was not and am not really interested on benchmarking games) when playing Doom 3 on Windows XP and Linux on a Mobility Radeon HD 3200, with the only noticeable difference it overheated on Windows but not on Linux (I had no faith on Linux for gaming, but I got tired of overheating and gave it a shot). It's the only game I played back then, though, so it's not really representative.

[jrch2k8]

WinXP is EOL next year and most game makers do *not* care about the majority. If they did, their recommended specs wouldn't contain $300+ graphics cards.
Many games released this year are already DX11-only. https://en.wikipedia.org/wiki/List_o...ctX_11_support you can sort it by games that are DX11 only.

I'd honestly be curious how much of a % China makes up of game buyers anyways.
2%? 3%?
I'd imagine North America + European markets make up the massive majority.

well the point is there are a freaking bunch of games already for DX9 that this will help you to play on linux with better performance those DX9 games later maybe this project can be expanded other revisions, you have to start somewhere

[peppercats]

Not at all. WinXP is still the dominant OS in many parts of the world. Gl is still a horrible API with buggy-as-hell drivers commonplace. Companies that are smart enough to target more than just the US still want to target DX9 for at least a couple years until/unless China and the like starts pirating Windows 7 instead of XP.

WinXP is EOL next year and most game makers do *not* care about the majority. If they did, their recommended specs wouldn't contain $300+ graphics cards.
Many games released this year are already DX11-only. https://en.wikipedia.org/wiki/List_o...ctX_11_support you can sort it by games that are DX11 only.

I'd honestly be curious how much of a % China makes up of game buyers anyways.
2%? 3%?
I'd imagine North America + European markets make up the massive majority.

[przemoli]

DX9 3D is all about games. And Wine is about LEGACY/CURRENT apps.

Add those two, and you will get plenty of use cases for such integration, even if every and each FUTURE app would use DX10/11.

[elanthis]

Not much to celebrate, DX9 is dead. This will probably be the last year of any real DX9 support, but most major titles don't have it.
On the upside, many titles are getting linux ports.

Not at all. WinXP is still the dominant OS in many parts of the world. Gl is still a horrible API with buggy-as-hell drivers commonplace. Companies that are smart enough to target more than just the US still want to target DX9 for at least a couple years until/unless China and the like starts pirating Windows 7 instead of XP.

[elanthis]

One of the problems for the D3D10/11 state tracker is that the Shader Model 4.0+ binary formats are undocumented. I've been on a couple of the DX team's asses about this; it's stupid. Their argument was "we don't want to have to maintain compatibility" which of course is silly since they have to anyway. I've also been told they've had trouble getting a big enough budget given how key DX is to the entirety of Windows these days so getting a technical writer to maintain quality docs is a problem, which is silly but more management's fault than their own. I think maybe I got the point across but if anything comes of it it probably won't be until 8.1 ships or likely even later. I'm told that at least the issue whre the compiler was considered a "developer tool" is being fixed in the next SDK and Windows Blue update, which helps Linux not at all, but at least means Windows Store apps can now compile shaders on the fly (not as useful for games, but handy for game editors or graphics toolsets/sandboxes).

Note that projects like MojoShader only work on SM3 or under files, for which the format is documented.

More (courteous!) pressure on Microsoft Connect might help resolve the documentation issue faster.