Announcement

Collapse
No announcement yet.

Open source drivers for 5850...when?

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

  • #11
    Originally posted by bridgman View Post
    If the "slow responsiveness" comment refers to maximizing windows there is an X server patch to help with that.

    If "tearing" refers to lack of sync-to-vblank in Xv then using GL output will let you enable sync-to-vblank and eliminate the tearing.

    I haven't heard about "cursor hidden" issues, can you pls provide more info or file a Bugzilla ticket at http://ati.cchtml.com ?

    The "unsupported hardware" watermark should go away with the October Catalyst driver.
    Yes, I know this patch, for desactivate backlight to solve minimize-maxime problem, but the solution you propose to solve tearing, is only to solve video, not to solve tearing when animations like moving windows...

    However, I'm now using open drivers in spite of the incorrect resolution and second display disconected, but works very fluently for me, and this is the most important in my case.

    Im sad to think that with my old NVIDIA 8800 GTX the driver was nearly perfect, without slowness, tearing and working very fluently. I hope AMD will put more effort working on it.

    Cheers

    Comment


    • #12
      Originally posted by bridgman View Post
      If the "slow responsiveness" comment refers to maximizing windows there is an X server patch to help with that.

      If "tearing" refers to lack of sync-to-vblank in Xv then using GL output will let you enable sync-to-vblank and eliminate the tearing.
      Yeah there's truth behind both of these statements, and I am liking the development of fglrx but the previous poster is simply right for the moment.

      2D performance is bad with and without Composite when compared to let's say the open source radeon driver. What worries me most is that even though r600 in Mesa is very new, its Composite performance and experience is already a lot better than fglrx. Xv is also not so fun with fglrx, not only because of the tearing but there's those washed out colours aswell.

      In everything the open source drivers support, they're leading the way. And the things they don't support are being worked on.

      Comment


      • #13
        It's funny how much flak AMD is getting despite being a very linux friendly company.

        In older times, everyone was shouting "we don't want fglrx, we want documentation and OS drivers!". AMD provided. The result?

        Now half the people are shouting "improve fglrx, implement EXA!", the other half "there are still bugs in the OS drivers, go fix them! And get 5xxx support in there yesterday!".

        For what it's worth, AMD only has finite resources, and the way they're using them makes me happy. The future for consumers isn't an improved fglrx, but a working OS stack where every part of the system works together and new features or architectural changes don't depend on the whims and priorities of small internal proprietary driver teams (like KMS, DRI2 and proper multiseat). The road there is long and rocky, but it's the right thing(tm) to do if you look at the big picture.

        Best yet, we're almost there, support until 4xxx is almost complete and just a matter of time until it bubbles up the release chain and is available to everyone on every linux CD, just working out of the box. We're through the worst, from now on it'll only get better.


        Edit: sorry bridgman for making false assumptions. I edited the part out.
        Last edited by rohcQaH; 25 October 2009, 12:28 PM.

        Comment


        • #14
          One minor point - we actually shifted *more* resources to fglrx, not less. The open source work comes out of a separate budget.
          Test signature

          Comment


          • #15
            Originally posted by rohcQaH View Post
            It's funny how much flak AMD is getting despite being a very linux friendly company.

            In older times, everyone was shouting "we don't want fglrx, we want documentation and OS drivers!". AMD provided. The result?

            Now half the people are shouting "improve fglrx, implement EXA!", the other half "there are still bugs in the OS drivers, go fix them! And get 5xxx support in there yesterday!".

            For what it's worth, AMD only has finite resources, and the way they're using them makes me happy. The future for consumers isn't an improved fglrx, but a working OS stack where every part of the system works together and new features or architectural changes don't depend on the whims and priorities of small internal proprietary driver teams (like KMS, DRI2 and proper multiseat). The road there is long and rocky (especially as fglrx suffers while priorities shift to the OS drivers), but it's the right thing(tm) to do if you look at the big picture.

            Best yet, we're almost there, support until 4xxx is almost complete and just a matter of time until it bubbles up the release chain and is available to everyone on every linux CD, just working out of the box. We're through the worst, from now on it'll only get better.
            This.

            The only thing that I see a bit different is that people who are moaning about stuff not working as good as people liked them to (maybe you could include my last post) do appreciate the opensource strategy of AMD. It's not that if you say "this doesn't work", you're already switching to nVidia. In fact, I've built countless computer systems for friends and school and every single one of them is completely based on AMD products.

            Regarding the opensource stack development. I am running karmic+xorg-edgers right now and just came back from playing Nexuiz on a Compiz-enabled desktop with my HD 4850.

            Comment


            • #16
              Why not drop fglrx and shift development resources to the open-source driver? Improve it so that all enterprise customer needs can be met through a single driver.

              Comment


              • #17
                If the fglrx driver was a standalone code base, ie if it were written by a team which only worked on Linux, then shifting all the resources to the open source code base would be an option. That's not the situation, however -- remember that fglrx shares most of its code with drivers for other OSes, and we can't make *that* code public and still be able to use it effectively on the other OSes.

                If we moved the Linux-specific resources onto the open source driver and gave up the benefits of code sharing, I don't think those resources would be sufficient to give us a competitive 3D workstation driver. For the other enterprise markets (ie other than 3D-intensive ones) I suspect the open source drivers will be fine.
                Last edited by bridgman; 25 October 2009, 04:52 PM.
                Test signature

                Comment


                • #18
                  How "intensive" are you talking about with 3D?

                  Originally posted by bridgman View Post
                  For the other enterprise markets (ie other than 3D-intensive ones) I suspect the open source drivers will be fine.
                  You imply that 3D will never be great with the Open Source drivers. And yet 3D is the aspect that some of us care about the most. For example, I still have hopes of entering Dalaran and Northrend some day with AMD hardware. (Blizzard's recommendation here is only a X1650, whereas I have a HD4650, but even using fglrx I can only get about 20fps in Ironforge or Shattrath.)

                  Does WoW count as "3D intensive" in OpenGL mode? Or could Wine somehow be a bottleneck? Should people who want to play WoW using Open Source drivers be prepared for a massive disappointment?

                  Comment


                  • #19
                    Originally posted by chrisr View Post
                    You imply that 3D will never be great with the Open Source drivers. And yet 3D is the aspect that some of us care about the most.
                    No, I'm implying that open source 3D will probably not match the performance and features of the proprietary drivers to a sufficient extent that we could compete in the 3D workstation business using only those drivers.

                    In the workstation business you can win or lose big chunks of business based on relatively small differences in 3D performance or features. We need proprietary drivers in that market. For most consumer Linux apps, however, including 3D games, I think the open source drivers will end up with sufficient speed and functionality after the current wave of rearchitecture work settles down.

                    If the combination of application and hardware is such that you need every last scrap of 3D performance to even be *barely* fast enough with a proprietary driver then there's a reasonable chance the open source drivers will be just slow enough to push you over the "too slow" line. That said, I don't think anyone will be able to tell you *exactly* where that line is until some more Wine and Gallium3D work has happened.
                    Last edited by bridgman; 25 October 2009, 06:13 PM.
                    Test signature

                    Comment


                    • #20
                      Originally posted by chrisr View Post
                      Does WoW count as "3D intensive" in OpenGL mode? Or could Wine somehow be a bottleneck? Should people who want to play WoW using Open Source drivers be prepared for a massive disappointment?
                      The OGL rendering engine from WoW is Crap nothing else. If you use windows and set the renderer to OGL you has the same result.

                      Comment

                      Working...
                      X