Gallium3D's Direct3D 9 Support Is Coming Along Well

[duby229]

Wine users aren't all customers. Some of them actual pay a company for software based on Wine and since many of the Wine developers work for said company, it is natural for them to focus on what the customers pay for. The "fix" would be for more wine users to pay for it or develop patches themselves. Opinions, especially looking for "downfall" are going nowhere.

And that is exactly the problem. Don't care about users opinions. Don't care about fixing problems.

If they could provide something that people would want to pay for they'd have better luck.

EDIT: MS epitomizes that crap. That's why I can't wait for the downfall to happen. The ironic thing is, it'll be good for wine when it does happen, but they won't be able to see it. They don't care about opinions or problems. They're going to be completely blinded when the time comes.

[zanny]

I keep hoping someone shows up with the insanity to fork Wine and include all the Linux beneficial patches that upstream just refuses to adopt because its not platform independent or doesn't work on all hardware or some nonsense.

That includes the multimedia patches, the d3d command stream patches, and the Gallium Nine patches. In the last few years so much tech has come up to benefit Wine that the developers won't adopt, but the problem is we need someone crazy, smart, and determined enough to properly maintain a fork of one of the largest free software projects in existence.

I'm just getting tired of always having to either use AUR builds of wine or even worse having to write my own configs and build scripts and patch sets for it.

[degasus]

@Michael: Did you see both gallium3d nine talks at the fosdem? In my opinion Stefan did show quite well why they do not want to include nine within wine. It would be nice to have a neutral article comparing both points of view. And it is not just about reducing code size...

[RahulSundaram]

And that is exactly the problem. Don't care about users opinions. Don't care about fixing problems.

Every release fixes plenty of bugs. So I don't believe that they don't care about fixing problems. They might not care about your pet peeves but you aren't necessarily representative of majority of users.

[SpyroRyder]

It really isn't that they dont care about users

Their own implementation works decent over everything, GalliumD3D9 only works on Nouveau and Radeon. That cuts out all of us that run things of Intel GPU's or catalyst or want the full power of our Nvidia cards. They also know which parts work and on what systems other parts may not. Because this is a key piece of what Wine is used for, to default and rely on a set of software that is both out of their control programming wise and also out of their control as to what version an individual user might have is a little worrying. If the version the user needs is in Mesa 11.2 (to pick a future release) but the user only has mesa 11.0 then all they are going to see is wine not working and thus blame wine. The more power users will try and debug that stuff but speaking from experience it can take a while sometimes to figure out if a problem is part of wine or an external package.

[mannerov]

@Michael: Did you see both gallium3d nine talks at the fosdem? In my opinion Stefan did show quite well why they do not want to include nine within wine. It would be nice to have a neutral article comparing both points of view. And it is not just about reducing code size...

Two main arguments to me where:
. with Nv driver we get very good performance, so instead of Gallium Nine, there should be fast performing mesa
. In a highly cpu limited scenario, Win still beats Gallium Nine by a lot.

None of the arguments surprise me, and the latter is a bit unfair, given cpu overhead hasn't been a optimisation focus for Gallium Nine, and it doesn't have CSMT equivalent (whereas Win does).

Do I forget anything ?

[geearf]

Two main arguments to me where:
. with Nv driver we get very good performance, so instead of Gallium Nine, there should be fast performing mesa
. In a highly cpu limited scenario, Win still beats Gallium Nine by a lot.

None of the arguments surprise me, and the latter is a bit unfair, given cpu overhead hasn't been a optimisation focus for Gallium Nine, and it doesn't have CSMT equivalent (whereas Win does).

Do I forget anything ?

Does the 2nd point only apply to Wine with CSMT or even standard wine?

[degasus]

Does the 2nd point only apply to Wine with CSMT or even standard wine?

Also to standart wine. Standart wine with nvidia is much faster than nine in CPU bound usages.

[mannerov]

Nine cannot do miracles. It can be improved to have even lower cpu usage, but the gallium driver is also a limiting factor on this point.

[mannerov]

Also cpu bound benchmarks tend to be tricky, since they do not reflect normal play where you are less affected by it.
As far as I remember, Stefan did test HL2 at lowest resolution (windowed) with mid settings, to show cpu overhead. You are not going to play at this resolution.

However in the other benchmarks showed in the other presentation, you see that some games shown were cpu limited on wine, but not on nine. (and the benchmarks were taken at res/settings you would play with).
As for the game being slow on both wine, nine and csmt (nine being 2 fps less), it may be a bug with some gpu queries, resulting in the game doing glfinish, and thus having lower speed for all three (the 2fps difference being unexplained)