Announcement

Collapse
No announcement yet.

Whoops, ATI's Evergreen Will Bring A New Driver

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

  • #61
    Originally posted by pvtcupcakes View Post
    I think he's talking about accelerated 2D like EXA or Xv.
    But you're right in that r800 can draw stuff on screen. It's just not hardware accelerated.
    Exactly.
    I think, im settled with HD4770. Its 40nm as HD5xxx, has performance similar to 5750(well, a bit slower, but Wattage is lower too), and its R700, that's back'd up.

    I was unable to find blow-out air-tube cooler, as with XFX, but oh well. I will create my own from empty DVD cases...

    Thanks everyone, and thanks to AMD devs for caring about FOSS. Bb nvidia

    Comment


    • #62
      Originally posted by Veerappan View Post
      Yes, it does. I have a Radeon 4770 in my desktop at home and Ubuntu 10.04 has hardware-accelerated 3D via Mesa. Compiz is working, suspend/resume is working, native games (the one's that I've bothered benchmarking using PTS) are working.
      Ty!



      <blablablamessagelimitblablabla>

      Comment


      • #63
        what?

        Originally posted by smitty3268 View Post
        To make it a little simpler, which of these (completely made up) scenarios makes more sense:

        1. Work 1 week on refactoring the classic driver to include r800 register offsets. Then work 3 weeks trying to get the 3D hardware actually working. Then port everything over to Gallium, throwing away the refactoring work you did.

        2. Work 4 weeks trying to get the 3D hardware working. Then port everything over to Gallium.
        why would you throw away stuff in scenario 1? I don't see that. I fact, I think this scenario is the best reflection of reality: r800 differs only (mainly) in register offsets. it actually exploits the major similarities in the chips.

        If you loose stuff in 1 then you'll also loose the same stuff in 2...

        beside, if classic mesa driver can be unified for r300-evergreen then a gallium driver can probably also be unified!

        Comment


        • #64
          Originally posted by bridgman View Post
          Again, the only reason doing this makes sense is if there *is* no future, ie if we move from "classic" to Gallium3D drivers which would be a different code base anyways.

          If it turns out that we need to stay with the classic mesa drivers for a while then we probably would want to merge 6xx/7xx with Evergreen and later, but *after* the initial working code is in a public repo and in users hands.
          there is no future? there's always a future: maintenance of the driver! I have learned to never underestimate that effort: every project stage increases software effort 10-fold... Any reuse will pay itself back very quickly...

          Even now I have very strange and unreproduceable weirdness in my T60 laptop with X1400: sometimes the gfx get into a state where the whole system goes into major stutter mode: work for .1 second, hang for 1 second, repeat. Switching to text mode (KMS enabled) and switching back to gfx mode usually fixes it. Once someone fixes this bug it must be applied over multiple drivers in your copy scenario. wouldn't it be better if it were only 1 driver? :-)

          if classic mesa driver can be unified for r300-evergreen then a gallium driver can probably also be unified!

          anyway, I really appreciate the work you and the rest of the guys are doing. you're interaction with the community is wonderful, keep up the good work!

          Comment


          • #65
            But... but... the classic mesa driver is *not* unified that way today. The r300 driver covers 3xx, 4xx, 5xx and the r600 driver covers 6xx, 7xx and (maybe) Evergreen. There are no plans to merge the r300 and r600, either in classic or Gallium3d form.

            Again, all we're saying here is that burning cycles to keep Evergreen in the same "classic" driver as 6xx/7xx only makes sense if we do *not* move to a Gallium3D driver, since the G3D driver would be structured differently anyways. The only thing that's different now is that we separated out the "get Evergreen support running" work from the "make a merged driver" step, which lets Evergreen support get out faster and avoids investing time in a maintainable classic driver if we're going to jump across to Gallium3D immediately anyways.

            Comment


            • #66
              Originally posted by fhuberts View Post
              there is no future? there's always a future: maintenance of the driver! I have learned to never underestimate that effort: every project stage increases software effort 10-fold... Any reuse will pay itself back very quickly...
              Sure, but the point is that we may not be maintaining *that* driver. I agree completely that investing in improving maintainability of the driver we are going to maintain is a Good Thing, but it's not decided yet whether the driver we maintain is going to be the "classic" one we use to deliver initial support or the Gallium3D one.

              Comment


              • #67
                Originally posted by bridgman View Post
                Sure, but the point is that we may not be maintaining *that* driver. I agree completely that investing in improving maintainability of the driver we are going to maintain is a Good Thing, but it's not decided yet whether the driver we maintain is going to be the "classic" one we use to deliver initial support or the Gallium3D one.
                Start a poll here ...
                (Just an idea)

                Comment


                • #68
                  Personally, I think doing solid ground and then building there is better, than maintaining both "houses" half-alive. Time passes, new generations come out...

                  Comment


                  • #69
                    Originally posted by crazycheese View Post
                    Start a poll here ...
                    (Just an idea)
                    I would vote for getting the code out in the open as soon as possible. I guess that probably means a separate dri driver for Evergreen.

                    Comment


                    • #70
                      Wow, it's amazing how many armchair coders we have here at phoronix. Everyone seems to think the driver developers are really stupid...

                      I'm not saying whether it's the best plan or not, I really am not in any position to know. But I do trust the actual developers to make the right decision. This isn't rocket science, code duplication and the tradeoffs involved here are pretty basic stuff when it comes to software management.

                      Anyway, to the people talking about keeping both houses alive, or maintaining this in the future, you're completely missing the point. Which is that this copied driver will be deleted in a month, that it's a private experimental driver that will never be supported by anyone. You guys would never have even heard of this if bridgman hadn't announced it, it just would have been another branch of code that came and went silently.

                      Comment


                      • #71
                        V!ncent, if you want to prove you have accel, post Xorg.0.log instead.

                        Comment


                        • #72
                          Originally posted by smitty3268 View Post
                          You guys would never have even heard of this if bridgman hadn't announced it, it just would have been another branch of code that came and went silently.
                          Bingo... and I wouldn't have said anything about it if I hadn't just finished telling the mesa dev list folks that we were going to do something different an hour before we had the latest meeting.

                          I kinda felt it was important to tell them what was going on, since the implication was that the 7xx-to-Evergreen transition might end up being a good opportunity for jumping to Gallium3D despite having said the exact opposite an hour earlier

                          Comment


                          • #73
                            Originally posted by bridgman View Post
                            Bingo... and I wouldn't have said anything about it if I hadn't just finished telling the mesa dev list folks that we were going to do something different an hour before we had the latest meeting.

                            I kinda felt it was important to tell them what was going on, since the implication was that the 7xx-to-Evergreen transition might end up being a good opportunity for jumping to Gallium3D despite having said the exact opposite an hour earlier
                            What's with the Evergreen codename anyway? Is it the first one that AMD named instead of ATI? Or do you guys just suddenly hate numbers now? It seems like it would be a lot simpler to just keep having increasing numbers, now we have to try and remember which names come before others - yuck.

                            Comment


                            • #74
                              No, we just like trees... and islands...

                              Comment


                              • #75
                                Originally posted by salva84 View Post
                                You are right, I have an ATI 5850, the fglx drivers are really slow even scrolling web pages in firefox.... and the open source drivers are always "coming".... For me, the solution I've found is to execute Linux in a Virtualbox machine inside Windows 7. No more problem with graphics, suspend / hibernate, I can make a backup of the whole system, and I dont have to reboot to play some games.
                                See, I know exactly what you mean. I have been a loyal ATI user since the Radeon 9700 days. I started converting myself to a full time Linux user in the Radeon X1900 era (3~4 years ago?) and the experience has always been like what you said Fglrx has always been a crap, endless crashing, slowing down, corrption, watermark?! And OSS driver by that time does not even support 2D acceleration in my X1900, so I waited and waited and waited still I sold my X1900 and it still doesn't work in Linux. My next purchase, the most regretful one was HD 2900 PRO. I could have gone to nVidia and be happy once and for all, but 2900 drag me into the same loop hole. Fglrx after two years was still just like before, slowing down in scroll, card fan fires up at full speed, lock ups and shit, and they got X1000 series working in OSS driver! but I upgraded to HD2000 family, by which time the OSS driver still did not support yet. So another year of wait. And this keeps on going for my HD 4850. You see, you can never get out of this waiting loop hole unless you jump ship to use something else. You can either use new NVidia cards, or you can use ATI cards which are 5 years old. But new ATI card on Linux? come on that's never gonna ever happen.

                                Comment

                                Working...
                                X