Direct3D In Gallium3D Suffers Bit-Rot, Now Disabled

[Sidicas]

The point is that we shouldn't allow random users to try to compile known broken code. It doesn't do anything good. They may file bug reports about build breakages, but when it turns out that even with a successful build the code doesn't do anything useful then there's no point in fielding the bugs at all.

Are saying the DX10/11 demos they had running in d3dxl1 a year or two ago don't work anymore because d3d1x hasn't been updated along with the rest of mesa's internals?
It looked to me that, by default, the d3d1x wasn't compiled into mesa. And now, even if you specifically use the d3d1x build flag to compile it in, it won't?
It just seems a little early to be killing this off when Wine still hasn't got around to doing decent DX10/DX11 support and most open source graphics drivers are still struggling with OpenGL3.X..

Of course, it will still be a while before d3dxl1 is used as it is based on DX10/DX11 which depends on decent OpenGL3.X support.
Even if Wine doesn't want to touch d3d1x with a 10 foot pole, I'd think it would still be useful for demos/testing.... Or at the very least, couldn't it be used to make porting Direct3D Games to Linux *without* rewriting the whole engine to use OpenGL and *without* having to use Wine? I'd think that would be important for Linux gaming as it could significantly reduce porting costs.

The code might be a little stale, but it's still code for hardware that, for the most part, Gallium hasn't even gotten around to supporting well yet. It just seems to me that completely disabling it like that is pretty much a guarantee that it will very quickly fall into a state that it will be a lot of work just trying to get it to compile at all.

I don't mean to be a "backseat driver" but when I see stuff that could hurt the future of gaming on Linux, I always have to make a comment, that's all.

[NeoBrain]

It just seems a little early to be killing this off when Wine still hasn't got around to doing decent DX10/DX11 support and most open source graphics drivers are still struggling with OpenGL3.X..

While you didn't say so, I think it's worth pointing out that Wine devs stated multiple times that they have no interest in D3D support via G3D for multiple reasons. I guess they'd accept a well done, well separated code path that makes use of G3D, but it's not going to work that way with Wine's development model. Just look at how long it took for a working DIB engine to enter the Wine tree. Adding a G3D code path is a similar big and invasive task.

Of course, it will still be a while before d3dxl1 is used as it is based on DX10/DX11 which depends on decent OpenGL3.X support.
Even if Wine doesn't want to touch d3d1x with a 10 foot pole, I'd think it would still be useful for demos/testing....

I can't imagine a single scenario where one would want to test anything with a broken D3D implementation which is more cumbersome to use than just setting up a Windows VM and using software rasterization (or a full windows dual-boot setup if that's too slow).

Or at the very least, couldn't it be used to make porting Direct3D Games to Linux *without* rewriting the whole engine to use OpenGL and *without* having to use Wine? I'd think that would be important for Linux gaming as it could significantly reduce porting costs.

It could be used for that, but that would require someone to put some *very* substantial work into a) getting the D3D implementation in G3D to work close to perfectly (since you want a suitable replacement for Wine) b) getting it up to at least Wine's level of performance (no use in native D3D if it runs slower than Wine) c) getting the most popular drivers to actually work with the D3D implementation in G3D (that's not necessarily a trivial task).
Also, note that porting an application from Direct3D to OpenGL isn't necessarily hardest part of porting a whole application from Windows to Linux. So even if you had something like native D3D support in Linux, there'd be tons of other items to work on for the game developer.
Meanwhile, all the effort that would've gone into desperately making G3D support D3D properly could've just went into improving Wine.

The code might be a little stale, but it's still code for hardware that, for the most part, Gallium hasn't even gotten around to supporting well yet. It just seems to me that completely disabling it like that is pretty much a guarantee that it will very quickly fall into a state that it will be a lot of work just trying to get it to compile at all.

I have no idea how often interfaces change in G3D, but you either end up with what you just explained or with the maintainers of G3D code wasting lots of time on code they don't really care about. It's enough work to maintain a single piece of software; if you have to bother about another one because the original maintainer randomly disappeared and doesn't show any interest in helping out anymore, there's really no excuse to leave that guy's piece of code any longer in the tree.

I don't mean to be a "backseat driver" but when I see stuff that could hurt the future of gaming on Linux, I always have to make a comment, that's all.

Sorry, but even if someone removed the D3D code in G3D altogether, that wouldn't hurt the future of gaming on Linux at all.

[DrYak]

Even if Wine doesn't want to touch d3d1x with a 10 foot pole, I'd think it would still be useful for demos/testing.... Or at the very least, couldn't it be used to make porting Direct3D Games to Linux *without* rewriting the whole engine to use OpenGL and *without* having to use Wine? I'd think that would be important for Linux gaming as it could significantly reduce porting costs.

