Announcement

Collapse
No announcement yet.

Wine 1.1.23 Released With Various Fixes

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

  • #16
    Usually the "native" apps then have to program around fglrx problems too. If they don't they could even crash the xserver - like vdrift when you end it. I would see wine as opportunity to reproduce outstanding bugs in order to fix em. When you can reproduce em then you can at least verify more easy if changes fixes em or not. nvidia just looked more carefull at outstanding rendering bugs than ati. The target should be always a flawless driver, which is of course not so easy to archive, but telling the ppl that rendering issues and video issues are not really the main target - as long as some workstation apps work which are usally not used by ppl who buy the gamer series cards - must be a joke. When you look at the sales numbers ati should notice gaming cards are the majory. Focussing on the minority with very few bugs is somehow extra stupid.

    Comment


    • #17
      Here we go again...

      Anyway, the way I see it and have understood it up to now, is that fglrx targets workstations and the like, and the open drivers the home desktop user. ATI is starting to optimize fglrx toward the desktop environment, which is a big plus over the driver's intended purpose.

      Comment


      • #18
        Originally posted by RealNC View Post
        The conclusion I draw from all this is that NVidia simply cares about features and performance while AMD does not or lacks the knowledge for it.
        No nVidia push others to use their extensions and to think their way, not everytime invite some goodness, but always it's vendor way... So yes they just have that power in OpenGL area, but AMD also have knowledge in other area like http://www.pcper.com/article.php?aid=724. Guess how Wine will attempt to implement that "tesselation"...

        Originally posted by Thunderbird View Post
        The only major issue around now is that there are buggy FBO implementations. Wine is the most complicated opengl program around.
        One more major issue is also that in 1.1.23 backbuffer is not working any more as expected (i tested this on DRI drivers), will that tend to be deprecated or maybe even removed?

        I always suppose that silence meaning recognition, but it's OK - Wine developers often don't even have other cards then nVidia's, but always know when all other drivers are wrong.


        -------++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++-------
        No i don't want to whining or trolling here, but i hate any vendor only solution everywhere, even more when some developers rumor about how they actually support standardization in their software, but on the other hand everyone can see that source is full of quirks for nVidia, but others can just fix their drivers. That is it. Maybe Wine is just one game that needs to be fixed!

        Comment


        • #19
          The Way It's Meant To Be Played

          Comment


          • #20
            Originally posted by Melcar View Post
            The Way It's Meant To Be Played
            Yes that way, pushing and scrapping all around

            But why Wine do the same is another question?

            Comment


            • #21
              Because it's easier to use NVidia's extensions maybe. They "just work". NVidia was always providing support for fast gaming. If the standard sucks, NVidia steps in. That's not a bad thing. It shows they want their cards to be fast. And they are. NVidia is not the industry leader in high performance graphics for no reason.

              Comment


              • #22
                Originally posted by RealNC View Post
                Because it's easier to use NVidia's extensions maybe.
                And maybe not, their extensions are often bloated and hard to use.

                They "just work".
                Marketing... When they not, there is multisampling quirk ready to help in nVine pleasure.

                NVidia was always providing support for fast gaming.
                And others provide nothing?

                If the standard sucks, NVidia steps in.
                Standards never sucks, leave make up to your girl.

                That's not a bad thing.
                Who said that it is?

                It shows they want their cards to be fast.
                We all want our cards to be fast as Tesla's lightning.

                And they are.
                As Tesla's lightning?

                NVidia is not the industry leader in high performance graphics for no reason.
                Agree, there are many reasons. Half of them are naturally at 50%.
                Last edited by dungeon; 06-08-2009, 12:28 AM.

                Comment


                • #23
                  Well, Medieval 2 and Rome no longer install and Furmark runs at half speed now. I guess it's either back to 1.1.22 or start hacking. Thankfully Fallout remains playable .

                  Comment


                  • #24
                    Originally posted by dungeon View Post
                    And maybe not, their extensions are often bloated and hard to use.
                    At least they provide extensions. As Thunderbird said, Wine on ATI is slow and buggy. "Bloated and hard to use". Yeah. Right.

                    And others provide nothing?
                    Nothing that works at least.

                    Standards never sucks, leave make up to your girl.
                    I think you're obsessed with something. Someone who knows a lot about 3D and Wine just told you why NVidia is best for it, but still you won't admit that ATI just isn't up to par here. I already discussed this too long with you. There's no point trying to talk sense into fanbois.

                    Comment


                    • #25
                      Next to the FBO change there were lots of other changes in 1.1.23 and those seem to have caused some small regressions. This causes that moving to backbuffer still doesn't allow you to run some games.

                      Further as I said we are only using nvidia shader extensions (and that code was written in the last couple of weeks), we always have fallbacks. For >=SM3.0 we are just using glsl. Further even if we were using NV extensions nothing forbids lets say ATI to also add those (as I mentioned S3 offers the same extensions).

                      Comment


                      • #26
                        Originally posted by RealNC View Post
                        At least they provide extensions. As Thunderbird said, Wine on ATI is slow and buggy. "Bloated and hard to use". Yeah. Right.


                        Nothing that works at least.


                        I think you're obsessed with something. Someone who knows a lot about 3D and Wine just told you why NVidia is best for it, but still you won't admit that ATI just isn't up to par here. I already discussed this too long with you. There's no point trying to talk sense into fanbois.
                        You're trying to manipulate words here. Several points: ATI have always provided their own extensions as well. I think it was VBOs that ATI pushed ahead - nvidia preferred something else (VARs).
                        ATI not up to par? Wine could be changed to take advantage of ATI cards, then you could say nvidia wasn't up to par. Again, it's about developer experience and being able to work around things - this applies to ati, nvidia, and I'm guessing intel as well. I've written my own apps that work great on an ATI card, but horribly slow on nvidia - and this applies to both windows and linux (never tried on a mac, but wanted to). Oh look, nvidia drivers must be crap. No - I just have more experience with ATI.
                        I'm going to call you an nvidia fanboy, as it certainly seems that way. Nothing wrong with that - but do please add some substance to what you say.

                        Comment


                        • #27
                          I don't get you. When you know ATI so well then optimize wine for it yourself instead complaining...

                          Comment


                          • #28
                            Originally posted by Kano View Post
                            I don't get you. When you know ATI so well then optimize wine for it yourself instead complaining...
                            Sorry, I forgot, this is the internet. Some degree of sense and reason doesn't belong.

                            Comment


                            • #29
                              The relevant Wine bug report is http://bugs.winehq.org/show_bug.cgi?id=18794. This is a fglrx bug, plain and simple. The backtrace looks like a simple NULL-pointer dereference, which shouldn't be particularly hard to fix.

                              I already notified an fglrx developer about this. I will also file a proper bugreport with testcase on http://ati.cchtml.com/, probably later today. (And in case any ATI/AMD people read this, you guys *really* need to fix that. Having only an unofficial bugzilla that someone might read or not isn't the way to handle developer relations.)

                              On the subject of AMD running the Wine test suite or not, that's their choice to make of course. However, I think it's important to note that many of the tests in there were added as a result of fixing actual bugs in real applications. Failures in those tests usually translate into real bugs in real applications.

                              It's certainly true that at least some time ago most Wine (D3D) developers and users had nvidia cards. I think it's not hard to see why, given fglrx's quality in the past. More recently, as fglrx's quality has been improving, that's been changing. (And fwiw, Thunderbird actually has an AMD card.) That's an advantage for nvidia of course, but not due to malicious intend on our side. It's simply a result of ATI's historic policy of spending effort on fglrx proportional to Linux market share. That too was their choice to make. Either way, the current situation is that while fglrx is certainly improving, it isn't quite there yet in terms of support for features like FBOs and GLSL. Neither is Mesa/DRI, but things are improving there as well.

                              @dungeon: I think I asked you to do a regression test. Perhaps I'm mistaking you for someone else though.

                              Comment


                              • #30
                                Originally posted by Henri View Post
                                The relevant Wine bug report is http://bugs.winehq.org/show_bug.cgi?id=18794. This is a fglrx bug, plain and simple. The backtrace looks like a simple NULL-pointer dereference, which shouldn't be particularly hard to fix.
                                Perhaps, but it looks like Wine's doing something a bit iffy. It appears to be attaching textures to FBOs with formats the specification explicitly forbids, apparently in the process of blindly trying all possible texture formats to see which can be attached. Something that fglrx should handle without crashing, certainly, but not exactly a normal or sane thing to do.

                                Also, if this was an NVidia driver bug, I really doubt Wine would do a release in the current state. They've broken all D3D apps under fglrx, since this test is done during D3D initialization. However, since fglrx is a second-class citizen in the Wine world...

                                Comment

                                Working...
                                X