Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 32

Thread: Wine 1.1.43 Brings Many Direct3D Fixes, Optimizations

  1. #21
    Join Date
    Sep 2008
    Location
    Netherlands
    Posts
    510

    Default

    I knew such a project was already in place: http://wiki.winehq.org/WineReleaseCriteria

    You can nominate "small but embarassing" bugs as release criteria of Wine 1.2 (I wish they'd just call it Wine 2.0).

  2. #22
    Join Date
    Feb 2009
    Posts
    45

    Default

    Quote Originally Posted by Shining Arcanine View Post
    Would it be wishful thinking to expect Linux to become a better Windows than Windows at some point?
    That mostly depends on how you define "better". E.g. if that's a comparison in terms of performance, it's not completely impossible, but unlikely in the immediate future. (However, for some (very) specific applications Linux + Wine may already outperform Windows.) If for example your main concern is licensing it may already be "better", depending on your preferences. If you look at features and compare to specific Windows versions, Wine will for example likely support D3D10/11 in the future, while e.g. Windows XP most likely won't.

    The point is that you can't make a simple comparison like that without being very specific about what's important to you, and the situation may also be different for different applications.

  3. #23
    Join Date
    Feb 2009
    Posts
    45

    Default

    Quote Originally Posted by MPF View Post
    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.

  4. #24
    Join Date
    Feb 2009
    Posts
    45

    Default

    Quote Originally Posted by PsynoKhi0 View Post
    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.

    Quote Originally Posted by PsynoKhi0 View Post
    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.

    Quote Originally Posted by PsynoKhi0 View Post
    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.

  5. #25
    Join Date
    Apr 2010
    Posts
    94

    Default

    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

  6. #26
    Join Date
    Feb 2010
    Posts
    519

    Default

    Quote Originally Posted by Henri View Post
    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...

  7. #27
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    Quote Originally Posted by Joe Sixpack View Post
    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? -_-'

  8. #28
    Join Date
    Feb 2010
    Posts
    4

    Default

    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

  9. #29
    Join Date
    Feb 2009
    Posts
    45

    Default

    Quote Originally Posted by PsynoKhi0 View Post
    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.

  10. #30
    Join Date
    Feb 2009
    Posts
    45

    Default

    Quote Originally Posted by notaz View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •