Announcement

Collapse
No announcement yet.

ATI R600/700 OSS 3D Driver Reaches Gears Milestone

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

  • Originally posted by bridgman View Post
    Can you pastebin your dmesg output ?
    Sorry, I was editing like crazy. You probably missed my edit where I found the problem. It's working now, and I'm back to 24fps on glxgears.

    Also Kwin using OpenGL crashed KDE instead of just telling me that it can't be enabled.

    Comment


    • I had success installing those new drivers on debian testing with the 2.6.30 kernel and xorg 7.4 from unstable.
      Had a few troubles. Yesterday I started with the 2D part and followed this howto

      https://help.ubuntu.com/community/RadeonHD

      I skipped the linux modules part and used the modulles coming with the kernel. To finaly get it working I had to install a package called "firmware-linux".

      Today I followed this howto http://www.x.org/wiki/radeonhd%3Aexperimental_3D to get 3D stuff working.
      I had to move the drm.ko and radoeon.ko module manualy from /lib/modules/2.6.30-1-amd64/extra to /lib/modules/2.6.30-1-amd64/kernel/drivers/gpu/drm.
      The mesa build mooaned about missing RADEON_TILING_MACRO and RADEON_TILING_MICRO. I searched the web and found a few patches adding those defines to /usr/include/drm/radeaon_drm.h. Those defines where missing in the git version I had installed so i went ahead and added those lines to /usr/include/drm/radeon_drm.h

      Code:
      #define RADEON_TILING_MACRO 0x1
      #define RADEON_TILING_MICRO 0x2
      #define RADEON_TILING_SWAP  0x4
      #define RADEON_TILING_SURFACE  0x8
      Afterwards the build ran fine. In addition to the howto I had to rebuild xf86-video-radeonhd.

      The card is unknown (HD3300 on 790GX an mobo) but working
      Code:
      (**) RADEONHD(0): Option "DRI"
      (**) RADEONHD(0): Selected EXA 2D acceleration.
      (II) RADEONHD(0): Unknown card detected: 0x9614:0x1002:0x0000.
              If - and only if - your card does not work or does not work optimally
              please contact [email protected] to help rectify this.
              Use the subject: 0x9614:0x1002:0x0000: <name of board>
              and *please* describe the problems you are seeing
              in your message.
      (--) RADEONHD(0): Detected an RS780 on an unidentified card
      (II) RADEONHD(0): Mapped IO @ 0xfeaf0000 to 0x7fa4546ca000 (size 0x00010000)
      (II) RADEONHD(0): Getting BIOS copy from legacy VBIOS location
      (II) RADEONHD(0): ATOM BIOS Rom:
              SubsystemVendorID: 0x1002 SubsystemID: 0x1002
              IOBaseAddress: 0xd000
              Filename: 13B27721.025
              BIOS Bootup Message:
      113-B27721-025 RS780 DDR2 200e/500m

      Detected voltages for power management look abit scary.
      Code:
      (II) RADEONHD(0): FirmwareInfo Revision 0104
      (II) RADEONHD(0): Unused attribute: ul3DAccelerationEngineClock 0
      (II) RADEONHD(0): Unused attribute: ulDriverTargetEngineClock 0
      (II) RADEONHD(0): Unused attribute: ulDriverTargetMemoryClock 0
      (II) RADEONHD(0): Unused attribute: ucASICMaxTemperature 0
      (II) RADEONHD(0): Scary bits: Estimated MinEngineClock 250000 kHz
      (II) RADEONHD(0): Scary bits: Estimated MinMemoryClock 250000 kHz
      (II) RADEONHD(0): Default Engine Clock: 700000
      (II) RADEONHD(0): Default Memory Clock: 400000
      (II) RADEONHD(0): Current Engine Clock: 694520
      (EE) RADEONHD(0): AtomBIOS command table 47 does not exist
      (II) RADEONHD(0): Query for AtomBIOS Exec: not implemented
      (WW) RADEONHD(0): Unusupported SetVoltage Revision
      (II) RADEONHD(0): Power Management: used engine clock / memory clock / core (VDDC) voltage   (0: ignore)
      (II) RADEONHD(0): Power Management: Raw Ranges
      (II) RADEONHD(0):   Minimum    250000 kHz /   250000 kHz /  0.000 V
      (II) RADEONHD(0):   Maximum         0 kHz /        0 kHz /  0.000 V
      (II) RADEONHD(0):   Default    700000 kHz /   400000 kHz /  0.000 V
      (II) RADEONHD(0): PowerPlayInfo Revision 0401
      (II) RADEONHD(0): Power Management: Validated Ranges
      (II) RADEONHD(0):   Minimum    250000 kHz /   250000 kHz /  0.000 V
      (II) RADEONHD(0):   Maximum    700000 kHz / 128000000 kHz / 28.672 V
      (II) RADEONHD(0):   Default    700000 kHz /   400000 kHz /  0.000 V
      (II) RADEONHD(0): Power Management: Known Good Configurations
      (II) RADEONHD(0):   1          300000 kHz /   300000 kHz /  0.000 V
      (II) RADEONHD(0):   2               0 kHz / 128000000 kHz / 28.672 V
      (II) RADEONHD(0): Power Management: Final Levels
      (II) RADEONHD(0):   Off        250000 kHz /   250000 kHz /  0.000 V
      (II) RADEONHD(0):   Idle       350000 kHz /   400000 kHz /  0.000 V
      (II) RADEONHD(0):   Slow2D     700000 kHz /   400000 kHz /  0.000 V
      (II) RADEONHD(0):   Fast2D     700000 kHz /   400000 kHz /  0.000 V
      (II) RADEONHD(0):   Slow3D     700000 kHz /   400000 kHz /  0.000 V
      (II) RADEONHD(0):   Fast3D     700000 kHz /   400000 kHz /  0.000 V
      (II) RADEONHD(0):   Max3D      700000 kHz / 128000000 kHz / 28.672 V
      (II) RADEONHD(0):   User       700000 kHz /   400000 kHz /  0.000 V

      Comment


      • Please disregard the bit of advice that I put here a few minutes ago. Devs are looking into the problem.
        Last edited by nanonyme; 08-07-2009, 02:46 PM.

        Comment


        • Originally posted by nanonyme View Post
          Please disregard the bit of advice that I put here a few minutes ago. Devs are looking into the problem.
          Had already tried your tip. radeon_drm.h from freedesktop seem to be even older.
          This was the patch I found those lines I added to drm/linux-core/radeon_drm.h.
          http://www.mail-archive.com/dri-deve.../msg41244.html

          Mesa DRI works fine and I get ~24fps with glxgears. Power management also seems to work X.Org.log says the card is running at 350MHz (default 700MHz). Is there a tool to monitor/verify the current frequency the chip is running at?

          Comment


          • Just thought to remind to remove the hack you had. agd5f fixed the problem a while ago (the fix belonged to Mesa, not libdrm) and it might be the workaround you had might lead into more compilation errors unless removed. (I'm not sure how much the preprocessor likes two defines for the same name, might error out)

            Comment


            • Originally posted by nanonyme View Post
              Just thought to remind to remove the hack you had. agd5f fixed the problem a while ago (the fix belonged to Mesa, not libdrm) and it might be the workaround you had might lead into more compilation errors unless removed. (I'm not sure how much the preprocessor likes two defines for the same name, might error out)
              Yepp, seen it already and now mesa builds without the radeon_drm.h modifications. Thanks for the fix agd5f.

              Comment


              • I suppose this is not really usable yet? (With "usable" meaning low temperatures so my card won't fry, fast KDE 4 and HD video.)

                Comment


                • No.

                  But he, it's still an important milestone !

                  Comment


                  • When I try to enable kde 4.3's desktop effects here the system freezes immediate. Then after a reboot I can login via kdm and then the system froze again during desktop load. I heared the startup sound, the taskbar and desktop stuff got displayed.
                    In the syslog I find those entries.

                    Code:
                    [drm] wait for fifo failed status : 0xE47034E0 0x00110103
                    Update: If I disable all effects manual it works in opengl and xrandr mode. Things like preview images on the taskbar work but things like sliding during workspace change run very slow in both modes.
                    Last edited by justapost; 08-08-2009, 07:32 AM.

                    Comment


                    • We reached the point last week some time where the slow back-to-front copies were starting to be an obstacle for further testing, so agd5f is working on accelerating that now. That should get rid of all the "too slow" failures and will probably help with some overflow-related problems as well.

                      That just leaves the intermittent geometry corruption, which I expect is going to be a real pain to troubleshoot but easy to fix once the problem is understood, plus some regressions over the last couple of weeks (eg etracer).

                      Comment

                      Working...
                      X