Announcement

Collapse
No announcement yet.

Open-Source 2D, 3D For ATI Radeon HD 5000 Series GPUs

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

  • #46
    Originally posted by psychok9 View Post
    [SNIP]
    I hope you not used the atombios-support branch. He is 3 Years old. You need evergreen_accel

    Comment


    • #47
      Originally posted by Nille View Post
      I hope you not used the atombios-support branch. He is 3 Years old. You need evergreen_accel
      Of course

      Seem very unstable, 1-2 mins and I got crash.
      Mouse cursor corrupted... I can move windows without get tearing!

      Comment


      • #48
        Originally posted by rohcQaH View Post
        git co evergreen_accel
        Code:
        /xf86-video-ati$ git co evergreen_accel
        git: 'co' is not a git command. See 'git --help'.
        What do you mean with "co"?

        Comment


        • #49
          Probably local alias for checkout. Used for changing active branch in git.

          Comment


          • #50
            Using today's git master of all Xorg libs, protos, server, mesa drm, and mesa/mesa. Linux 2.6.36-rc2-git3. Have a HD5970. Fully preemptible 1000 Hz. drm and radeon modules built-in to kernel.

            Boot-up takes an extremely long time to switch to the KMS framebuffer. On the dmesg I see:

            Code:
            [   62.288248] r600_cp: Failed to load firmware "radeon/CYPRESS_pfp.bin"
            [   62.288309] [drm:evergreen_startup] *ERROR* Failed to load firmware!
            [  123.205570] r600_cp: Failed to load firmware "radeon/CYPRESS_pfp.bin"
            [  123.205611] [drm:evergreen_startup] *ERROR* Failed to load firmware!
            [  123.205645] radeon 0000:05:00.0: disabling GPU acceleration
            [  123.206744] radeon 0000:05:00.0: ffff8801b653b400 unpin not necessary
            [  123.206769] radeon 0000:05:00.0: ffff8801b653b400 unpin not necessary
            [  123.206799] failed to evaluate ATIF got AE_BAD_PARAMETER
            Later on, in Xorg.0.log, I see

            Code:
            [   464.362] (II) RADEON(0): GPU accel disabled or not working, using shadowfb for KMS
            [   464.362] (II) Loading sub module "shadow"
            [   464.362] (II) LoadModule: "shadow"
            [   464.362] (II) Loading /usr/lib64/xorg/modules/libshadow.so
            [   464.368] (II) Module shadow: vendor="X.Org Foundation"
            [   464.545] (II) RADEON(1): GPU accel disabled or not working, using shadowfb for KMS
            [   464.545] (II) Loading sub module "shadow"
            [   464.545] (II) LoadModule: "shadow"
            [   464.546] (II) Reloading /usr/lib64/xorg/modules/libshadow.so
            I've therefore got no 3d accel, but 2d accel is nice and stable, and actually quite fast, even with the core set to its minimum clock frequency using the power management profiles. Verified:

            Code:
            # cat /sys/kernel/debug/dri/0/radeon_pm_info
            default engine clock: 725000 kHz
            current engine clock: 399990 kHz
            default memory clock: 1000000 kHz
            current memory clock: 1000000 kHz
            voltage: 1000 mV
            I've got both DVI outputs plugged into an LCD; could this be related to using dual monitors?

            FWIW, the firmware seemed to have worked with 2.6.35.3, but I was still stuck in software rendering. I had a lot of different variables there though, such as building drm and radeon as modules.

            Right now I'm going on 45 minutes running X without a crash, but since it's a shadowfb on top of KMS, this isn't very surprising; developers have presumably been testing this configuration for months while 2d/3d support was in the works.

            And yes I'm using evergreen_accel. No xorg.conf.

            Comment


            • #51
              Just changed my xrandr configuration from mirror (both monitors running at 1680x1050) to non-xinerama dual head (24" running at 1920x1200, 22" running at 1680x1050). Works like a charm.

              What the heck is this shadowfb doing providing such smooth 2d accel? It's not allowed to be faster than fglrx! :P

              Now if only I could get DRI2 to work... I guess I need to get the firmware working first, don't I.

              Comment


              • #52
                Originally posted by allquixotic View Post
                What the heck is this shadowfb doing providing such smooth 2d accel? It's not allowed to be faster than fglrx! :P
                Well the point is that shadowfb is doing almost nothing; only blitting and drawing some shit on RAM and then sending it happily to the framebuffer.

                Now if you'd be doing more than just this crap it would be more efficient per time to send it all over tot the graphics card, which takes time, and let the GPU handle all that stuff.

                Comment


                • #53
                  OK, I got the firmware to load. I guess that the firmware got excluded from the built-in kernel somehow, because it was trying to bring up the radeon driver before the ext4 was initialized... I made drm and radeon build as modules, and the firmware loads.

                  However, I'm still stuck with the shadowfb, and I see no indication why in terms of the kernel. It would appear that the kernel is operating correctly.

                  So then the userspace somehow is acting up. I'll ask on #radeon.

                  Comment


                  • #54
                    Originally posted by V!NCENT View Post
                    Well the point is that shadowfb is doing almost nothing; only blitting and drawing some shit on RAM and then sending it happily to the framebuffer.

                    Now if you'd be doing more than just this crap it would be more efficient per time to send it all over tot the graphics card, which takes time, and let the GPU handle all that stuff.
                    Kindof. The CPU has much less latency to system RAM than it does to gfx card RAM - so there's less latency for the CPU to rasterise graphics to main memory than to send the command to the GPU. The GPU can draw much faster once it's recieved the commands..

                    Anyway, this means that for small writes(such as drawing an icon) the CPU can probably perform that operation in system RAM in less time than it would take to send that task to the GPU. Large tasks, (drawing large areas, and with complex shaders) the GPU's much higher speed at these tasks will more than compensate.

                    In cairo benchmarks, the evergreen_accel gets at best half what my CPU does in shadowfb mode. I expect this will improve a bit once the drivers get beaten on a bit more.

                    Comment


                    • #55
                      A few things:

                      1. I got out of shadowfb mode. Turns out I was being stupid and didn't really have the evergreen_accel branch compiling. I had to rerun autogen.sh to get configure to generate Makefiles that included the evergreen translation units. Grr.

                      2. Gnome/compiz compositing crashes when you minimize windows, but Kwin doesn't if you tell it to always keep thumbnails in the control center (it's the option that says "Breaks minimization"). Probably some issue related to evicting EXA pixmaps out of VRAM and into (?) system RAM when they are minimized. IMHO this is unnecessary on cards with as much VRAM as mine (1892 MB); more effort should be made to actually use the VRAM that is available. But that is neither here nor there.

                      3. Workaround for corrupt mouse cursor:
                      Edit your xorg.conf, under the Driver "radeon" section, and add
                      Code:
                      Option "RenderAccel" "off"
                      This will give you a working mouse cursor, but obviously anything that uses the XRender extension will either be very slow, or won't work. Mouse cursor performance seems unaffected, as it's still using a hardware cursor.

                      So now I've got EXA and a compositing manager that is relatively stable on top of a HD5970. I'd still like to see the driver stabilize, but the basic tech is visibly starting to work.

                      Comment


                      • #56
                        Originally posted by allquixotic View Post
                        Just changed my xrandr configuration from mirror (both monitors running at 1680x1050) to non-xinerama dual head (24" running at 1920x1200, 22" running at 1680x1050). Works like a charm.

                        What the heck is this shadowfb doing providing such smooth 2d accel? It's not allowed to be faster than fglrx! :P

                        Now if only I could get DRI2 to work... I guess I need to get the firmware working first, don't I.

                        "It's not allowed to be faster than fglrx! :P"

                        sure shadowFB it is faster than the fglrx ;-)

                        Exempel: my last try to install a 10-8 catalyst:

                        Package build failed!
                        Package build utility output:
                        ./packages/Ubuntu/ati-packager.sh: 385: dpkg-buildpackage: not found
                        [Error] Generate Package - error generating package : Ubuntu/lucid

                        Comment


                        • #57
                          I've done some more detailed test in addition to my last post.

                          radeon, today's git:
                          mesa reverted to 7.8.2, export LIBGL_ALWAYS_SOFTWARE=1
                          • glxgears works without corruption
                          • xv doesn't work at all, there's nothing but slight colourful flickering in the whole window
                          • screenshots I take (both ksnapshot and import -window root file.png) are still corrupted (see last post for an example)
                          • kde3 still has the same corruption as before, it's not related to mesa (kde3 doesn't use opengl much, anyway)

                          same as before, but added to my xorg.conf: Option "RenderAccel" "off":
                          • no changes with glxgears and xv
                          • screenshots I take with import are still corrupted, ksnapshot started to work though.
                          • corruption in kde3 is gone, even with composition (it's not opengl-based, anyway)
                          • more extensive tests revealed corruption in Seamonkey, but not in firefox or other GTK-apps I tested
                          • flash (firefox) worked right until I clicked the "fullscreen" button, let's blame flash for that

                          If I had to take a wild guess, reading from the framebuffer is broken in some way. Not just because of the screenshots, but also because most pseudo-transparency effects (yakuake, crystal window decorations) are corrupted.
                          On the other hand, compositing and true transparency effect work fine, so vram->vram blits appear to work.
                          The mouse pointer and some icons are displayed wrong, too. The corruption looks similar to the screenshot/transparency bugs, so it may or may not have the same root cause.


                          xv worked fine last week (until x crashed), should I try to bisect?

                          reinstalled mesa master (today), enabled hardware 3d.
                          • xv still broken
                          • glxgears still messes with parts of the video memory it shouldn't mess with, resulting in corruption in the form of horizontal lines (not neccessarily in the framebuffer, but this time in my wallpaper's pixmap).
                            With RenderAccel off, glxgears appeared to work fine, save for some horizontal red lines that appeared in glxgear's window from time to time.
                          • neverball still doesn't start with r600 (as mentioned in my last post)
                          • kde 4.5: seems to work fine with compositing disabled, had corruption with XRender compositing (even with RenderAccel off), kwin4 crashes immediately when opengl compositing is active, each time this appears in dmesg:
                            Code:
                            [ 3877.649234] radeon 0000:02:00.0: forbidden register 0x00009508 at 10
                            [ 3877.649237] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !

                          in other words, as far as I'm concerned, r600's status is "glxgears barely works" :/

                          Comment


                          • #58
                            Originally posted by rohcQaH View Post
                            I've done some more detailed test in addition to my last post.

                            radeon, today's git:
                            mesa reverted to 7.8.2, export LIBGL_ALWAYS_SOFTWARE=1
                            • glxgears works without corruption
                            • xv doesn't work at all, there's nothing but slight colourful flickering in the whole window
                            • screenshots I take (both ksnapshot and import -window root file.png) are still corrupted (see last post for an example)
                            • kde3 still has the same corruption as before, it's not related to mesa (kde3 doesn't use opengl much, anyway)

                            same as before, but added to my xorg.conf: Option "RenderAccel" "off":
                            • no changes with glxgears and xv
                            • screenshots I take with import are still corrupted, ksnapshot started to work though.
                            • corruption in kde3 is gone, even with composition (it's not opengl-based, anyway)
                            • more extensive tests revealed corruption in Seamonkey, but not in firefox or other GTK-apps I tested
                            • flash (firefox) worked right until I clicked the "fullscreen" button, let's blame flash for that

                            If I had to take a wild guess, reading from the framebuffer is broken in some way. Not just because of the screenshots, but also because most pseudo-transparency effects (yakuake, crystal window decorations) are corrupted.
                            On the other hand, compositing and true transparency effect work fine, so vram->vram blits appear to work.
                            The mouse pointer and some icons are displayed wrong, too. The corruption looks similar to the screenshot/transparency bugs, so it may or may not have the same root cause.


                            xv worked fine last week (until x crashed), should I try to bisect?

                            reinstalled mesa master (today), enabled hardware 3d.
                            • xv still broken
                            • glxgears still messes with parts of the video memory it shouldn't mess with, resulting in corruption in the form of horizontal lines (not neccessarily in the framebuffer, but this time in my wallpaper's pixmap).
                              With RenderAccel off, glxgears appeared to work fine, save for some horizontal red lines that appeared in glxgear's window from time to time.
                            • neverball still doesn't start with r600 (as mentioned in my last post)
                            • kde 4.5: seems to work fine with compositing disabled, had corruption with XRender compositing (even with RenderAccel off), kwin4 crashes immediately when opengl compositing is active, each time this appears in dmesg:
                              Code:
                              [ 3877.649234] radeon 0000:02:00.0: forbidden register 0x00009508 at 10
                              [ 3877.649237] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !

                            in other words, as far as I'm concerned, r600's status is "glxgears barely works" :/
                            It needs a lot of work still. I may be seeing bugs in unrelated components like the kernel or the X server, but I can't even get the driver to load up DRI2 today. It just falls back to software without any explanation as to why.

                            Comment


                            • #59
                              Very much sounds like your kernel and Mesa aren't compatible with each other. "forbidden register" is a good hint of this. There's security functionality in kernel DRM, afaik mostly written by glisse, that causes that kind of stuff to be outputted. If the register should be usable, updating kernel might fix it. If not, updating Mesa might fix it. But since you don't know, could as well update both.

                              Comment


                              • #60
                                I was using the latest mesa git and the latest stable kernel (2.6.35). It's supposed to work with .35, so I don't want to risk further trouble by using a .36-RC-kernel.

                                Besides, the trouble in 2d-land certainly isn't related to mesa.

                                Comment

                                Working...
                                X