Announcement

Collapse
No announcement yet.

AMD Radeon HD 7970 On Linux

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

  • #46
    Yes and no. I expect this would be a driver branch that ended in December and was used to get last minute SI fixes out the door more quickly than we could in a regular release. Later drivers would support other new hardware but wouldn't necessarily have the SI-specific changes.

    We would have had to lock the driver down in December in order for boards to be on shelves in time for a January launch.

    Comment


    • #47
      Yes seems to be specifiy for that card, but i really dont get it why aticonfig uses the same limited ids as the control file. Basically fglrx is a generic driver similar to the oss radeon one...

      Comment


      • #48
        This is getting into philosophical questions, but if you take a generic driver, make lots of changes for one specific chip and do lots of testing for one specific chip but don't test for regression failures on all the other chips, is that specific branch still a generic driver ?

        Based on what you are saying about aticonfig IDs, it sounds like we decided the answer was "no".

        Comment


        • #49
          Basically there are 2 checks in your driver:

          -> /etc/ati/control

          a pretty useless check as it must contain just a whitelist of some pci ids, but when you remove it all you get is an unsupported hardware watermark - i never saw a driver that did not run at all but showed a watermark - usally the driver crashes before or it works. btw. you can simply replace the file by another one which was supported before.

          -> aticonfig

          that check is really idiculous as it just does not allow you to configure the driver correctly without doing it the manual way. of course a very short xorg.conf would be enough too or lust like u does: they use a package that overrides the xorg autodetection so it uses fglrx instead. if you really want a whitelist use the same ids as in the fglrxko_pci_ids.h file or just check for 1002 vendor.

          ALL fglrx drivers are generic, the same as the nvidia ones. They most likely parse your funny atombios and every supported pci id can be parsed from

          common/lib/modules/fglrx/build_mod/fglrxko_pci_ids.h

          which i do to too create a whitelist. for nvidia you dont need to do a whitelist, because it is much simpler to use a backlist as old pci ids usually do not change at all and every new device is supported anyway - the only thing that does not show up correctly is the name in the OpenGL version string when you use a new device with an old driver, something thats not really critical. If it does not run at all then you see the crash log anyway (very rare).

          a little "optical" hint: update your own 1002 vendor string in the pciids database, it looks really bad now...

          Comment


          • #50
            Originally posted by Kano View Post
            a little "optical" hint: update your own 1002 vendor string in the pciids database, it looks really bad now...
            Do you mean :

            http://pciids.sourceforge.net/pci.ids

            What's wrong with it ?

            Comment


            • #51
              1002 Advanced Micro Devices [AMD] nee ATI

              what lang should be "nee"? maybe "informer", "aka" or whatever...

              Comment


              • #52
                AFAIK it was originally French but absorbed into English a long time ago. The literal meaning is "born" or "born as" but it is most commonly used to indicate "previously named". May not be the ideal usage here since AFAIK it is more commonly used to describe a person rather than a company but "nee" probably fits as well as anything.

                And before anyone asks, it has nothing to do with "the knights who say ni"

                Comment


                • #53
                  Maybe you find a better string to describe the company you work for, i still dont think it is a good one even if it is "correct".

                  Comment


                  • #54
                    X86 unified addressing

                    Current generation gpu could access only page-locked host memory. Could new gpu (SI) access full memory without this limitation? Does it depend on chipset capabilities (ats/pri) ?

                    Comment

                    Working...
                    X