Wine 1.1.43 Brings Many Direct3D Fixes, Optimizations

[Hephasteus]

Yes thank you for your work Henri.

[curaga]

Thanks for your work. This is the first Wine release where Tiberian Sun actually works, and is playable.

[Henri]

Henri, your 'wined3d: Disable strict draw ordering by default' commit gave at least 50% performance improvement to me, sometimes more for some games that I play, with no graphics problems so far. The change looks rather simple, I wonder if there are similar "easy" hacks out there that could slightly decrease accuracy but improve performance a lot

There may be some, like e.g. disabling sRGB textures for source engine games, but in general those don't go into Wine. The "StrictDrawOrdering" patch was a bit of a special case because it restores the 1.1.37 behaviour except for users that explicitly ask for it. The original patch was a fix for applications that did draws to the same drawable from different threads, causing flickering, incorrect shadows, etc. Unfortunately that patch also caused a large performance regression on some configurations, including some (all?) systems with fglrx.

[Henri]

The Oh so predictable answer :P

No report that I could find. I've seen a couple of comments in the AppDB (and a thread here), that's it.
Why no bug report? Could be a handful of reasons, though I'm gonna sound like a broken record :P
- "Going back to 1.1.37 works for me, why bother?" That could change with Ubuntu 10.04
- "It's so freaking obvious, they HAVE to notice someday..." According to what you said earlier, that's wishful thinking
- "Meh, they won't look at it and brush it off as an fglrx issue, not worth my time."
- I could very well be looking for the wrong stuff in the bugzilla entries heh

Sure, there are plenty of reasons for why someone might not file a bug, "Somebody else will probably file a bug." is another one. In the end it's unlikely that a bug will get fixed quickly without a bug report though. It'll probably get fixed eventually, but that may take a while. Also, regressions have higher priority than regular bug reports.

[notaz]

Henri, your 'wined3d: Disable strict draw ordering by default' commit gave at least 50% performance improvement to me, sometimes more for some games that I play, with no graphics problems so far. The change looks rather simple, I wonder if there are similar "easy" hacks out there that could slightly decrease accuracy but improve performance a lot

[V!NCENT]

Sounds like pretty much every other OSS project to be honest. The question is what's considered to be a papercut and what's a serious problem? I'm guessing they are focusing mostly on D3D and DX9 related things. People get tired of papercuts because of the low level of excitement. So they'll switch to something more interesting just to keep from getting burned out.

Me personally - I'd much rather play an older game flawlessly (say Counter-Strike) than to have a new game that kinda works.

And for the love of God can they PLEASE fix this bug.

TDR 2000 came around in the Pentium 3 days.

But hey, if working your ass of to get Dx7 to work, but no one can play it then fine... I'm sure a 20yo game will be fixed with wine 2.0... not.

Like with any floss, distro's will work around it, right? -_-'

[PsynoKhi0]

Are there bugs filed for those?

The Oh so predictable answer :P

No report that I could find. I've seen a couple of comments in the AppDB (and a thread here), that's it.
Why no bug report? Could be a handful of reasons, though I'm gonna sound like a broken record :P
- "Going back to 1.1.37 works for me, why bother?" That could change with Ubuntu 10.04
- "It's so freaking obvious, they HAVE to notice someday..." According to what you said earlier, that's wishful thinking
- "Meh, they won't look at it and brush it off as an fglrx issue, not worth my time."
- I could very well be looking for the wrong stuff in the bugzilla entries heh

I'm sure someone will come up with other reasons (including some smartass jabs at ATI).
Regression testing here I come, I guess...

[DeiF]

For these people that play "Populous: The Beginning", or "Heroes of Might and Magic III", a little warning:

If you update Wine to the current version, be sure to update also your kernel to 2.6.34 or greater.

See these bugs:

http://bugs.winehq.org/show_bug.cgi?id=20554

http://bugs.winehq.org/show_bug.cgi?id=20380

[Henri]

I might as well take the opportunity to ask:
To what extent are wine development releases tested on ATI hardware with fglrx?

Essentially, not a whole lot. Although we obviously try to make usable releases, and try to prevent regressions, there's no formal code freeze before releases, which means the regular releases are only slightly more stable than two-weekly snapshots. (In the sense that individual developers try to be sensible and not introduce huge destabilizing changes right before a release.) For testing we're mostly dependent on individual developers testing their changes before submitting them, and users running Wine from git to report regressions before release.

It might be a communication issue but I get the feeling Radeon owners are pretty much treated as second-rate users and served the "It's a fglrx problem" copy/paste as a way to avoid investigating the actual cause of the hickups.

I understand that a few years ago ATI's binary driver was too much a hassle to bother with, so I wonder if the "screw this" mindset is still influencing wine devs without a second thought.

Somewhat, although I can't think of any recent cases where that happened. Keep in mind though that most bugzilla admins aren't wined3d developers or even regular developers at all. On the other hand, when we get e.g. a bug report with a backtrace or assert pointing into the graphics driver, it's still much more likely that it's a problem in the driver than a problem with Wine. The number of situations where that's valid behaviour for an OpenGL implementation is pretty limited. In those cases it makes much more sense to investigate the bug from the point of view of the driver first, and only file a bug with Wine if it turns out that the driver really is behaving properly. I agree that some people on bugzilla could phrase that more carefully though.

Personally I've had problems with anything 3D past 1.1.37 in apps listed in the platinum top 10, problems which nature makes me wonder how this could even get pushed out of the door in that state.

Are there bugs filed for those? I know about one performance issue with at least fglrx and OS X that was introduced around 1.1.37, but that one should be fixed in 1.1.43. There are currently also a number of open regressions related to wined3d's usage of ARB_map_buffer_range, but those aren't unique to fglrx. That's just something that will take some time to properly stabilize, unfortunately.

[Henri]

I thought wine developers wouldn't care about mesa but I was obviously wrong.
I hope mesa & wine developers would work hand-in-hand towards useful graphic drivers.
Wine developers obviously know which functions are pretty useful, mesa developers may be interested in a top lacking-feature list.

We care (I personally do, at least), but there's also only so much you can do in a day. I'm pretty sure the Mesa developers are also familiar with that feeling though. I don't have a detailed list with top issues, but my feeling from the bugs we see in our bugzilla is that problems with FBOs and GLSL are pretty common and general performance and stability could do with some improvements. I don't think that would be a big surprise though. Perhaps less obvious is that I'd expect floating point texture support to become a problem for more recent games, if it isn't already.