The problem is that Gallium3D isn't used everywhere. On the desktop, Intel (which *DO* have a significant market share, though) is the only using Gallium3D for their official driver, and AMD are also giving support to an opensource driver using it beside their official one. AMD and Nvidia official drivers aren't based on Gallium, but share code with their respective Windows equivalent. Currently for Nvidia (which is mega-popular among gamers) the binary driver is the preferred one as it is the only supported by Nvidia and nouveau is entirely done by reverse engineering (and thus is having a hard time to be on par, although it's quite amazing what they still managed to achieve anyway).

So, DirectX 3D on Gallium3D only solves the "Wine support & Game porting" problems for a fraction of the players. (The one with Intel hardware, and the few AMD/Nvidia interested in the opensource drivers). For the rest (the bulk of Nvidia and AMD running the official binary drivers) you need support from the company themselves - that might be made easy if they share code with the windows version, but on the other hand that still require extra work from them (and given how slow is Nvidia to pick up latest linux trends... Just look how much time it's taking them to pick-up RandR, to decide they might start playing with DMA-BUF to offer actual real optimus support instead of bumblebee workaround... Still don't even care to consider Wayland... Hence Linus' big "Fuck You". At least apparently the things are starting to move on the Tegra front and looks like Nvidia might go the AMD way).

For directx on Linux to make any sense, one would need:
- developpers jumping on to maintain d3d1x
- AMD and Nvidia porting their windows DirectX code to Linux

Better keep the current route:
- Developers are adding OpenGL support to their 3d engines anyway, in order to support Mac OS X and support OpenGL ES powered handheld devices (smartphone, tablets, etc.). As DirectX is only available on Windows and X-Box, and as OpenGL is available on pretty much everything *including* Windows and *including* all the juicy new emerging markets (mobile apps), it really does make sens.
- Bring OpenGL support on Linux on par with everything else. AMD and Nvidia are already doing their work on their binary drivers (with support of the recent OpenGL 4.x APIs). Gallium3D is lagging behind, but the pace at which it progress is accelerating, thank various developpers like Intel (they want to get an as good as possible opengl support) and Steam (they helped bring some of the OpenGL 4.x debugging APIs into Gallium3D because it helps them).

The only actual use case for a DirectX state tracker would be VMware :
They bought Tungsten graphics and have them work on their virtualized acceleration. If they move their guest drivers on Windows to using Galllium3D, a Direct3d state tracker will make sense.

[GreatEmerald]

So, you quote me but don't seem to realize that I'm the guy who disabled d3d1x. (I guess it would have been easier to know if my forum title said something about Intel.)

Michael?

[evil_core]

The problem is that Gallium3D isn't used everywhere. On the desktop, Intel (which *DO* have a significant market share, though) is the only using Gallium3D for their official driver, and AMD are also giving support to an opensource driver using it beside their official one.

RTFM!

Intel doesn't use Gallium(there were some porting to Gallium done over two years ago) for their drivers, only classic Mesa. Citing from Wikipedia:

In November 2011, Intel 965g and Cell Gallium drivers were removed from the master branch of Mesa as unmaintained and broken.

And its not because Gallium isn't technically better, but because Intel Company put so much time and money into developing pre-gallium driver, that they aren't considering it would be worth of time/money, but especially regressions(they always happen), to switch to Gallium.

[artivision]

The problem is that Gallium3D isn't used everywhere. On the desktop, Intel (which *DO* have a significant market share, though) is the only using Gallium3D for their official driver, and AMD are also giving support to an opensource driver using it beside their official one. AMD and Nvidia official drivers aren't based on Gallium, but share code with their respective Windows equivalent. Currently for Nvidia (which is mega-popular among gamers) the binary driver is the preferred one as it is the only supported by Nvidia and nouveau is entirely done by reverse engineering (and thus is having a hard time to be on par, although it's quite amazing what they still managed to achieve anyway).

So, DirectX 3D on Gallium3D only solves the "Wine support & Game porting" problems for a fraction of the players. (The one with Intel hardware, and the few AMD/Nvidia interested in the opensource drivers). For the rest (the bulk of Nvidia and AMD running the official binary drivers) you need support from the company themselves - that might be made easy if they share code with the windows version, but on the other hand that still require extra work from them (and given how slow is Nvidia to pick up latest linux trends... Just look how much time it's taking them to pick-up RandR, to decide they might start playing with DMA-BUF to offer actual real optimus support instead of bumblebee workaround... Still don't even care to consider Wayland... Hence Linus' big "Fuck You". At least apparently the things are starting to move on the Tegra front and looks like Nvidia might go the AMD way).

For directx on Linux to make any sense, one would need:
- developpers jumping on to maintain d3d1x
- AMD and Nvidia porting their windows DirectX code to Linux

Better keep the current route:
- Developers are adding OpenGL support to their 3d engines anyway, in order to support Mac OS X and support OpenGL ES powered handheld devices (smartphone, tablets, etc.). As DirectX is only available on Windows and X-Box, and as OpenGL is available on pretty much everything *including* Windows and *including* all the juicy new emerging markets (mobile apps), it really does make sens.
- Bring OpenGL support on Linux on par with everything else. AMD and Nvidia are already doing their work on their binary drivers (with support of the recent OpenGL 4.x APIs). Gallium3D is lagging behind, but the pace at which it progress is accelerating, thank various developpers like Intel (they want to get an as good as possible opengl support) and Steam (they helped bring some of the OpenGL 4.x debugging APIs into Gallium3D because it helps them).

The only actual use case for a DirectX state tracker would be VMware :
They bought Tungsten graphics and have them work on their virtualized acceleration. If they move their guest drivers on Windows to using Galllium3D, a Direct3d state tracker will make sense.

To bad that WINE and YOU are wrong!!! The D3D(or HLSL) state-tracker, doesn't need heavy translations, and doesn't need D3D dlls. Its easier to maintain than the current alpha-state WINE D3D-compiler, and does not need support from Nvidia nor AMD. It will only need a back-end in order to work with closed drivers. You can use LLVM, but some one need to continue development. As for patents, come one now. Microsoft said that Linux-Kernel and WINE violate their patents.

[calim]

It simply isn't quite finished and still has a number of bugs.
It was *always* usable with WINE, and you could run Unigine Heaven (the Windows version, via WINE) with it (with a hack to bypass TGSI and hand SM4 to the driver, which is only handled by the Fermi driver).
But not any actual game. Unimplemented features, bugs -> crash.
And no one cares about it anymore. It could have been a great success for gallium if more people (developers) ever had ...

[RealNC]

D3D in Gallium was a good idea, IMO. Personally, I find it to be a nicer API to work with than OpenGL (where for me nicer==easier.) But if nobody's using it (or even maintaining it), then there's no point.

Though it might be a bit of a chicken & egg problem - nobody is maintaining it because no one's using it, and no one's using it because it's not maintained and therefore its future looks grim.

(I've got no idea or opinion about the legal stuff.)

[mrugiero]

RTFM!

Intel doesn't use Gallium(there were some porting to Gallium done over two years ago) for their drivers, only classic Mesa.

The point still stands. The point was "D3D via Gallium3D would be useful only for a small fraction of users", and you just prove it's a smaller fraction than he thought it was.

To bad that WINE and YOU are wrong!!! The D3D(or HLSL) state-tracker, doesn't need heavy translations, and doesn't need D3D dlls. Its easier to maintain than the current alpha-state WINE D3D-compiler, and does not need support from Nvidia nor AMD. It will only need a back-end in order to work with closed drivers. You can use LLVM, but some one need to continue development. As for patents, come one now. Microsoft said that Linux-Kernel and WINE violate their patents.

I think he means the support from closed source drivers is needed to get a dev to actually want to use D3D on Linux. And I think he is right, most gamers use closed source drivers (and the apps are usually made with a kind of user in mind, which, for D3D apps, is likely a gamer), and what you suggest is to, essentially, code in D3D and then translate to OpenGL for the blobs. That would mean a useless performance loss for blobs, which are benefitted by direct OpenGL use. The other option, coding for both OpenGL and D3D, which would make everyone happy, except for the dev, who would have to write and maintain duplicated code. But then, you could just do it OpenGL, which support is WAY more universal, specially on FLOSS OS's, where blobs supports it and FLOSS drivers supports it (at least, at a better extent than D3D), and, most important, the (almost) OS independent drivers (classic mesa) supports only that.
Personally, I use the open source drivers, and I'd love to see more features added, and better performance, and what not. But I don't really see the point in keeping coding apps for both API's, coding once is easier than coding twice, and dropping OpenGL means dropping several platforms (I think of the *BSD and Haiku guys, for example) and drivers, while dropping D3D means just dropping D3D (well, I don't really mean dropping, because I'm talking about software that it's not there yet ). So, the main use would be for already existing software, being via WINE or via porting it. And again, most of it already uses OpenGL, which means you could just port it to use OpenGL on the new OS or just use it with OpenGL on WINE.

[mattst88]

Are saying the DX10/11 demos they had running in d3dxl1 a year or two ago don't work anymore because d3d1x hasn't been updated along with the rest of mesa's internals?
It looked to me that, by default, the d3d1x wasn't compiled into mesa. And now, even if you specifically use the d3d1x build flag to compile it in, it won't?
It just seems a little early to be killing this off when Wine still hasn't got around to doing decent DX10/DX11 support and most open source graphics drivers are still struggling with OpenGL3.X..

The D3D demos aren't useful for users.

The code might be a little stale, but it's still code for hardware that, for the most part, Gallium hasn't even gotten around to supporting well yet. It just seems to me that completely disabling it like that is pretty much a guarantee that it will very quickly fall into a state that it will be a lot of work just trying to get it to compile at all.

I don't mean to be a "backseat driver" but when I see stuff that could hurt the future of gaming on Linux, I always have to make a comment, that's all.

It's already in a state where it's a lot of work to get it to compile...