Announcement

Collapse
No announcement yet.

Fglrx 8.6 or 8.7 doesn't work with Intel AGP at all

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

  • #16
    Originally posted by bridgman View Post
    I don't really understand you here. Accelerated 2D and 3D was available from roughly the time the card launched. As near as I can figure from your posts something went wrong with your installation so you didn't get acceleration. In your case I think you also picked up some bad advice from the internet and wasted a bunch of time as a result, which is unfortunate but does sometimes happen.





    Since "perpetual mesa" means "something went wrong with the installation on my particular combination of hardware, distro, updates and drivers" I doubt we will ever get rid of it completely, but it is happening a lot less these days now that the installer has been opened up to allow independent maintenance of distro-specific packaging scripts.

    Doing a Google search for "can't acquire AGP" gave me only 3 hits, one of them from your post. The other two seem related to a motherboard BIOS bug which allowed the AGP aperture to be allocated above 2^^32 which a lot of hardware apparently can't handle.



    I can definitively tell you drm should not be built for fglrx. re: getting rid of the error message, please post your full x log to the bugzilla ticket so we can all see what is going on.



    Yes.



    Why do you say that ?

    Ok, thanks. Will rerun without drm and post the X log to my bugzilla ticket.

    It's true that I may have picked up some bad advice, but it begs the question why so many people are thrashing around with these problems. Getting working 2D out-of-the-box for linux should be as easy as for Windoze. Especially in the case of Debian Etch one of the most stable distros on the planet.

    Why do I say that I feel horn swaggled? Because ATI has generated the impression that they make a usable driver available via package generation. Unless there is a 100% distro neutral way of distributing the driver ATI cannot absolve itself of the responsibility of testing the results of the distribution mechanism they provide, i.e. test the results of generating packages. If that doesn't yield a problem free install then for all intents and purposes it's the equivalent of a buggy driver. It just shouldn't be that difficult!

    For instance, the packages could include pre and post install scripts that validate the driver environment (libraries, kernel source, tools, etc.). Frankly I'm surprised that this seems to be missing from the generated Debian packages as the Debian packagers tend to be very thorough on that count. What exactly have they made available to ATI in the way of packaging?

    Despite my irritation with the driver (or lack thereof) your help is greatly appreciated. I'll post my X log ASAP after I get home from work.

    Comment


    • #17
      Why do I say that I feel horn swaggled? Because ATI has generated the impression that they make a usable driver available via package generation.

      Unless there is a 100% distro neutral way of distributing the driver ATI cannot absolve itself of the responsibility of testing the results of the distribution mechanism they provide, i.e. test the results of generating packages.
      We try to be pretty clear in our statements about supported distros. I think we have been using the following blurb for quite a while.

      Operating Systems Distributions Supported
      The latest version of the ATI Catalyst™ Linux software suite is designed to support the following Linux distributions:

      Red Hat Enterprise Linux suite
      Novell/SuSE product suite

      --------------------------------------------------------------------------------
      Note: The ATI Catalyst™ Linux software suite may install on a number of other Linux distributions. Refer to the Package Generation installation instructions for more information.

      --------------------------------------------------------------------------------

      --------------------------------------------------------------------------------
      Note: AMD has accepted contributed packaging scripts to allows creation of other packages, but does not necessarily test, verify or warrant the reliability. Currently Red Hat Enterprise Linux suite and Novell/SuSE product suite are supported Linux distributions

      --------------------------------------------------------------------------------
      If you have any ideas for making this more clear please let us know.

      Thanks,
      John

      Comment


      • #18
        Not sure if I asked this, but have you used the radeonhd (or radeon) driver with shadowfb acceleration ? If you haven't, you'll find it *much* faster for 2d than fglrx running without acceleration -- definitely worth a try.

        Comment


        • #19
          Originally posted by bridgman View Post
          Not sure if I asked this, but have you used the radeonhd (or radeon) driver with shadowfb acceleration ? If you haven't, you'll find it *much* faster for 2d than fglrx running without acceleration -- definitely worth a try.
          No, I have not used radeonhd. Don't know how to enable shadowfb.

          Anything is bound to be "much" faster than fglrx without 2D acceleration. That isn't saying anything of value. My ancient Matrox Millenium runs circles around the crippled fglrx in 2D. Unless the 2D performance is on par with the 2D performance of the Catalyst Windoze driver I would not consider it an acceptable alternative.

          Having indicated my willingness to help get 2D working for fglrx are you now telling me I should abandon that effort? Perhaps for reasons not shared with me nor anyone else in the linux community?

          Don't mean to sound paranoid, but the timing of your comment strikes me as odd coming right after my agreement to run fglrx without drm and to post the resulting X log. Having invested as much time as I have I'd really like closure on 2D using fglrx.

          Comment


          • #20
            Originally posted by nbi1 View Post
            No, I have not used radeonhd. Don't know how to enable shadowfb.
            Shadowfb is enabled by default on 6xx and 7xx cards. There is also an option to force it on with 5xx and RS690 (Option "AccelMethod" "ShadowFB", I think).

            Originally posted by nbi1 View Post
            Anything is bound to be "much" faster than fglrx without 2D acceleration. That isn't saying anything of value. My ancient Matrox Millenium runs circles around the crippled fglrx in 2D. Unless the 2D performance is on par with the 2D performance of the Catalyst Windoze driver I would not consider it an acceptable alternative.
            No worries, I was just surprised that you hadn't found the existing open source drivers useable since shadowfb runs as fast or faster than traditional 2D acceleration on many systems. The only place you see a real advantage from "2D acceleration" these days is if you are running full EXA Render acceleration (running on the 3D engine) and a very recent X server build to pick up the latest EXA server enhancements. You might be surprised how fast shadowfb really is.

            Originally posted by nbi1 View Post
            Having indicated my willingness to help get 2D working for fglrx are you now telling me I should abandon that effort? Perhaps for reasons not shared with me nor anyone else in the linux community?
            Well, there is the secret conspiracy with Microsoft... darn it, I wasn't supposed to say anything about that

            Seriously, your comments about prioritizing 2D over 3D made me think you would have been pretty happy with the open source drivers, since 3D is really where fglrx has a big lead over the open source drivers.

            Originally posted by nbi1 View Post
            Don't mean to sound paranoid, but the timing of your comment strikes me as odd coming right after my agreement to run fglrx without drm and to post the resulting X log. Having invested as much time as I have I'd really like closure on 2D using fglrx.
            No, not paranoid at all
            Last edited by bridgman; 08-04-2008, 07:23 PM.

            Comment


            • #21
              Originally posted by bridgman View Post
              Shadowfb is enabled by default on 6xx and 7xx cards. There is also an option to force it on with 5xx and RS690 (Option "AccelMethod" "ShadowFB", I think).



              No worries, I was just surprised that you hadn't found the existing open source drivers useable since shadowfb runs as fast or faster than traditional 2D acceleration on many systems. The only place you see a real advantage from "2D acceleration" these days is if you are running full EXA Render acceleration (running on the 3D engine) and a very recent X server build to pick up the latest EXA server enhancements. You might be surprised how fast shadowfb really is.



              Well, there is the secret conspiracy with Microsoft... darn it, I wasn't supposed to say anything about that

              Seriously, your comments about prioritizing 2D over 3D made me think you would have been pretty happy with the open source drivers, since 3D is really where fglrx has a big lead over the open source drivers.



              No, not paranoid at all
              radeonhd does not install on Debian etch. There are too many dependency issues to attempt building it from source. Don't ask me to change my OS in an attempt to use an unproven driver. There are many alarming statements in the radeonhd documentation:
              1. "Future work is happening especially on more advanced features like 2D, 3D and video acceleration." (Say what?)
              2. "No XVideo"
              3. "there is no DRI support for r6xx based cards yet!"

              Any other minor details I overlooked?

              I posted my complete X log in my bugzilla report for Catalyst 8.7. I'm waiting to see if anyone will respond.

              Comment


              • #22
                Take it easy

                nbi1, I understand your frustration(I've been there before) but try to see some other aspects.
                fglrx is not that bad. I know people who use ATI cards in linux and have no problems. The driver improved a lot last year, believe me, many problems have been solved. What happens in our case is a bug with an intel_agp module. Unfortunately I had found people on the internet asking help to configure fglrx on an intel agp motherboard back to 2005, with the very same behavior blank screen, computer hangs and freezes. But this "bug" happens only in some specific hardware kernel-options/libs combination. I found this discussion which demonstrates what I'm talking about:
                http://bbs.archlinux.org/viewtopic.php?id=26016

                It "miraculously worked"
                They don't know what triggers this bug.

                Don't blame Debian's fglrx packages they are in good shape, as you said the best linux distro in the planet. Fglrx is probably not fully tested in AGP platform as it is in PCI-E. All of this problems happens mostly to card with this Rialto chip (a chip which interfaces PCI-E GPUs to AGP slot), and bugs in packages even the Debian stable branch exists once in a while. Maybe the microcode for this chip should be opened to the Xorg community.

                I'll attach my logs and experience to the bug report, and bridgman did you check the logs I posted ? My computer just hangs after I try to start kdm and no more message is saved in the log. Could you give me some directions to debug the application ?
                I really don't know how to proceed and what to debug: kdm ? X ? fglrx ?
                everything ?
                Last edited by israel_miranda; 08-05-2008, 12:25 PM.

                Comment


                • #23
                  Hi! As I dont know anything about your systemconfig, I updated my bench iso to current kernel + fgrlx 8-7 (+ all nvidia drivers). Language is german, but should not matter, it autoinstalls the 3d drivers.

                  http://debian.tu-bs.de/project/kanot...-5-generic.iso
                  http://debian.tu-bs.de/project/kanot...eneric.iso.md5

                  It includes gl2benchmark, something that can only render nvidia correctly (there test 1 to 4 work, fglrx can only render 1+2). You can also check your settings with amdcccle and fgl_glxgears. (if you need to get root: sudo -i)

                  Comment


                  • #24
                    radeonhd should build on

                    Originally posted by nbi1 View Post
                    radeonhd does not install on Debian etch. There are too many dependency issues to attempt building it from source. Don't ask me to change my OS in an attempt to use an unproven driver. There are many alarming statements in the radeonhd documentation:
                    We don't have a bug report about radeonhd not compiling on Debian Etch. Which it should, in fact we think that even modern drivers should compile on older X systems, an opinion that isn't shared by all developers in the X community. So please report on bugs.freedesktop.org or on the radeonhd mailing list. Build was broken for BSD for a little while, but that has been fixed lately.

                    Originally posted by nbi1 View Post
                    1. "Future work is happening especially on more advanced features like 2D, 3D and video acceleration." (Say what?)
                    2. "No XVideo"
                    3. "there is no DRI support for r6xx based cards yet!"
                    Ok, your point? r6xx is a completely new architecture, and especially the 3D engine has provrn to be notorious difficult (ask Alex Deucher or John Bridgman for confirmation). r5xx acceleration is luckily almost finished thanks to Alex, while on the 3D side unfortunately nobody works on the r5xx mesa driver on a constant basis.

                    Comment


                    • #25
                      You can install radeonhd with etch. It is just more tricky. Kanotix has it (base still etch) - just without 3d support, therfore I provide the fglrx script.

                      Comment


                      • #26
                        Originally posted by Kano View Post
                        You can install radeonhd with etch. It is just more tricky. Kanotix has it (base still etch) - just without 3d support, therfore I provide the fglrx script.
                        If someone wants to give me the recipe for bludgeoning the "testing" package into usable form for etch I'd be happy to do it as I don't expect to be spoon fed on everything. If it's already available in etch usable form great, but the conversion procedure would be good to know at any rate.

                        BTW, ich spreche gebrochenes Deutsch. (Ehemaliger Ansbacher)
                        And I could use a cold Tucher Pilsener right about now!
                        Cheers.

                        Peter

                        Comment


                        • #27
                          Originally posted by nbi1 View Post
                          If someone wants to give me the recipe for bludgeoning the "testing" package into usable form for etch I'd be happy to do it as I don't expect to be spoon fed on everything. If it's already available in etch usable form great, but the conversion procedure would be good to know at any rate.

                          BTW, ich spreche gebrochenes Deutsch. (Ehemaliger Ansbacher)
                          And I could use a cold Tucher Pilsener right about now!
                          Cheers.

                          Peter
                          Your logs seem OK - that AGP -1023 is the killer. I used to get that on my X1600 until I found a workaround (setting aperture to 512 in bios) that was with nvidia-agp.

                          Now I have almost the same card as you and I don't even need the workaround anymore.

                          I guess intel-agp has it's own different problems :-(

                          If you happen to have

                          i82875p_edac
                          edac_mc

                          loaded then you could try blacklisting them -

                          http://peter.peca.dk/art_Linux_Hardw...atibility.html

                          Comment


                          • #28
                            Originally posted by legume View Post
                            Your logs seem OK - that AGP -1023 is the killer. I used to get that on my X1600 until I found a workaround (setting aperture to 512 in bios) that was with nvidia-agp.

                            Now I have almost the same card as you and I don't even need the workaround anymore.

                            I guess intel-agp has it's own different problems :-(

                            If you happen to have

                            i82875p_edac
                            edac_mc

                            loaded then you could try blacklisting them -

                            http://peter.peca.dk/art_Linux_Hardw...atibility.html
                            I never had the edac code built at all, either as module(s) or into the kernel. Yes, I did find that discussion thread, but thanks for bringing it to my attention. Maybe I should give it a try?

                            Setting the aperture size in BIOS had no effect on this problem other than to increase/decrease overall system performance.

                            Comment


                            • #29
                              Originally posted by nbi1 View Post
                              I never had the edac code built at all, either as module(s) or into the kernel. Yes, I did find that discussion thread, but thanks for bringing it to my attention. Maybe I should give it a try?

                              Setting the aperture size in BIOS had no effect on this problem other than to increase/decrease overall system performance.
                              He had to disable them so I doubt using them would help - maybe you could try seeing what other modules get loaded that you can live without and blacklist those. Clutching at straws really.

                              I am surprised changing aperture size in bios (which I thought just sets the upper limit that a driver could use if it wanted too) gives a performance difference.

                              Comment


                              • #30
                                Originally posted by Kano View Post
                                You can install radeonhd with etch. It is just more tricky. Kanotix has it (base still etch) - just without 3d support, therfore I provide the fglrx script.
                                I don't understand what you are saying here. You have already created such a script or are creating one? All I need is some assistance in getting the source built.

                                I tried building from source, but autogen.sh is missing. I'm guessing the notes simply didn't get updated to reflect the use of 'configure' which bombs as follows:
                                checking for XORG... configure: error: Package requirements (xorg-server xproto fontsproto ) were not met:

                                No package 'xorg-server' found
                                No package 'fontsproto' found

                                I can't find these packages.

                                Comment

                                Working...
                                X