Why Wine Developers Don't See Gallium3D D3D9 As An Option

[artivision]

I have bunch of old DX games, but only one i want to play that is Dungeon Siege 2 and it does not work with nine, while it works in wine

It is nice to have nine, but should be more useful if that was available 7 years ago. We are really in DX11 age and DX12 coming, with near thousand native Linux OpenGL games avalible on Steam. In two years it will be probably doubled, and in five years... well who will really care about partially working D3D9 implementation nine has now Also in five years if not much more earlier, most of the hardware will also break some D3D9 compatibility .

It is simple as that, start working on eleven/twelve intead of nine and wine devs will support it . Blah, even newer Windows broke an will broke it even more those D3D9 compatibility, why should linux users care about that .

Well i don't care about nine or direct3d games, give me more native and 64bit binaries and i am fine

Because you cannot consider your self a gamer if you haven't play till the end a 3D Final-Fantasy and you aren't one of the best in a MMO of any generation. OGL gaming? Hahahaha ok you are good.

[dungeon]

OGL gaming? Hahahaha ok you are good.

Gamers of native games for Linux and (Mac) OS_X uses OpenGL only, smiles or not - that is how it is

Because you cannot consider your self a gamer if you haven't play till the end a 3D Final-Fantasy and you aren't one of the best in a MMO of any generation.

Some says PC is not for gaming and that there are consoles for gaming

[pal666]

who cares about wine devs whine ?
gallium nine support is included in playonlinux and fedora wine

[Temar]

With Stefan D?singer being an employee of Codeweavers (a for-profit company), I see a clear conflict of interests there, especially considering that CSMT patches have been integrated into Codeweavers' wine version quite some time ago. His reasoning sounds especially odd, considering that there already are distributions that choose to ship the patched wine by default, e.g. Fedora. Time to fork wine and run a crowdfunding campaign?

Wine and Codeweavers is the perfect liaison between Open Source development and comercial success. Every Open Source project should follow this example. Where do you think Wine would be today without Codeweavers paying for fulltime developers? How many fulltime developers do you think this project would have?

Even if they would hold these patches back to give their product an advantage over vanilla wine, this would be ok in my eyes, because in the end it guarantees the continued development of wine.

[Delgarde]

The usual story, I see. Lots of people calling for a fork of Wine, but nobody actually volunteering to do the work... much easier to just make demands of other people...

[GreatEmerald]

Hmm, those reasons are reasonable enough. Wine devs don't want to maintain it, fair enough. The question, however, is why it's not in wine staging.

[Sin2x]

The usual story, I see. Lots of people calling for a fork of Wine, but nobody actually volunteering to do the work... much easier to just make demands of other people...

Because not everybody who uses Linux and wine is a programmer. Captain Obvious to the rescue.

[Kivada]

The usual story, I see. Lots of people calling for a fork of Wine, but nobody actually volunteering to do the work... much easier to just make demands of other people...

And it's got absolutly nothing to do with the fact that Wine and Crossover is so hard coded for the Nvidia blob that the devs shit greener then if their diet was 100% kale.

[geearf]

I really don't get the arguments flying around.

#1 Why does it matter that 25,000 lines of d3d code are added to wine? Someone explain to me why this is a big deal?
#2 Last I checked doesn't Gallium Nine also work on Intel and Nvidia hardware? Don't you just have ot use ILO for Intel? Nouveau works as well but sucks compared to Nvidia drivers. But that is mostly Nvidia's fault. Fix it Nvidia!
#3 Gallium Nine is is faster than the existing code. Period. End of story. Do not past go. Do not collect $200. How much faster? For me it's nearly 100% in most games.
#4 Nvidia has fast opengl drivers. THANKS! Does Nvidia has fast open source drivers? NO! No no no so much no!
#5 Mesa needs to improve its OpenGL. Really? Ya think?

Also while the benefit mostly effects AMD users who use open source drivers, it won't be long before everyone uses Gallium over Catalsyt. It's so fast now there's really no reason to use Catalyst. Except for 290 or 285 users, poor bastards. But that's like what, 1/4 or 1/3 of Linux users right there? If Intel ILO perform nearly as well as Intel's non Gallium drivers then why wouldn't Intel users also not use it? It's just Nvidia users who are screwed, and that's still Nvidia's fault. But hey they get to use super fast D3D->OpenGL.

#1 means it adds almost a third more code to maintain.
The more lines of code you have, the more it costs you to maintain your application.
I suppose adding so many lines of code for a corner case seems quite expensive to them.

Remember code is not something you write once and never look at it again.
You may need to fix bugs in the current code, or to change it based on some other changes somewhere else...

It also adds a lot of potential bugs in the wine code base, so even if the wine team would eventually send these bugs to the nine team, they would have to look at them first to know that are nine based, so it's also potentially more wasted time for them.

I wonder what the wine team would say if the nine had a drastically smaller code base.

I agree with you on the other points though, they're moot...

Finally, I agree with Delgarde. What's the point of all these people screaming for a fork and not starting one? If they don't have the skills they could always finance it if they think they can do better than codeweavers. Actually I think it could get worse... some of the wine guys are still doing it on their free time, insult them more, they might give up, and with no (better) fork in place, it's only a lose-lose situation. If all you fork guys only care for is nine, Ixit's already maintaining that fork (even though they'd like it to be mainlined), so what other fork do you need?

[emblemparade]

Sigh. To the people posting here negatively who are not devs, and especially not devs of a very large free software project:

Code contributions are not free, even when they seem to solve a problem. They come with a tremendous cost of responsibility: once you accept that code, as project manager far into the future you will have to manage the code, deal with bugs, test (on all the various platforms), etc. All contributors will have to share this responsibility, and they are likely already stretched very thin. You can't just say "I will throw this feature away in the future if it becomes unmanageable," because by then you have users and other projects that depend on it, and your project would rightfully get a reputation of being unreliable.

For you it would mean:

1) more time between WINE releases,
2) fewer contributors to the project -- it's much more intimidating to try to contribute to a 100,000 line project,
3) contributors working on this issue rather than on some core very critical issues.

The Unix and free software principles of smaller, leaner projects which focus on a very small set on tasks has proven itself right again and again. As projects get bloated, they tend to suffer from all of the above 3 costs, with a very noticable drop in quality.

D?singer is not saying this code is bad or unuseful, he's just saying that he doesn't think it would benefit WINE if it is part of the WINE project. He hasn't suggested an alternative solution as such because that's not his role here: he's here to make sure WINE fulfils its goals.

In this case, it would seem that accepting this code would add 30% complexity to the WINE project (number of lines of code are a poor measurement of complexity, but still). That's huge.