Announcement

Collapse
No announcement yet.

Wine 1.1.21 and Fglrx

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

  • #11
    If you mean "different code paths for 9.1 Cat and 9.2 Cat" then I agree completely; code for the most recent. In a case such as pre-6xx support stopping at 9.3 you might end up with a bit of code specific to 9.3 on pre-6xx but in general you want to code for the most recent driver on any hardware class.

    This all echoes around between the vendors of course; it's not unusual for HW vendor A to have a bug, app vendor B to code in a workaround for that bug which breaks support on HW vendor C, so HW vendor C's drivers have to be hacked to duplicate the buggy behavior under certain conditions to make the app work, then when HW vendor A fixes their bug the new version of the app takes out the workaround and HW vendor C has to change *their* driver to take out the simulated bug which made the previous version of the app work. When anyone fixes a bug it takes a while for the ripples to fade

    Between the proprietary and open source drivers I would expect some differences, but the code paths will probably be different anyways because of the different extension sets and the branch criteria would probably not be based on the driver itself.
    Last edited by bridgman; 10 May 2009, 03:59 AM.
    Test signature

    Comment


    • #12
      Now that I can get in game (I disabled audio) it just randomly freezes my whole system up when I use wine for opengl...

      Comment


      • #13
        Originally posted by Qaridarium
        its completly pointless to fix bugs in new software for very old hartware...

        hey i switch from X800 to an 4670 now i have a 4350 and 4670 for gaming an old computers only to surf/klickaround no 3D is needet...

        its completly pointless to make special fixes for modern 3D games vor pre DX10 hartware becourse hd2000 class hartware cost only 5? used....

        upper hartware have 1 more nvidia extansion in openGL soo more code can be shared and upper hartware can use textured vertex shaders X1000 class hartware only can do this in an very diverend way thats hartwork for the wine dev's...

        so in my Point of View its stubit to dev for an X1000 class hartware and older...
        some of that hardware hardly qualifies as very old

        the X2000 series didnt even come out till about this time in 07.... which means that prior to 2 years ago that the X1000 series represented ati's top of the line pc graphics cards... and some of it (an X1950 for insance) can still run an awefull lot of games just fine.

        i certianly agree that the majority of effort should be spent on developing for newer hardware, but i certianly can see why they would want to address major bugs for "legacy" hardware.

        Comment


        • #14
          Well ATI/AMD is such a small company that can not handle things that NVIDIA can do just fine:

          * latest kernel support (even with all tricks possible i get dmesg errors with 2.6.30)
          * h264 accelleration (and even vc1 if somebody needs it)
          * wine working correctly
          * vdrift does not crash x server on exit

          Comment


          • #15
            i fully understand the reasons why amd decided to drop off support - they've been taking a beating and something has to give.

            just saying from the wine developers perspective - i think its perfectly reasonable to address major bugs on "legacy" hardware.

            Comment


            • #16
              Originally posted by Kano View Post
              Well ATI/AMD is such a small company that can not handle things that NVIDIA can do just fine:
              yeah, like providing full hardware specs and open source drivers. Oh, wait...

              also, please everyone ignore that AMD has three times as many employees as nvidia and the whole argument as presented is pointless.

              * latest kernel support (even with all tricks possible i get dmesg errors with 2.6.30)
              I get dmesg errors with nvidia-drivers all the time, no matter the kernel version. What was your point again?

              * wine working correctly
              this isn't entirely ATIs fault, as wine's D3D-layer was developed for nvidia hardware/drivers. Try the same games on wine on intel GPUs - given intel's size, it should be flawless, right?

              Let me rephrase your post:
              Nvidia's drivers suit my specific needs way better than ATI's, therefore ATI must suck. Because I like my world simple, I'll just blame company size.
              What matters isn't company size, but dedicated linux resources and priorities.

              nvidia can support recent kernels by throwing our betas like there's no tomorrow, ATI has longer internal testing phases for the proprietary drivers (and as a result less bloopers in publicly available drivers), but does support new kernels immediately using the in-kernel DRM of mesa.

              NVidia has time to develop VPDAU, while AMD is tied up in a massive open sourcing effort, writing up specs and maintaining two drivers at once.

              right now, nvidia's drivers may suit your needs better than others. That's fine, keep using them. But concluding that AMD/ATI dedicates less resources to their linux support than nvidia is pretty uninformed.

              Comment


              • #17
                "ATI has longer internal testing phases" - yes they are so long that they need 18 month to fix some bugs.

                Comment


                • #18
                  Originally posted by Kano View Post
                  "ATI has longer internal testing phases" - yes they are so long that they need 18 month to fix some bugs.
                  as opposed to the memory leak issues that have been plaguing nvidia drivers for as long as i've been using linux at least....

                  or the fact that i had to try three different versions of the official nvidia drivers on my moms computer to find one that wouldn't cause it to periodically lock up.

                  Comment


                  • #19
                    In some cases nvidia drivers do not fully work correct, but you can at least ask questions in nvnews.net and see if some devs will look at the issue. In most cases those are not known or hard to reproduce. Also you do not have to wait from month to month for next drivers, but they are released if needed (can be longer than a month too).

                    Comment


                    • #20
                      Originally posted by bridgman View Post
                      Between the proprietary and open source drivers I would expect some differences
                      Slightly offtopic but do you also expect such differences to be between two Gallium drivers for different vendor's cards? (eg Intel vs Ati)

                      Comment

                      Working...
                      X