Announcement

Collapse
No announcement yet.

AMD 8.42.3 Driver Released -- The Baby Is Born!

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • I can confirm that the xv and gl video is watchable using xcompmgr over compiz. Its still buggy; it refuses to accept a transparency given by transset and if the background changes (e.g scrolling a web page behind the movie) then the video disappears (apparently replaced by the background) for a fraction of a second (much like the compiz choppyness). I wonder if the xv/gl stuff doesn't like compositing and compiz is more inclined to refresh background windows.

    Comment


    • Originally posted by Phlogiston View Post
      I'm using gentoo with suspend2 patched kernel. Maybe you are missing a certain config line in xorg.conf. I will post it soon.
      Do you have these options?:
      Option "UseInternalAGPGART" "no"
      Option "KernelModuleParm" "agplock=0"

      Comment


      • Originally posted by Phlogiston View Post
        Do you have these options?:
        Option "UseInternalAGPGART" "no"
        Isn't this option deprecated now? I thought they removed all support for internal AGPGart

        Comment


        • Nice one.
          I am installing it right now.

          Thanks!

          Comment


          • Originally posted by Berniyh View Post
            I knew it.

            Now the screen corruption came back, so that isn't the solution either, but it might help a little bit.
            The screen corruption is gone for me - either with AIGLX/composite or without (but opengl/sdl is very slow when AIGLX/composite is on). So, here's everything ok - except the switching-from-X-to-console-and-back ancient bug :-(. Alright, I'm posting the whole Device section, maybe it will help you get rid of the screen corruption.

            Code:
            Section "Device"
            	Identifier  "ATI Radeon 9600"
            	Driver      "fglrx"
            	VendorName  "ATI Technologies Inc"
            	BusID       "PCI:1:0:0"
            	Option	    "VideoOverlay" "on"
            	Option	    "OpenGLOverlay" "off"
            	Option	    "UseFastTLS" "2"
            	Option	    "KernelModuleParm" "locked-userpages=0"
            	Option	    "no_accel" "no"
            	Option	    "no_dri" "no"
            	Option	    "EnablePrivateBackZ" "no"
            	Option	    "backingstore" "true"
            	Option      "XAANoOffscreenPixmaps" "true"
            	Option      "ForceMonitors" "notv"
            EndSection

            Comment


            • Originally posted by hluk View Post
              The screen corruption is gone for me
              I hope you're spitting that not too fast out. My screen was clean for lets say 12 hours, but then it came back.
              Actually if it takes that long it would be acceptable, but I really would like to see AMD releasing a bug fix for this before next driver release (I know that's not gonna happen...).

              Another thing that they really should release a fix for before the next release (8.43) is the wrong SONAME issue of libGL.so which may hold off this driver of gentoo's portage.

              See here:


              That shouldn't be a big issue and I guess it would be fixable by just releasing a fixed libGL.so, but of course that is not going to happen either.

              Comment


              • Option "XAANoOffscreenPixmaps" "true"
                this options seems to remove the screen corruption. after i've added it i have not experienced any corruption anymore.
                the other thing is that you seem to have to force the xv with the videooverlay and disable the opengl overlay. after that i had to set beryl from texture from pixmaps to copy and my fps have not gone down anymore. now i'm stable at 700-800 fps with every environment which is quite good.

                Another thing that they really should release a fix for before the next release (8.43) is the wrong SONAME issue of libGL.so which may hold off this driver of gentoo's portage.
                just use the sabayon ebuild or modify the 8.40.4 one removing the gunzip line and by adding the libGL.so.{major} where there is the libGL symlinking in the ebuild.
                for some reason the sabayon ebuild has removed the fgl_glxgears and some other things, but on my gentoo they work flawlessly. another important thing is to always run the atieventsd service at boot time. after i've had it added some time ago i was able to correct a lot of problems. i don't know what it really does but it seems to be of some kind of use.

                Comment


                • Originally posted by givemesugarr View Post
                  just use the sabayon ebuild or modify the 8.40.4 one removing the gunzip line and by adding the libGL.so.{major} where there is the libGL symlinking in the ebuild.
                  The sabayon ebuild is just wrong. I can't believe, that they actually put something like that in their tree.
                  Did they even test this? It spits out some errors during installation.
                  I'm mean, after an emerge, when you made (or modified an ebuild), you should just go through the install process at least once and see if it did everything correctly.
                  Sorry, but you just can't add some (proprietary) software one day after it has been released to your tree and with that they can't be taken serious by anybody again...
                  ... or at least not by me.

                  The thing with the libGL.so is not that it has the wrong (file-)name. The thing, is that the SONAME of it is wrong, which brings the whole needing for the symlink in in first place.
                  See the gentoo bug about 8.42.3 for information.


                  I'll try the other option and see if that helps, tomorrow.

                  Comment


                  • i don't really know if the sabayon ebuild works... i didn't tried it myself. i've patched manually the old 8.40.4 and installed from that one. for me it worked without problems. i had the driver installed about 1 hour after it was released and it works fine for now.
                    i could test the new ebuild, but since the old patched one works fine i don't really see a reason to change it. maybe when i got to try the 2.6.23 (not so fast since it seems for this driver to have problems with this kernel).

                    as for the soname issue, i don't really think that this is a real problem since it is fixed with a simple symlink. of course that should be fixed in the next release and i think that ati would correct that feature by next month's release. for now just add the symlink part in the ebuild and you'll have it working.

                    Comment


                    • Originally posted by givemesugarr View Post
                      i don't really know if the sabayon ebuild works... i didn't tried it myself. i've patched manually the old 8.40.4 and installed from that one. for me it worked without problems. i had the driver installed about 1 hour after it was released and it works fine for now.
                      i could test the new ebuild, but since the old patched one works fine i don't really see a reason to change it. maybe when i got to try the 2.6.23 (not so fast since it seems for this driver to have problems with this kernel).
                      Then you sort of did what sabayon people did.
                      The thing is (and maybe this is also the reason you didn't expect any problems) that ATI changed the installer package and therefore on AMD64 systems two of the 32bit libs don't get installed (because their location has changed). Of course if you modify the ebuild yourself this is ok, because then you know that you may run into problems, but if the ebuild is provided by your distributor you think, that it will work.
                      With your current ebuild you might expect problems running 32bit apps, that use opengl, for example, if you run a game with wine.

                      as for the soname issue, i don't really think that this is a real problem since it is fixed with a simple symlink. of course that should be fixed in the next release and i think that ati would correct that feature by next month's release. for now just add the symlink part in the ebuild and you'll have it working.
                      Once again you can fix this of course locally very easy, but you can't write sth. like that in the ebuild, because the ebuild works as it should (it writes the libGL.so.1.2 to /usr/lib/opengl/ati/lib and then symlinks libGL.so.1 and libGL.so to it in that directory). Because there are seperate opengl impelementations (xorg-x11 and ati) you need a programm to select the right one and that is eselect, which sets the symlink to /usr/lib. The ebuild should not do that, so there is nothing from the side of the ebuild, that could be done.
                      The real problem is, that because of the wrong SONAME the wrong libname is included by env-update/ldconfig and that is the reason it doesn't find the lib.
                      So this is a problem that should be fixed by ati, not a dirty hack in the ebuild.

                      Comment

                      Working...
                      X