I'm trying to do something similar and can't wait for the HD7xxx ISA manual in particular. I'll try and get the source out as ASAP but I actually have code *running* on the card itself using the UVD microprocessor (a Tensilica Xtensa); although it's only an HD2400 - see the link below. Sorry if slightly off-topic (probably more relevant on an electronics forum).
Originally Posted by curaga
There is no support for the HD 7970 in the closed source drivers until today. Please update this article as it is one of the first hits on a web search.
It actually made me buy the card as an early adapter and might save others some money if it would be corrected.
Try this :
I haven't had a chance to test it myself and the KB page is still WIP, but it should include support for HD 7970.
Interesting, from the version number that driver must be from december. Also 12-1 supports all ids (and more) than this driver does, so maybe only the control file is different...
Last edited by Kano; 01-27-2012 at 09:10 PM.
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.
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...
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".
Basically there are 2 checks in your driver:
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.
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
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...
Do you mean :
Originally Posted by Kano
What's wrong with it ?