Announcement

Collapse
No announcement yet.

RS480/RS690 OSS Compiz Achieved

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

  • #31
    Originally posted by rvdboom View Post
    Well I did compile libdrm, mesa and xf86-driver-ati from git; as well as dri2proto, but got not much luck with KWin4 compositing abilities.
    I have this strange message in Xorg.0.log, though :

    Code:
    bash-3.1$ grep AIGLX /var/log/Xorg.0.log
    (**) Option "AIGLX"
    (**) AIGLX enabled
    (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/r300_dri.so failed (/usr/lib/xorg/modules/dri/r300_dri.so: undefined symbol: _glapi_tls_Context)
    (EE) AIGLX: reverting to software rendering
    bash-3.1$
    I compiled mesa with glx-tls enabled and osmesa. What module could be responsible for this message?
    Apart from that, messages in Xorg.0.log seem consistent with what is given above :

    Code:
    (II) RADEON(0): [dri] Found DRI library version 1.3.0 and kernel module version 1.28.0
    (II) RADEON(0): Direct rendering experimental on RS400/Xpress 200 enabled
    (**) RADEON(0): Page Flipping enabled
    (II) RADEON(0): Will try to use DMA for Xv image transfers
    (II) RADEON(0): Detected total video RAM=32768K, accessible=65536K (PCI BAR=65536K)
    (--) RADEON(0): Mapped VideoRAM: 32768 kByte (64 bit DDR SDRAM)
    (II) RADEON(0): Color tiling enabled by default
    (II) RADEON(0): Max desktop size set to 2560x1200
    
    (snip)
    
    (==) RADEON(0): Backing store disabled
    (II) RADEON(0): [DRI] installation complete
    (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers
    (II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers
    (II) RADEON(0): [drm] dma control initialized, using IRQ 17
    (II) RADEON(0): [drm] Initialized kernel GART heap manager, 5111808
    (WW) RADEON(0): DRI init changed memory map, adjusting ...
    (WW) RADEON(0):   MC_FB_LOCATION  was: 0x1fff1e00 is: 0x1fff1e00
    (WW) RADEON(0):   MC_AGP_LOCATION was: 0xffffffc0 is: 0x21ff2000
    (II) RADEON(0): RADEONRestoreMemMapRegisters() :
    (II) RADEON(0):   MC_FB_LOCATION   : 0x1fff1e00 0x1fff1e00
    (II) RADEON(0):   MC_AGP_LOCATION  : 0x21ff2000
    (II) RADEON(0): Direct rendering enabled
    (II) RADEON(0): Render acceleration enabled for R300/R400/R500 type cards.
    (II) RADEON(0): RADEONEngineInit: num pipes is 4
    (II) EXA(0): Offscreen pixmap area of 7553024 bytes
    (II) EXA(0): Driver registered support for the following operations:
    (II)         Solid
    (II)         Copy
    (II)         Composite (RENDER acceleration)
    (II)         UploadToScreen
    (II)         DownloadFromScreen
    (II) RADEON(0): Acceleration enabled
    So EXA and DRI seem correctly enabled, even though glxinfo says no direct rendering is done.
    I should add that my chipset is detected as "ATI Radeon XPRESS 200M 5955 (PCIE)".
    to me kde4 doesn't function with the git version of xorg so i cannot tell you nothing about kwin4 compositing, for now.

    as for the aiglx error it isn't something that on my board gives issues, but i still have to remember that my chipset is 5975 and not 5595. anyway, that symbol should have been given at least a warning during the compilation of the xf86-video-ati package. also you could use the gart size option and set it to 64mb to use 64mb or video ram instead of just 32 that you're using now. it would give you some boost in terms of fluidness at least when using multitasking.
    as for the mesa compile options i need to see how my ebuilds take the configure options to mesa and to the mesa gl-core branch.

    Comment


    • #32
      Originally posted by givemesugarr View Post
      compilation of the xf86-video-ati package.
      I agree but the compilation seems to work fine. I'm using the current release of xorg, with an xserver 1.4. mesa, libdrm, drm2proto and the ati driver are the only things I got from git. Maybe that's the reason I get a weird behaviour, I should upgrade xorg to full git version?

      Originally posted by givemesugarr View Post
      as for the mesa compile options i need to see how my ebuilds take the configure options to mesa and to the mesa gl-core branch.
      I used a "configure --enable-gl-osmesa --enable-glx-tls --prefix=/usr" for mesa, "configure --prefix=/usr" for the others. I compiled drm, mesa then the ati driver in that order, that may be an issue. I retried to build drm after mesa though, with no change.

      Anyway, thanks for your help. :-)

      Comment


      • #33
        Originally posted by rvdboom View Post
        I agree but the compilation seems to work fine. I'm using the current release of xorg, with an xserver 1.4. mesa, libdrm, drm2proto and the ati driver are the only things I got from git. Maybe that's the reason I get a weird behaviour, I should upgrade xorg to full git version?



        I used a "configure --enable-gl-osmesa --enable-glx-tls --prefix=/usr" for mesa, "configure --prefix=/usr" for the others. I compiled drm, mesa then the ati driver in that order, that may be an issue. I retried to build drm after mesa though, with no change.

        Anyway, thanks for your help. :-)
        by drm you intend the drm rework from alex's personal git?!
        to me it doesn't seem to be anything wrong with the compilation; upgrading to xorg git version isn't mandatory and would keep you away from other git packages like libpciaccess and don't break current abi.
        the order for git packages are:
        1. dri2proto
        2. mesa (should include also the libdrm inside it)
        3. drm rework
        4. xf86-video-ati

        and restart x after removing the radeon and drm module.

        Comment


        • #34
          Originally posted by givemesugarr View Post
          by drm you intend the drm rework from alex's personal git?!
          Yes. I don't see any error in the compilation either, that's why I'm rather baffled by this message.
          Oh, well, I'll retry in a week or two, with newer git clones, maybe I'll have more luck. :-)

          Comment


          • #35
            Originally posted by rvdboom View Post
            Yes. I don't see any error in the compilation either, that's why I'm rather baffled by this message.
            Oh, well, I'll retry in a week or two, with newer git clones, maybe I'll have more luck. :-)
            i've just downgraded again to xorg-server 1.4 series (needed to make kde4 work) and drm master and now i got a strage stuff: i get the screen white (as it was when i tried to run compiz some time ago) and i cannot do noting on it. it's quite a strange issue. it's like compiz doesn't want to work anymore.
            i'm now trying to understand if this is due to the latest commits in the radeon driver (last night there were some commits) or to some regression on my system.

            Comment


            • #36
              I have something like this too with KDE4 : when I turn on compositing, most of the screen turns grey, with just some windows outlines (apparently the composited shadows). But everything hangs and I need to restart X.
              When will the next release of X11 including all the recent ATI changes will be planned? :-)

              Comment


              • #37
                Originally posted by rvdboom View Post
                I have something like this too with KDE4 : when I turn on compositing, most of the screen turns grey, with just some windows outlines (apparently the composited shadows). But everything hangs and I need to restart X.
                When will the next release of X11 including all the recent ATI changes will be planned? :-)
                i don't know yet. i know that the new xcb api is a real pain. i've tried it out and now about 180 packages need rebuild, but the disappeareance of a libtool archive and the fact that about 90% of the packages built in gentoo are statically linked makes this a real problem. now i'm struggling to see if the new stuff (radeon fix for x200m compiz has been applied into gentoo mesa snapshot drivers) and if not i'll try to apply it and see if it works. i need to downgrade mesa because glcore on gentoo is now a different module and the git version needs the new git xserver, which in turn doesn't work with kde4. so if you want kde4 to work with compiz similar effects you'll need to still wait a little. maybe on other distros is more friendly, but usually gentoo is a little further on these matters.

                Comment


                • #38
                  I use Slackware personnaly, but I don't mind waiting. I perfectly understand that all this takes time. I'm pretty sure it's a matter of weeks now before I get a working composited desktop, so it's OK for me (after all, it's not that vital an issue :-)).
                  Thanks all for your time and efforts.

                  Comment


                  • #39
                    Originally posted by rvdboom View Post
                    I use Slackware personnaly, but I don't mind waiting. I perfectly understand that all this takes time. I'm pretty sure it's a matter of weeks now before I get a working composited desktop, so it's OK for me (after all, it's not that vital an issue :-)).
                    Thanks all for your time and efforts.
                    try browsing in the slackware forums and see if there have been already generated the new packages with your distro.

                    Comment


                    • #40
                      Xrandr issues with compiz

                      Anybody noticed issues with xrandr and multiple screens with the radeon fix when compiz is on?

                      I don't know if compiz is supposed to work with multiple screens anyway.

                      Comment

                      Working...
                      X