Announcement

Collapse
No announcement yet.

Wine 1.1.43 Brings Many Direct3D Fixes, Optimizations

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    man, stop whining! this is open source software, you know, people develop things as they see fit. And most wine developers are already occupied implementing a handful of windows functions. Also, codeweavers can't support every game/app. Wine will stay pretty much unstalbe until version 2.0.

    But, if you're a geek like me, you can fiddle with every wine release, every wine tweak and have a lot of windows games work with little flaws.

    Comment


    • #17
      it's really cool to do this by using q4wine, creating your own separate wine bottles for each game, compiling your own patched wine, and making then breakable, unlike windows

      Comment


      • #18
        Originally posted by V!NCENT View Post
        If only the Wine team would get together and fix these papercuts for a month long; Wine would be able to run games for end-users.

        And that's the point anyways...

        If only all Wine devs got together and decided
        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.

        Comment


        • #19
          Originally posted by Qaridarium View Post
          wine do not support the radeon opensource driver (mesa7.7/7.8)

          "wined3d: Don't use GLSL if the supported version isn't at least 1.20. "

          yes very nice wine packages... (ironic)
          If you think end of year linux releases will be using mesa 7.7 then you are living in a cave.

          Comment


          • #20
            Originally posted by V!NCENT View Post
            If only the Wine team would get together and fix these papercuts for a month long; Wine would be able to run games for end-users.
            Another major release is coming up, so now would be the perfect time to suggest a "100 papercuts" on the Wine mailing list. I think it's a great idea.

            Comment


            • #21
              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).

              Comment


              • #22
                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.

                Comment


                • #23
                  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.

                  Comment


                  • #24
                    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.

                    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.

                    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.

                    Comment


                    • #25
                      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

                      Comment


                      • #26
                        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...

                        Comment


                        • #27
                          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? -_-'

                          Comment


                          • #28
                            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

                            Comment


                            • #29
                              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.

                              Comment


                              • #30
                                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.

                                Comment

                                Working...
                                X