Announcement

Collapse
No announcement yet.

Not all Unhappy campers on ati

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

  • #16
    It depends - when you know what the nvidia does it is not that critical. As it replaces parts of xorg and mesa (which are restored when you call uninstall to the version it was when the installer ran first time) it certainly only works until those packages are updated - then you have to run the installer again - thats all. It would be the same when you compile your own oss drivers without package management. You can check which packages are effected like this:
    Code:
    dpkg -S $(grep 1..: /var/lib/nvidia/log|cut -d: -f2)
    libgl1-mesa-glx: /usr/lib/libGL.so.1.2
    xserver-xorg-core: /usr/lib/xorg/modules/extensions/libglx.so
    libvdpau1: /usr/lib/vdpau/libvdpau_trace.so.1.0.0
    libvdpau1: /usr/lib/libvdpau.so.1.0.0
    so after a clean uninstall you just do
    Code:
    apt-get install --reinstall libgl1-mesa-glx xserver-xorg-core libvdpau1
    To uninstall i wrote a tiny script - uninstalls fglrx as well:
    http://kanotix.com/files/fix/oss-tes...nary-driver.sh
    But do whatever you like - i want new drivers as soon as i know about em, i don't care (on a debian system) if there are debian packages or not. Things would be different on ubuntu lucid+. There you should NOT do that.

    Comment


    • #17
      Originally posted by Kano View Post
      @elanthis

      Newer nv cards (dx10+) seem to have better oss drivers than ati cards. Did you check out nouveau lately? There are speed differences but not as extreme like ati. Also more games work - waiting for trine to work with ati/intel.
      The nv mx-440 is so old it's past giving away in breakfast cereal boxes. I'm stuck on 96.43.xx drivers in linux. The libGL stuff is so old I suspected it was causing issues. So I got the ATI HD4650, never dreaming I'd have to install windows, and never dreaming that it was a superbitch to install.

      Thanks for your comments, guys.

      Comment


      • #18
        Use my distro and most likely it will work

        Comment


        • #19
          Originally posted by pingufunkybeat View Post
          I prefer using the package manager instead of running nvidia install scripts. I'm sorry I did not make this clear.

          The reason I am running Debian at work is that I trust its package management system and I know that it's stable and I won't have to muck around with it and can concentrate on work. My home Gentoo machine is for mucking around and experimenting.

          I know how to run the nvidia installer, I've done it many times in the past, and it left a trail of destruction behind it. Perhaps it's improved now, but I still don't like executing random things as root. I also don't like dropping binaries all over the filesystem and bypassing the package management. I might as well run LFS if I'm going to do that.

          Now I have debian packages installed and it works.
          Thats what I like with fglrx. It has a buildin package generation tool, given that you are running one of the supported OSs. If a new kernel is installed, dkms will recompile fglrx's kernel module.

          Comment


          • #20
            When you use an ubuntu style kernel - like ubuntu mainlines ones - then my nvidia script has also dkms support. That's not depending on packageing or not, dkms is a very simple thing. The problem is that the debian nvidia dkms support is not compatible with u style kernels and vice versa. As my distro does not use debian kernels i dont have got that in the script, but a tiny addon extra script for pure debian (which i wrote before i integrated it) would be simple if the demand is there.

            Comment


            • #21
              Originally posted by Kano View Post
              When you use an ubuntu style kernel - like ubuntu mainlines ones - then my nvidia script has also dkms support. That's not depending on packageing or not, dkms is a very simple thing. The problem is that the debian nvidia dkms support is not compatible with u style kernels and vice versa. As my distro does not use debian kernels i dont have got that in the script, but a tiny addon extra script for pure debian (which i wrote before i integrated it) would be simple if the demand is there.
              Right. dkms is nice and all, but the main advantage is the use of the packaging system.
              I really don't like to polute my system with anything not installed through my package manager. That is also the reason why I use checkinstall to generate/install packages for Ubuntu from plain source code.

              Comment


              • #22
                I prefer compiling extra apps from source with --prefix=$HOME/dist with PKG_CONFIG_PATH + LD_LIBRARY_PATH overrides. That also exposes problems in apps like xbmc which definitely does not like when libbluray is installed that way. I think it is still not fixed... checkinstall does not create good packages, they are even painfull when depends should be parsed. At least it allows you to remove em more simple, but thats all. The remove problem for binary drivers is very simple and already solved...

                Comment


                • #23
                  Originally posted by amphigory View Post
                  What really astonishes me is the stability of the development trees. I'm running kernel 2.6.39-rc4 with drm/mesa/xf86-video-ati from git and everything is completely stable. I haven't submitted a bug report in ages.
                  Great for you. I am stuck at kernel 2.6.36, because with newer kernels the X server hangs with black screen. Problem reported but no progress so far. I am on the newest (stable) mesa and radeon driver (with HD 4350).

                  But before this problem, the driver and kernel and mesa combo was quite stable across versions, I am satisfied with it. It just has many graphical bugs (celestia, stellarium, kwin/video tearing), which are slowly getting better.

                  Comment


                  • #24
                    Originally posted by Kano View Post
                    Newer nv cards (dx10+) seem to have better oss drivers than ati cards. Did you check out nouveau lately? There are speed differences but not as extreme like ati. Also more games work - waiting for trine to work with ati/intel.
                    Can you pleas post some nvidia vs nouveau benchmarks? I'm sorry but I REALLY doubt it.
                    ## VGA ##
                    AMD: X1950XTX, HD3870, HD5870
                    Intel: GMA45, HD3000 (Core i5 2500K)

                    Comment


                    • #25
                      The reason why Trine worked correctly in Nouveau was (ironically) incorrect code. Nouveau did not check a flag and went along, while all other drivers checked the flag and acted accordingly.

                      Then another bug had the flag set incorrectly, causing all other drivers to fail.

                      Great for you. I am stuck at kernel 2.6.36, because with newer kernels the X server hangs with black screen. Problem reported but no progress so far. I am on the newest (stable) mesa and radeon driver (with HD 4350).
                      This is no help for you, of course, but I've run my HD 4350 on .37, .38 and ,39-rc3, with no problems.

                      Are you absolutely sure you're not making any mistakes when compiling the newer kernels? Can you link the bug report?

                      Comment


                      • #26
                        Originally posted by pingufunkybeat View Post
                        This is no help for you, of course, but I've run my HD 4350 on .37, .38 and ,39-rc3, with no problems.

                        Are you absolutely sure you're not making any mistakes when compiling the newer kernels? Can you link the bug report?
                        Thanks, at least there is hope Here is the bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=31974. Of course it may depend on wrong compile options or driver options. All starts fine e.g. with NoAccel driver option.

                        Comment


                        • #27
                          Hrm, it might be related to vga-switcheroo or something. I have an HD 4350 (PCI) and an HD 4550 (PCI-x) in this computer and can't remember the last lockup I've had.

                          Do you compile your own kernels? Are you sure you're using the same config for older and newer kernels?

                          Comment


                          • #28
                            Yes I compile my kernels and always migrate the same config to newer kernels, answering just new options. I do not have 2 cards in the system. But I could try to disable vga arbitration in the kernel (I have it compiled in if I need it in the future).

                            However I am not the original reporter of the bug, who has 2 cards. Maybe my problem is different from his just the symptoms are the same.

                            Comment


                            • #29
                              Originally posted by aceman View Post
                              Yes I compile my kernels and always migrate the same config to newer kernels, answering just new options. I do not have 2 cards in the system. But I could try to disable vga arbitration in the kernel (I have it compiled in if I need it in the future).

                              However I am not the original reporter of the bug, who has 2 cards. Maybe my problem is different from his just the symptoms are the same.
                              I'm the original reporter of that bug. And I also think we're actually hitting different bugs, as since recently my problem has disappeared. Unfortunately I've no idea what exactly fixed it for me, but at least with 2.6.39-rc2 and ati 6.14.1 it's now working for me... at least kinda. The XServer starts up and Xorg-log reports EXA and DRI2 are enabled, but everything is veeery slow... for example I only get ~16FPS on OpenArena.
                              Anyway I really should go and update that bug-report.

                              Comment


                              • #30
                                Soooo... I am sure kernel 2.6.38 didn't work. But now I have compiled 2.6.38.3 AND disabled vga arbitration in the kernel. And now everything works fine as before. Yes, even xterm redraws ARE slower but e.g. mplayer and googleearth ARE not noticeably slower. But I will look into it more later and post in the bugreport. Thank you guys for poking into it

                                Comment

                                Working...
                                X