Announcement

Collapse
No announcement yet.

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

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

  • #31
    Originally posted by torham View Post
    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
    Do note that there is no XAA for r6xx/r7xx cards, only EXA.

    Comment


    • #32
      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!
      torham, can you please start another thread and pastebin your xorg log, conf and dmesg output ? It sounds as if acceleration isn't enabled on your system for some reason.

      As a quick check, see if xvinfo finds textured video adapters.

      Comment


      • #33
        Originally posted by Louise View Post
        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?
        Yes, more or less. In addition, there is a programming guide, shader ISA documentation, and register specs available for download:
        http://www.x.org/docs/AMD/
        So with GDB and specs you can get a general idea of what's going on in the mesa code by just tracing the code. The redbook demos are very simple.

        Comment


        • #34
          Sooo, pretty soon I'll have a 100% open source OS, including WiFi.

          Coolness.

          On fglrx: Seems to all work fine for me, except maximizing windows with compiz has a 1-2 second lag on it (so I turn compiz off, 'ray)

          System:

          Phenom II X3 720 BE
          Biostar TA790GX AM2+ board
          4GiB DD2-533
          Integrated Radeon 3300
          1440 x 900 monitor
          3 x 500GiB HDD
          Ubuntu 9.04 32bit.

          Don't know why maximizing windows has such bad latency, everything else is pretty sharp.

          bridgman: You're the man now, dog!

          Regards,

          J1M.

          Comment


          • #35
            Originally posted by torham View Post
            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
            Debian has removed the firmware out of the Linux kernel since 2.6.30. I assume you are using Debian/sid. Try installing the "firmware-linux" package and reboot.

            Comment


            • #36
              Originally posted by RoboJ1M View Post
              Sooo, pretty soon I'll have a 100% open source OS, including WiFi.

              Coolness.

              On fglrx: Seems to all work fine for me, except maximizing windows with compiz has a 1-2 second lag on it (so I turn compiz off, 'ray)

              System:

              Phenom II X3 720 BE
              Biostar TA790GX AM2+ board
              4GiB DD2-533
              Integrated Radeon 3300
              1440 x 900 monitor
              3 x 500GiB HDD
              Ubuntu 9.04 32bit.

              Don't know why maximizing windows has such bad latency, everything else is pretty sharp.

              bridgman: You're the man now, dog!

              Regards,

              J1M.
              I have a 1-2 second lag with unminimization in gnome, as in: minimize a window, then focus on it again. Maximization and restoring works fine here. Happens only when using compositing (in gnome I use compiz as compositing window manager).

              The funny thing is, I also get that lag when using KDE's KWin. when I enable the KWin plugin for performance tracking, a clear spike to the maximum of the scale is noticeable (I assume that cpu usage is being tracked).

              It's a damn shame too, because this means that the fault lies with fglrx. I think that if this issue were to be fixed in Catalyst 9.6 that it certainly would make the wait for FOSS radeon(hd) 3D support for the R600/R700 cards a bit less painful.

              Comment


              • #37
                The delay resulted from an xserver patch being backed out to fix a corruption issue on Intel HW AFAIK - reapplying the patch seems to make the delay go away. My understanding is that this is an xserver issue not a driver issue; you hear similar complaints from people with different hardware and drivers as well.
                Last edited by bridgman; 07-06-2009, 10:16 AM.

                Comment


                • #38
                  Originally posted by bridgman View Post
                  My understanding is that this is an xserver issue not a driver issue; you hear similar complaints from people with different hardware and drivers as well.
                  But then why does it not happen with radeon/radeonhd/intel? The thing that surprised me the most when switching from fglrx to radeon was the great performance with composite. That includes resizing/maximizing (no noticeable lag).

                  Comment


                  • #39
                    The reports I have seen indicated a similar delay with the open source driver when running compositing. All the reports saying there was no delay with the open source drivers were on 6xx/7xx where the lack of 3D support prevents the use of GL-based compositing.

                    I have also seen a number of posts from Intel users discussing the tradeoffs associated with the patch; screen corruption vs delays.

                    Are you seeing something different, and if so which GPU are you using ?

                    Comment


                    • #40
                      Originally posted by bridgman View Post
                      The reports I have seen indicated a similar delay with the open source driver when running compositing
                      When I had a R500 about a year ago, the maximise delay did not happen with OSS drivers + compiz if EXA was enabled. It did happen with OSS + compiz if XAA was used.

                      Comment


                      • #41
                        Using the open drivers in Jaunty with a 200M you can notice a slight delay with Compiz while maximizing/minimizing. Kwin is not that bad, but you can indeed notice some lag when maximizing/minimizing as well. Using xterm with the open drivers is smooth as silk however, whereas with fglrx its simply painful; Metacity takes at least 3 seconds to update, and Kwin bogs down to a crawl.

                        Comment


                        • #42
                          @all people experiencing slow Composite performance (like with maximizing/minimizing) with Ubuntu 9.04 (Gnome or KDE):

                          add this ppa repository to your APT sources and upgrade the Xserver to a fixed one:

                          Click me, I am of help!

                          Comment


                          • #43
                            Originally posted by bridgman View Post
                            Are you seeing something different, and if so which GPU are you using ?
                            Ah, ok. I have a HD3850. But I don't experience any delay with my integrated intel (G965).

                            Comment


                            • #44
                              Originally posted by d2kx View Post
                              @all people experiencing slow Composite performance (like with maximizing/minimizing) with Ubuntu 9.04 (Gnome or KDE):

                              add this ppa repository to your APT sources and upgrade the Xserver to a fixed one:

                              Click me, I am of help!

                              Yep, this works. Not only are the Compiz issues resolved, but the CCC no longer that +5 seconds to load.

                              Comment


                              • #45
                                Originally posted by Melcar View Post
                                Yep, this works. Not only are the Compiz issues resolved, but the CCC no longer that +5 seconds to load.
                                Indeed, I can confirm that the xserver from the PPA d2kx provided, works.
                                Running KDE 4.3 RC1 right now with compositing turned on, on a radeon HD4870 card.

                                @bridgman: I was indeed aware that the direct cause for this performance regression was the removal of a xorg patch. The reason, however, that I said the fault lay with catalyst is that I was (and still am, to be honest) under the impression that nvidia's blob reaches acceptable performance on their cards. If this incorrect, I apologise.

                                I do wonder, regardless of where the blame lies, about what can be so computationally intensive about unminimizing a window that, when a certain patch is removed from xorg, the performance for that functionality drops to a level where lag is noticeable.
                                The fact that this happens tells me that the performance for that operation wasn't too high to start with (although this doesn't HAVE to be the case, I guess that would also depend on the invasiveness of the xorg patch in question).
                                I assume the window has to be rendered again, but with modern gfx cards that shouldn't be an issue; it is what the hardware is built for

                                Comment

                                Working...
                                X