Announcement

Collapse
No announcement yet.

"Ask ATI" dev thread

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

  • Dear ATI devs.

    I think I have one that may stump the devs. I have received no response from the any other list, so I am trying here. I bought a new HIS Radeon x1650 card for my daughter's computer, and I cannot get the card to draw gears in glxgears. I thought I knew the fglrx driver pretty well, but I am stumped here. The card has 512M of Ram and sits in the AGP slot of an MSI KM2M board running openSuSE 11.0/KDE 3.59 and compiz-0.7.6-16.1. All bios setting are correct.

    The 1650 replaced a 9600 card in the same box so the Catalyst 8-8 driver was already installed and compiz and mplayer had been working fine. After installing the x1650 card, kde runs fine, but glxgears is blank (no gears, just a black window, but good frame rates in the console). The same blank window occurs with mplayer and with compiz, the entire display goes blank (no screenshot of that):




    I have done just about everything I can think of with xorg.conf and I updated /etc/ati/amdpcsdb with the changes (aticonfig --input=/etc/X11/xorg.conf) trying tls on/off (--tls=1)(--tls=0) and I have tried removing all xorg.conf "Device" section "Options" and adding them back one at a time (restarting x in between) but still I get blank glxgears, mplayer and compiz is blank as well. I have tried with and without the Extensions enabled (composite and damage) and with and without AIGLX enabled. No change.

    When I say compiz is blank, I mean I'll start compiz and then the entire screen goes blank/black. Typing in the blind (alt+f2 'kwin --replace &' tab tab return) restores kwin without a problem showing that compiz was running.

    I cannot find anything wrong with my config, but I cannot explain the blank compiz, glxgears or mplayer. The complete config and log details are:






    My conclusion is that there is a bug in the driver as it relates to the 1650 card or the HIS 1650 card. This is drawn from working with the x1650 AGP card in a MSI KM2M motherboard for the past 3 weeks with no luck. See: ([opensuse] radeon 1650 agp - no compiz, blank glxgears, but good frame rates?) The problem is that the AGP x1650 card cannot handle any overlay or composite display. After trying all options with both the 8-8 and 8-9 driver, the card still would not draw the gears in glxgears, video in mplayer or anything in compiz.

    Further evidence of a driver or card problem: I replaced the x1650 512M card with an x800 XT 256M card, dropped it in the slot, rebooted (didn't even bother to alter the board name in xorg.conf) and everything worked perfectly. The frame rates with glxgears were everybit as good as with the x1650, and ... there were actually _gears_ in the glxgears box. Compiz worked perfectly.

    So what say the ATI devs? What's the problem with the 1650 card?

    Comment


    • Hi,
      (WW) fglrx: No matching Device section for instance (BusID PCI:1:0:1) found
      (--) Chipset Supported AMD Graphics Processor (0x71C1) found
      (WW) fglrx: No matching Device section for instance (BusID PCI:1:0:1) found

      seems you need to change that in xorg.conf?
      BusID "PCI:1:0:0"

      or maybe that is completly harmless and unrelated. But when I switched mobo I had to change that or the driver wouldn't work as expected.

      Comment


      • My suggestion would be to run aticonfig --initial again, you may need to also add -f to force it. It will backup your current xorg.conf and tell you the name it gives it, and then make a new one for you. It will add the options such as BusID(as I agree with energyman, that this seems to be the trouble with the card) and others for you and the others you can copy over from the backup.

        I'm not sure which distro you are using or how recent it is, but if it is a newer release, you can likely leave out 99% of the Files section, all the Modules section, AIGLX you don't need to set as it is enabled by deafult in fglrx, under the device section you don't need to set the FSAA options, the MaxGART size or XAANoOffscreenPixmaps as again, these are all set(as you have them) by default within the driver.

        After you get that looked after, run fglrxinfo to see if the driver is loading properly. If it is, it will list ATI info, if not it will show MESA. If it ahows ATI then the driver is up and running properly and then you can give glxgears a shot.

        Comment


        • Originally posted by drankinatty View Post
          Dear ATI devs.

          I think I have one that may stump the devs. I have received no response from the any other list, so I am trying here. I bought a new HIS Radeon x1650 card for my daughter's computer, and I cannot get the card to draw gears in glxgears. I thought I knew the fglrx driver pretty well, but I am stumped here. The card has 512M of Ram and sits in the AGP slot of an MSI KM2M board running openSuSE 11.0/KDE 3.59 and compiz-0.7.6-16.1. All bios setting are correct.
          Setting the agp aperture size in the BIOS to 512 if you can may fix it - if it doesn't do 512, try the highest.

          All is not lost for a 1650 if it doesn't work as you could try the OSS radeon or radeonhd drivers. You should get 3D and xv OK with these.

          I don't know what you need to do for opensuse to get a recent enough X server/mesa/drm/drivers.

          Comment


          • Originally posted by legume View Post
            Setting the agp aperture size in the BIOS to 512 if you can may fix it - if it doesn't do 512, try the highest.

            All is not lost for a 1650 if it doesn't work as you could try the OSS radeon or radeonhd drivers. You should get 3D and xv OK with these.

            I don't know what you need to do for opensuse to get a recent enough X server/mesa/drm/drivers.
            Well,

            The strange part about the HIS x1650 issue is that I have run a number of ATI cards in this same AGP slot with the fglrx driver without *any* problems at all. I had a 9600 card that worked fine with glxgears and compiz, the 1650 fails, I put an x800 card in and it works great as well. The curious part is the x1650 seems to work fine on the windows side of the dual-boot machine. All testing was done with both the 8-8 and 8-9 fglrx drivers and the results were the same. I'm beginning to wonder if the Chinese manufacturer of the HIS card chipsets didn't cut-corners that are causing the problems.

            The largest AGP apeture that is supported in the BIOS is 256M which I have set. I have tried the X/mesa/drm setup and it crawls in comparison to the fglrx drivers. In the past, I have built X/mesa/drm from scratch to patch resolution modes and that is definitely something I don't want to repeat. I think I'll stay with the X800 card here. I think the X800 XT card is twice the card the 1650 is. (I know it weighs at least twice as much). The performance is 100% equivalent on frame-rates with glxgears (5700-5750 FPS). Just frustrating that the supposedly newer/faster card can't display glxgears?

            Comment


            • I'm not sure an X1650 would outrun an X800XT at the best of times. IIRC the X1650 is essentially a 4-pipe chip with extra ALUs for shader-intensive code, while the X800XT is a 16-pipe chip. If I had to guess I would expect the X800XT to be twice as fast as the X1650 unless the newer shader model capabilities were being used by the app.

              The AGP interface hardware on the X1650XT is quite different from earlier generations -- it uses a PCIE GPU with an AGP bridge, while previous generations generally used native AGP GPUs -- so it will definitely have a different set of challenges with each motherboard. The defaults for things like AGP speed may be different as well. I'll ask around re: what options the current drivers have for making your AGP board and mobo work together better (assuming that is the problem).
              Test signature

              Comment


              • Originally posted by drankinatty View Post
                Well,

                The strange part about the HIS x1650 issue is that I have run a number of ATI cards in this same AGP slot with the fglrx driver without *any* problems at all.
                That's what I found, my X1600 would work with Windows, OSS and old fglrx but not recent fglrx unless I set 512 aperture on my nforce2 mobo.

                I have a HD3850 now and it will work whatever the aperture is set to.

                Comment


                • Bridgman, can you tell anything about FGLRX driver quality roadmap?

                  Right now the driver is somewhere between bad and OK. It's fast enough and mostly working after some tweakings but full of serious bugs (which lead to X crash, system freeze etc). It doesn't "just work". Looks like many people hope that every driver release is significally better that the previous one. And it's not. Therefore people (including myself) start bitching and blame ATI developers.

                  The worst things is that we don't know when to expect driver which is somewhere between OK and good quality. The driver with only minor bugs, most required for that features implemented etc. Will it happen in next several monthes, in more than a year or never happen at all.

                  I've seen one roadmap (http://resources.vr-zone.com//newspi...t_roadmap1.png) but it doesn't reveal anything about the driver's quality.

                  Comment


                  • Question:

                    How many people work on the Linux Driver at ATi?

                    Comment


                    • A GEM/TTM question

                      On a different aspect of the driver: is there planning done at AMD now to use the GEM interface which has just entered Linux-next (future 2.6.29)? Because, if I remember correctly, you mentioned in a previous post that a somewhat similar architecture is used by fglrx.

                      Stop me if I'm wrong, if fglrx could use GEM, then we wouldn't need to recompile a kernel interface to install/update fglrx and the kernel? Is there work actually underway in that regard?

                      I know GEM is far from final (you just gotta see what Linus feels about it), but, maybe, support from a currently full-featured driver (even if closed source) may help, no? Considering fglrx's development cycle, starting it now may result in a first release by the time 2.6.30 gets out of RC...

                      Comment

                      Working...
                      X