Announcement

Collapse
No announcement yet.

Open-Source ATI R600/700 3D Driver Almost Working

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

  • #11
    I thought the 3d part would be more ready.

    I planed to buy a hd4870 1gb next week, but as i see i will not have 3d with the open driver till the dx11 ati cards come out (October), fglrx is no option for me. So i have no compiz for several months, I really consider my planed buying now.

    Right now i have an x800xl, maybe i look for an used X1950xtx or something like that, is the 3d part for r500 fast enough to play lets say quake wars on 1920x1200 with high settings? (without AA)

    Comment


    • #12
      I'd be happy if i could use Google Earth at least... the open source driver is really nice, but as times passes i realize how often i would appreciate a 3D driver. I won't go back to fglrx, because i can't watch videos there (tearing alarm) and the sleep modes won't work. So i realize that i've wasted some money for my notebook with a good 3d card in it, because i can't use it...
      The news that 3d could come by the end of summer saddens me even more...

      Comment


      • #13
        Originally posted by blackiwid View Post
        I thought the 3d part would be more ready.

        I planed to buy a hd4870 1gb next week, but as i see i will not have 3d with the open driver till the dx11 ati cards come out (October), fglrx is no option for me. So i have no compiz for several months, I really consider my planed buying now.

        Right now i have an x800xl, maybe i look for an used X1950xtx or something like that, is the 3d part for r500 fast enough to play lets say quake wars on 1920x1200 with high settings? (without AA)
        Don't expect a working/stable/efficient ATI 3d driver before 2011. Considering the world ends in 2012 I suggest to avoid buying AMD. Buy an NVIDIA, at least you "finish" with a working gpu (but you might go to hell since their blob driver is unmoral. It's the only real driver really working good on Linux as of today but it's unmoral, so you decide: heaven without candy or hell with candy) :P
        Last edited by bulletxt; 03 July 2009, 11:22 AM.

        Comment


        • #14
          Originally posted by blackiwid View Post
          I thought the 3d part would be more ready.

          I planed to buy a hd4870 1gb next week, but as i see i will not have 3d with the open driver till the dx11 ati cards come out (October), fglrx is no option for me. So i have no compiz for several months, I really consider my planed buying now.

          Right now i have an x800xl, maybe i look for an used X1950xtx or something like that, is the 3d part for r500 fast enough to play lets say quake wars on 1920x1200 with high settings? (without AA)
          Why is fglrx no option for you? If it's because it's closed source, then why do you want to buy a high-end card that couldn't be properly accelerated by the opensource driver anyway?

          Comment


          • #15
            Maybe because you have to switch between drivers to get a tearfree xv?

            Comment


            • #16
              because i use then another os (windows) to play games. all other than games dont need soo much acceleration.

              But i want get at least in near future compiz working with it, and enemy territory. maybe with 1920x1200 then i am happy for other games i have to use windows anyway, ok a few of em will work after several time with mesa, but thats no good alternative.

              Comment


              • #17
                In case this helps anyone understand the timing and status better, by early April Richard and Cooper had most of the driver code written and running including glxgears, texture operations, and arb_fp/arb_vp support with a working shader assembler. Like most fresh-from-the-developer code, it only really worked on the developers own systems and it had a bunch of obvious bugs, but all the core bits were in place and ready for integration testing.

                Unfortunately, by that time it had also become obvious that we would have to move onto the new bufmgr/cs code (from radeon-rewrite) before the driver could be broadly useful, since radeon-rewrite was going to merge into mesa master shortly. In case it's not obvious, that was *not* part of the original plan.

                Alex wrote an initial implementation of the new CS ioctls in mesa/drm (that's why the drm code is in ~agd5f/drm), and in early April we started moving the driver across to the new code base. That work is now pretty much finished, although there is at least one open problem with buffer allocation which shows up as a glxgears segfault, and the texture code still needs to be merged with bufmgr/cs and made to work.

                If you put your thumb over the April-to-now time period (mostly porting to radeon-rewrite and vacations) you'll probably get a better sense of the rate of progress.
                Last edited by bridgman; 03 July 2009, 12:56 PM.
                Test signature

                Comment


                • #18
                  Originally posted by bridgman View Post
                  In case this helps anyone understand the timing and status better[
                  I does indeed!. So, how are things looking from now on considering the change in plans. Could you please give a bit of a flavor of the next milestones and circa when they are being shot for. Of course I understand you might prefer not to, given that some ... ahem ... systematically negative people could hang on to it in the future to complain if something gets delayed.

                  I really think it would be nice to have parties in some bigger cities (in whatever country people are) to celebrate THE milestone I don;t know how many people would be interested, but I think it will be a historic moment for open/free software (unimaginable just 10 years ago).

                  Thank you all who are making this happen!

                  Comment


                  • #19
                    Originally posted by bridgman View Post
                    In case this helps anyone understand the timing and status better, by early April Richard and Cooper had most of the driver code written and running including glxgears, texture operations, and arb_fp/arb_vp support with a working shader assembler. Like most fresh-from-the-developer code, it only really worked on the developers own systems and it had a bunch of obvious bugs, but all the core bits were in place and ready for integration testing.

                    Unfortunately, by that time it had also become obvious that we would have to move onto the new bufmgr/cs code (from radeon-rewrite) before the driver could be broadly useful, since radeon-rewrite was going to merge into mesa master shortly. In case it's not obvious, that was *not* part of the original plan.

                    Alex wrote an initial implementation of the new CS ioctls in mesa/drm (that's why the drm code is in ~agd5f/drm), and in early April we started moving the driver across to the new code base. That work is now pretty much finished, although there is at least one open problem with buffer allocation which shows up as a glxgears segfault, and the texture code still needs to be merged with bufmgr/cs and made to work.

                    If you put your thumb over the April-to-now time period (mostly porting to radeon-rewrite and vacations) you'll probably get a better sense of the rate of progress.
                    Thank you for the explanation. It answered some of the the questions I had concerning the R600/R700 code (mostly about timing).

                    Comment


                    • #20
                      The tasks and milestones are pretty easy but putting dates on them right now is tricky. The big unknown is whether our in-depth understanding of current Mesa internals is solid or not, and we'll only find that out by testing.

                      The sequence of events for the short term is pretty simple though -- fix whatever is causing the glxgears segfault, finish hooking up texture code to the new buffer management logic, then test, fix, repeat. Most of the code is already written and has at least passed basic smoke tests, so the driver could come up really fast or it could drag on for a while. It all depends on whether we find any fundamental defects in the design. I don't think we will, but you never know.
                      Last edited by bridgman; 03 July 2009, 02:41 PM.
                      Test signature

                      Comment

                      Working...
                      X