Announcement

Collapse
No announcement yet.

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

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

  • #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; 07-03-2009, 12:56 PM.

      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; 07-03-2009, 02:41 PM.

            Comment


            • #21
              Originally posted by Kano View Post
              Maybe because you have to switch between drivers to get a tearfree xv?
              Yes, but you can just use OpenGL output under fglrx if you have an okay R6xx/R7xx GPU and there is far less tearing than with XVideo under fglrx. (My HD 3850 has about 40% GPU load at 300 MHz when playing back 1080i video using OpenGL output.) It's not an ideal situation as OpenGL output in my opinion doesn't look as good as XVideo, but it should be "good enough" for those who also want to use 3D applications with their ATi GPUs.

              If somebody is running an HTPC or just wants to do 2D desktop work and play videos, I suggest skipping fglrx and using the Xorg radeon driver with a 2.6.30 or better kernel. XVideo with xorg-video-radeon has *excellent* video quality and is much lighter on the CPU and GPU than fglrx + OpenGL output.

              Comment


              • #22
                3D Driver Almost Working
                Please reserve that for when this driver can play at least half the games the Nvidia driver can play.

                Comment


                • #23
                  First of all using opengl for video is just a really ugly workaround and no solution - xv has to work correctly! Also fglrx opengl does not work with xinelib backend in kaffeine/xine somehow here.

                  Comment


                  • #24
                    Originally posted by cruiseoveride View Post
                    Please reserve that for when this driver can play at least half the games the Nvidia driver can play.

                    I didn't know the nvidia open driver could play 3D games.

                    Comment


                    • #25
                      noueveau might be able to do, but never tried.

                      Comment


                      • #26
                        Originally posted by Kano View Post
                        noueveau might be able to do, but never tried.
                        I am disappoint. http://nouveau.freedesktop.org/wiki/GalliumHowto states, in a nutshell, that nouveau's Gallium code is broken, in heavy development, experimental, and does not accept bug reports.

                        As far as I know, the most advanced thing that works decently correctly with nouveau is xmoto.

                        Comment


                        • #27
                          Originally posted by bridgman View Post
                          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.
                          That sounds like a pretty cool state to be in.

                          I guess anyone with GDB debugging experience could start hammer on those bugs without knowing anything about graphics?

                          Comment


                          • #28
                            3D is great, but I would settle for some good 2D. Neither the fglrx driver or the radeonhd driver give usable performance in 2D yet. I have little hope for fglrx, even the catalyst driver for Windows is terrible. Try dragging a window around with show contents turned on, it's slower than it was a decade ago!

                            Still it is nice to hear things are progressing, hopefully I will be able to use my shiny new video card someday. For now, I wonder if we are overselling how well these things work. If anyone is considering buying one of the newer ATI cards for anything besides games, they are crazy.

                            Comment


                            • #29
                              Originally posted by torham View Post
                              3D is great, but I would settle for some good 2D. Neither the fglrx driver or the radeonhd driver give usable performance in 2D yet. I have little hope for fglrx, even the catalyst driver for Windows is terrible. Try dragging a window around with show contents turned on, it's slower than it was a decade ago!

                              Still it is nice to hear things are progressing, hopefully I will be able to use my shiny new video card someday. For now, I wonder if we are overselling how well these things work. If anyone is considering buying one of the newer ATI cards for anything besides games, they are crazy.
                              What hard- and software do you use? 2D acceleration should be very fast with the open source stack.

                              Comment


                              • #30
                                Originally posted by d2kx View Post
                                What hard- and software do you use? 2D acceleration should be very fast with the open source stack.
                                It's a 4850, I'm using Debian's packages, tried both the radeon and the radeonhd drivers, with DRI on and both EXA and XAA.

                                xserver-xorg 1:7.4+3
                                xserver-xorg-video-radeon 1:6.12.2-2
                                xserver-xorg-video-radeonhd 1.2.5-1
                                linux-image-2.6.30-1-686 2.6.30-1

                                Comment

                                Working...
                                X