Announcement

Collapse
No announcement yet.

how to get XV, DRI working on HD 3300 (rv620) ??

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

  • how to get XV, DRI working on HD 3300 (rv620) ??

    The last 2 days I unsuccessfully tried to get XV working on my ASRock AOD790GX. Graphics card is an onboard Radeon HD3300, which seems to be the same rv620 chipset as the Radeon HD3450.

    After doing research I ended up using the r6xx-r7xx-branch from the radeonhd git repository. I followed the instructions on http://xorg.freedesktop.org/wiki/rad...xx_r7xx_branch but still no success...

    One problem seems that the drm-module doesn't recognize my Radeon HD 3300. I used the r6xx_r7xx_branch from the drm git too. Or is it possible to run XV without relying on DRM?

    The drm-failure from my Xorg.0.log:
    Code:
    (WW) RADEONHD(0): Direct rendering for R600 and up forced on - This is NOT officially supported yet and may cause instability or lockups
    (II) RADEONHD(0): Found libdri 5.4.0.
    drmOpenDevice: node name is /dev/dri/card0
    drmOpenDevice: open result is -1, (No such device)
    drmOpenDevice: open result is -1, (No such device)
    drmOpenDevice: Open failed
    drmOpenByBusid: Searching for BusID pci:0000:01:05.0
    drmOpenDevice: node name is /dev/dri/card0
    drmOpenDevice: open result is -1, (No such device)
    drmOpenDevice: open result is -1, (No such device)
    drmOpenDevice: Open failed
    drmOpenByBusid: drmOpenMinor returns -19
    drmOpenDevice: node name is /dev/dri/card1
    drmOpenDevice: open result is -1, (No such device)
    drmOpenDevice: open result is -1, (No such device)
    drmOpenDevice: Open failed
    
    [...]
    
    drmOpenByBusid: drmOpenMinor returns -19
    drmOpenDevice: node name is /dev/dri/card14
    drmOpenDevice: open result is -1, (No such device)
    drmOpenDevice: open result is -1, (No such device)
    drmOpenDevice: Open failed
    drmOpenByBusid: drmOpenMinor returns -19
    drmOpenDevice: node name is /dev/dri/card0
    drmOpenDevice: open result is -1, (No such device)
    drmOpenDevice: open result is -1, (No such device)
    drmOpenDevice: Open failed
    drmOpenDevice: node name is /dev/dri/card0
    drmOpenDevice: open result is -1, (No such device)
    drmOpenDevice: open result is -1, (No such device)
    drmOpenDevice: Open failed
    drmOpenDevice: node name is /dev/dri/card1
    drmOpenDevice: open result is -1, (No such device)
    drmOpenDevice: open result is -1, (No such device)
    drmOpenDevice: Open failed
    
    [...]
    
    drmOpenDevice: node name is /dev/dri/card14
    drmOpenDevice: open result is -1, (No such device)
    drmOpenDevice: open result is -1, (No such device)
    drmOpenDevice: Open failed
    (EE) RADEONHD(0): RHDDRIVersionCheck: drmOpen("radeon", "pci:0000:01:05.0") failed.
    (WW) RADEONHD(0): RHDDRIPreInit: Version check failed. Disabling DRI.
    The more successful part oy my Xorg.0.log:
    Code:
    (II) Loading /usr/lib64/xorg/modules//libexa.so
    (II) Module exa: vendor="X.Org Foundation"
    	compiled for 1.5.2, module version = 2.4.0
    	ABI class: X.Org Video Driver, version 4.1
    (II) RADEONHD(0): FB: Allocated Offscreen Buffer at offset 0x006F4000 (size = 0x00CCC000)
    (--) Depth 24 pixmap format is 32 bpp
    (II) do I need RAC?  No, I don't.
    (II) resource ranges after preInit:
    	[0] -1	0	0xffffffff - 0xffffffff (0x1) MX[B]
    	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
    	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
    	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
    	[4] -1	0	0xffffffff - 0xffffffff (0x1) MX[B]
    	[5] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
    	[6] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
    	[7] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
    	[8] -1	0	0xffffffff - 0xffffffff (0x1) MX[B]
    	[9] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
    	[10] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
    	[11] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
    	[12] -1	0	0xffffffff - 0xffffffff (0x1) MX[B]
    	[13] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
    	[14] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
    	[15] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
    	[16] -1	0	0xffffffff - 0xffffffff (0x1) MX[B]
    	[17] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
    	[18] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
    	[19] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
    	[20] 0	0	0x000a0000 - 0x000affff (0x10000) MS[B]
    	[21] 0	0	0x000b0000 - 0x000b7fff (0x8000) MS[B]
    	[22] 0	0	0x000b8000 - 0x000bffff (0x8000) MS[B]
    	[23] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
    	[24] -1	0	0x00000000 - 0x00000000 (0x1) IX[B]
    	[25] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
    	[26] -1	0	0x00000000 - 0x00000000 (0x1) IX[B]
    	[27] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
    	[28] -1	0	0x00000000 - 0x00000000 (0x1) IX[B]
    	[29] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
    	[30] -1	0	0x00000000 - 0x00000000 (0x1) IX[B]
    	[31] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
    	[32] -1	0	0x00000000 - 0x00000000 (0x1) IX[B]
    	[33] 0	0	0x000003b0 - 0x000003bb (0xc) IS[B]
    	[34] 0	0	0x000003c0 - 0x000003df (0x20) IS[B]
    (II) RADEONHD(0): Mapped IO @ 0xfeaf0000 to 0x7f68e0b30000 (size 0x00010000)
    (II) RADEONHD(0): Mapped FB @ 0xf0000000 to 0x7f68d4aa6000 (size 0x08000000)
    (WW) RADEONHD(0): RHDCSInit: No CS for R600 and up yet.
    (==) RADEONHD(0): Backing store disabled
    (==) RADEONHD(0): Silken mouse enabled
    (II) RADEONHD(0): RandR 1.2 enabled, ignore the following RandR disabled message.
    (II) RADEONHD(0): Mapping DIG2 encoder to KLDSKP_LVTMA
    (II) RADEONHD(0): On Crtc 0 Setting 59.9 Hz Mode: Modeline "1680x1050"  119.00  1680 1728 1760 1840  1050 1053 1059 1080 +hsync +vsync
    None
    (II) RADEONHD(0): RHDAudioSetClock: using UNIPHY_KLDSKP_LVTMA as clock source with 119000 khz
    (II) RADEONHD(0): Using ACR timing N=4096 CTS=119000 for frequency 32000
    (II) RADEONHD(0): Using ACR timing N=6272 CTS=132222 for frequency 44100
    (II) RADEONHD(0): Using ACR timing N=6144 CTS=119000 for frequency 48000
    (II) RADEONHD(0): RHDAudioSetSupported: config 0x60040 codec 0x1
    (II) RADEONHD(0): DPMS enabled
    (--) RandR disabled
    (II) Setting vga for screen 0.
    (II) Initializing built-in extension MIT-SHM
    (II) Initializing built-in extension XInputExtension
    (II) Initializing built-in extension XTEST
    (II) Initializing built-in extension XKEYBOARD
    (II) Initializing built-in extension XINERAMA
    (II) Initializing built-in extension XFIXES
    (II) Initializing built-in extension RENDER
    (II) Initializing built-in extension RANDR
    (II) Initializing built-in extension COMPOSITE
    (II) Initializing built-in extension DAMAGE
    (II) Initializing built-in extension XEVIE
    (II) AIGLX: Loaded and initialized /usr/lib64/dri/swrast_dri.so
    (II) GLX: Initialized DRISWRAST GL provider for screen 0
    (II) RADEONHD(0): Setting screen physical size to 473 x 296
    I am running a gentoo system with xorg 7.4 (xorg-server-1.5.2) and gentoo-kernel 2.6.27.

    Any ideas what to do next?

  • #2
    Can you pastebin the kernel messages (dmesg) ? The most common problem I see is people building the 6xx-7xx drm branch but not getting the new drm successfully installed... so they're still running the old drm which does not support their hardware.

    You also might want to hop onto the #radeonhd IRC channel; there's usually a few people online there who just finished installing the 6xx-7xx code so probably have gone through some of the same issues.
    Last edited by bridgman; 01 February 2009, 07:33 PM.
    Test signature

    Comment


    • #3
      Originally posted by bridgman View Post
      Can you pastebin the kernel messages (dmesg) ? The most common problem I see is people building the 6xx-7xx drm branch but not getting the new drm successfully installed... so they're still running the old drm which does not support their hardware.

      You also might want to hop onto the #radeonhd IRC channel; there's usually a few people online there who just finished installing the 6xx-7xx code so probably have gone through some of the same issues.
      Thanks for the fast reply maen!

      Here's the dmesg output:


      And the complete Xorg.0.log:

      Comment


      • #4
        Hi as I have some similar problem I want to ask here.

        I have hd3200 igp. I am running OpenSuse 11.1 and Kde 4.2. I followed the same wiki as @schwarzygesetzlos. I get both drm module and radeonhd driver compiled and working as there is no error messages in xorg.conf log. But my problem is my desktop completely corrupted. Icons, colors, texts, menus, even desktop wallpaper is rendered wrong and full of garbage. I use EXA and DRI options enabled in xorg.conf. And It is beyond some corruptions, it is very very slow. Windows painted in 3-5 seconds. Scroling is like slide show

        Is this the r6xx-r7xx branch real state or I do something wrong. All I want is fast 2d and XV.

        Comment


        • #5
          That sounds like the branch's real state but (a) that state is MUCH better than it was a week ago (much more reliable on hd3200, more functions accelerated, less corruption) (b) there are things you can do to improve your experience with the current code and (c) the amount of corruption varies from user to user and your corruption sounds worse than what some folks are seeing (but probably not the worst).

          The corruption problems seem to happen in the EXA Composite function (aka EXA Render) and the slowness of scrolling and moving is because we're using an extremely basic algorithm for blitting with overlapped source and destination, and don't want to get into optimizing until all the sources of corruption have been fixed.

          So...you have two different options :

          1. Turn off the acceleration of EXA composite to remove the corruption, by adding Option "OXANoComposite" "true" to your xorg.conf. That should get rid of the corruption but leave the slow. If EXANoComposite option is not enough you can apparently switch acceleration to XAA which (I'm told by a user) removes 2D acceleration but keeps Xv.

          2. Keep EXA Composite turned on, but get some benefit from it by enabling desktop composition in KWin. This will still have the corruption but should improve performance quite a bit. There's an option in KWin, possibly under Desktop Effectts, where you can choose the kind of acceleration used by the compositor - you want to pick "XRender" *NOT* OpenGL. The last user to try this mentioned that there were places you needed to pick "All"; let us know what you find.

          Anyways, either of these approaches should improve things noticeably. Before you ask, no I don't think you can use the two options together

          Let us know how it works.
          Test signature

          Comment


          • #6
            Originally posted by bridgman View Post
            That sounds like the branch's real state but (a) that state is MUCH better than it was a week ago (much more reliable on hd3200, more functions accelerated, less corruption) (b) there are things you can do to improve your experience with the current code and (c) the amount of corruption varies from user to user and your corruption sounds worse than what some folks are seeing (but probably not the worst).

            The corruption problems seem to happen in the EXA Composite function (aka EXA Render) and the slowness of scrolling and moving is because we're using an extremely basic algorithm for blitting with overlapped source and destination, and don't want to get into optimizing until all the sources of corruption have been fixed.

            So...you have two different options :

            1. Turn off the acceleration of EXA composite to remove the corruption, by adding Option "OXANoComposite" "true" to your xorg.conf. That should get rid of the corruption but leave the slow. If EXANoComposite option is not enough you can apparently switch acceleration to XAA which (I'm told by a user) removes 2D acceleration but keeps Xv.

            2. Keep EXA Composite turned on, but get some benefit from it by enabling desktop composition in KWin. This will still have the corruption but should improve performance quite a bit. There's an option in KWin, possibly under Desktop Effectts, where you can choose the kind of acceleration used by the compositor - you want to pick "XRender" *NOT* OpenGL. The last user to try this mentioned that there were places you needed to pick "All"; let us know what you find.

            Anyways, either of these approaches should improve things noticeably. Before you ask, no I don't think you can use the two options together

            Let us know how it works.
            Thanks for your advice. For your 1. approach, I have no time now to test it but I will test and feedback soon.

            For the second one: No, no, no kwin can't enable Desktop Effects neither in Opengl nor Xrender options. I don't know why it can't. I should add this that glxgears run smooth even it runs teribly slow at 200 fps. I should add this too: I don't think there should be worse situation Because poor KWIN can't even renders the wallpaper and just renders its naked white&grey boxed bacground

            I can Attach xorg.conf log if it is necessary.


            Anyways thanks for your advice.

            Comment


            • #7
              Originally posted by rahman.duran View Post
              Because poor KWIN can't even renders the wallpaper and just renders its naked white&grey boxed bacground
              I get the very same with the current git - So it's the state of branch just now.
              But still this is much better than a while a go. Then it just froze the box

              Maybe we'll try again after some new commits ..

              Comment


              • #8
                Originally posted by PWMx View Post
                I get the very same with the current git - So it's the state of branch just now.
                But still this is much better than a while a go. Then it just froze the box

                Maybe we'll try again after some new commits ..
                Yep, me to I also wish that I have the in-depth knowlage of C language
                and driver developing skill. Then I should just rollover my sleeves and get my hand dirty Waiting is just boring an annoying. Unfortunately, I am a Java developer without these knowlage

                Comment


                • #9
                  Originally posted by bridgman View Post
                  Can you pastebin the kernel messages (dmesg) ? The most common problem I see is people building the 6xx-7xx drm branch but not getting the new drm successfully installed... so they're still running the old drm which does not support their hardware.

                  You also might want to hop onto the #radeonhd IRC channel; there's usually a few people online there who just finished installing the 6xx-7xx code so probably have gone through some of the same issues.
                  Hmm, seems my first posting with the pastebinned kernel output got lost... So here we try again

                  kernel dmesg output:


                  full xorg.0.log:



                  You are right, there definetly is a problem with the kernel drm module on my machine. Maybe it's my fault but I am not aware where I made the error.

                  I did following procedure to install it:
                  Code:
                  git clone git://anongit.freedesktop.org/mesa/drm
                  git checkout -b r6xx-r7xx-support origin/r6xx-r7xx-support
                  cd drm/linux-core
                  make
                  cp drm.ko radeon.ko /lib/modules/2.6.27-gentoo-r8/kernel/drivers/gpu/
                  depmod
                  In tne kernel-config DRM and the radeon module are deselected. I did a make clean within the kernel dir before compiling the git drm module.

                  Hmm, I just had a thought that my errors have something to do with an outdated mesa? I am using mesa-7.2.


                  @rahman.duran:
                  Good to hear that accelleration support basically works on your machine! I too experience the slowness of scrolling but without screen corruptions. Well, there's at least no mess on my screen without the working drm module

                  Could you please have a look which versions of: xorg-server, mesa, libdrm you are running and from what kernel sources you did the compile?

                  Comment


                  • #10
                    I don't understand the comment about "KWin can't enable desktop effects". This is already working for a couple of KDE 4.x users. There is an "Advanced" button you need to click in order to reach the dialog where you can choose XRender.
                    Test signature

                    Comment

                    Working...
                    X