This card has a bit of an identity crisis in it's lspci entries, so I'm reporting just it's marketing name "X600 Pro"; 05:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B62 [Radeon X600 (PCIE)] (prog-if 00 [VGA]) Subsystem: ABIT Computer Corp. Unknown device 0004 Flags: bus master, fast devsel, latency 0, IRQ 12 Memory at e0000000 (32-bit, prefetchable) [size=256M] I/O ports at d000 [size=256] Memory at f1000000 (32-bit, non-prefetchable) [size=64K] [virtual] Expansion ROM at f0000000 [disabled] [size=128K] Capabilities: [50] Power Management version 2 Capabilities: [58] Express Endpoint IRQ 0 Capabilities: [100] Advanced Error Reporting 05:00.1 Display controller: ATI Technologies Inc Radeon X600(RV380) Subsystem: ABIT Computer Corp. Unknown device 0005 Flags: bus master, fast devsel, latency 0 Memory at f1010000 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 2 Capabilities: [58] Express Endpoint IRQ 0 After entering the PCI ID in the DRM accelerated XV works fine, also glxgears reports around 1400fps and emits: Unknown device ID 5B62, please report. Assuming plain R300. The card got through 10 minutes of 'I Have No Tomatoes' without any issues. Not all the necessary functions for UT2004 are supported, but the game intro sequence is displayed and seems fine (some minor discolourations aside).
(In reply to comment #0) > After entering the PCI ID in the DRM accelerated XV works fine, also glxgears > reports around 1400fps and emits: > Unknown device ID 5B62, please report. Assuming plain R300. This message should not appear with current Mesa cvs. For some reason this ID is in the dri driver (from mesa cvs), but not in drm cvs. There seem to be other ids in the dri driver but missing from drm, as well as some bogus entries in drm cvs (the 0x4e4a is probably a r (no v there) 360 9800xt and should probably be treated as r350 instead of rv350, and the 0x5d4d and 0x554F should probably both be r420 instead of r350 shouldn't they? The only (currently) difference code-wise seems to be that a r350 is treated like it doesn't have a hier-z buffer, and the r420 having one. This is wrong however anyway, r350 has hier-z buffer (unless it's a half-working die sold as a 4 pipe 9800se in which case hier-z apparently doesn't work).
(In reply to comment #1) > (In reply to comment #0) > > After entering the PCI ID in the DRM accelerated XV works fine, also glxgears > > reports around 1400fps and emits: > > Unknown device ID 5B62, please report. Assuming plain R300. > This message should not appear with current Mesa cvs. > For some reason this ID is in the dri driver (from mesa cvs), but not in drm > cvs. There seem to be other ids in the dri driver but missing from drm, as well > as some bogus entries in drm cvs (the 0x4e4a is probably a r (no v there) 360 > 9800xt and should probably be treated as r350 instead of rv350, and the 0x5d4d > and 0x554F should probably both be r420 instead of r350 shouldn't they? The only > (currently) difference code-wise seems to be that a r350 is treated like it > doesn't have a hier-z buffer, and the r420 having one. This is wrong however > anyway, r350 has hier-z buffer (unless it's a half-working die sold as a 4 pipe > 9800se in which case hier-z apparently doesn't work). We probably ought to just add all r3xx and r4xx cards from the DDX to the DRM and Mesa. Alex
Could you post more information about your system and configuration as I have not been able to get X600 Pro working (see bug 5341) and I am very keen to get this working.
Created attachment 4175 [details] [review] dri part of radeon pci id patch Ok, the dri part of the patch. It contains all ids (and only those, more on that later) which are recognized by xorg ddx (6.9). Not sure on the code changes I've done in r300_state.c but the code related to pipe count didn't look correct before (though I have some doubts it is correct now, for instance r420 (and r430, etc.) can have anything from 8 to 16 enabled pipelines (and I'd bet they could have only 1 active pixel quad, i.e. 4 pipelines) and I don't know if they would need different configuration). I've added a new rs400 family (they pretty likely NEED different treatment, for one they don't have hw tcl/vertex shader), though this won't make those work magically.
Created attachment 4176 [details] [review] drm part of radeon pci id patch add ids for drm. I've changed the family enum to look more alike the ddx/dri versions, which meant ditching the non-existant r250 and the rs250 which is too similar to rs200 to warrant its own entry. Some problems though: drm will think r300 and r350 chips have hier-z buffer, which is not correct for the 4-pipe versions (that is, they DO have hier-z buffer, but it's not working correctly). Shouldn't be a problem however, since dri will tell if hier-z is used or not too (and it isn't currently anyway) (the r4xx chips can use hier-z even with disabled pixel quads). BUT a problem may be that I have REMOVED some pci ids. There were ids only in drm. Some only in dri. Some in both drm and dri but not ddx. Pretty much all combinations imaginable, what a mess. I believe some of these ids were secondary ids and thus rightfully removed. However, there are still more ids in xorgs xf86PciInfo.h file than radeon ddx recognizes. Here's the list of the ids which are not recognized by ddx (some were in dri/drm before, but no longer): #define PCI_CHIP_RV380_3151 0x3151 #define PCI_CHIP_RV380_3152 0x3152 #define PCI_CHIP_RV380_3153 0x3153 #define PCI_CHIP_RV380_3156 0x3156 #define PCI_CHIP_RV380_3E51 0x3E51 #define PCI_CHIP_RV380_3E52 0x3E52 #define PCI_CHIP_RV380_3E53 0x3E53 #define PCI_CHIP_RV380_3E56 0x3E56 #define PCI_CHIP_RV250_Id 0x4964 #define PCI_CHIP_RV250_Ie 0x4965 #define PCI_CHIP_RV250_Le 0x4C65 #define PCI_CHIP_RV250_Ln 0x4C6E #define PCI_CHIP_R200_QI 0x5149 #define PCI_CHIP_R200_QJ 0x514A #define PCI_CHIP_R200_QK 0x514B #define PCI_CHIP_R200_QN 0x514E #define PCI_CHIP_R200_QO 0x514F #define PCI_CHIP_RV370_5461 0x5461 #define PCI_CHIP_RV370_5462 0x5462 #define PCI_CHIP_RV370_5463 0x5463 #define PCI_CHIP_RV370_5465 0x5465 #define PCI_CHIP_RV370_5466 0x5466 #define PCI_CHIP_RV370_5467 0x5467 #define PCI_CHIP_RS300_5836 0x5836 #define PCI_CHIP_RS300_5837 0x5837 #define PCI_CHIP_RV370_5B61 0x5B61 #define PCI_CHIP_RV370_5B63 0x5B63 #define PCI_CHIP_RV370_5B66 0x5B66 #define PCI_CHIP_RV370_5B67 0x5B67 Someone knows what's up with them? I.e. do these devices exist and if so, what's their proper marketing name? If they exist they need to be added to ddx, drm and dri obviously (I didn't touch ddx, I think rs400 should really get its own family there too). Also, at least one id (5d5d) seems to have a bogus name in the ddx radeon_chipset.h file. There are also ids in there which likely don't work. RS400 family for one, and I'm not sure about the firemv2200 pci neither (it has strangely just one id, I'd have guessed it would get two but apparently not - it should be just two rv280 chips afaik or does it also need a pci-pci bridge or something?).
I'm a bit worried about adding all IDs from the DDX to the DRM/Mesa as the 3D isn't reported stable on all the combinations especially with 64-bit things... I'd prefer to add them on a it works for me basis, and even that isn't probably that great.. maybe we shouldn't be enabling DRI on r300 by default...
(In reply to comment #6) > I'm a bit worried about adding all IDs from the DDX to the DRM/Mesa as the 3D > isn't reported stable on all the combinations especially with 64-bit things... > > I'd prefer to add them on a it works for me basis, and even that isn't probably > that great.. maybe we shouldn't be enabling DRI on r300 by default... The point of the patch isn't so much about adding ids only, but to make it more conistent too. It's a bit messy currently with the 3 distinct sets of ids of ddx, drm and dri (though it makes sense if ddx supports a superset). Also, I'm not sure I agree about "adding 1 by 1", with 133 (in ddx) devices you're bound to have some which are very rare (for instance some firegl cards). Personally I think all chips from a family should be added or not, except probably some "special" ones (very few of these exist afaik, like the multi-chip rv280). There is absolutely no reason some X600 card is listed there but some other (maybe X600Pro) is not imho (though you might want to enable or not based on the interface, i.e. agp or pci-e too).
(In reply to comment #7) > (In reply to comment #6) > > I'm a bit worried about adding all IDs from the DDX to the DRM/Mesa as the 3D > > isn't reported stable on all the combinations especially with 64-bit things... > > > > I'd prefer to add them on a it works for me basis, and even that isn't probably > > that great.. maybe we shouldn't be enabling DRI on r300 by default... > The point of the patch isn't so much about adding ids only, but to make it more > conistent too. It's a bit messy currently with the 3 distinct sets of ids of > ddx, drm and dri (though it makes sense if ddx supports a superset). Also, I'm > not sure I agree about "adding 1 by 1", with 133 (in ddx) devices you're bound > to have some which are very rare (for instance some firegl cards). Personally I > think all chips from a family should be added or not, except probably some > "special" ones (very few of these exist afaik, like the multi-chip rv280). There > is absolutely no reason some X600 card is listed there but some other (maybe > X600Pro) is not imho (though you might want to enable or not based on the > interface, i.e. agp or pci-e too). I have to agree with Roland. More bugs get shaken out when it's easier to test. Adding them one by one will probably leave out a lot of potentially supported cards and users will just think that their card is only supported by fglrx. besides, r300 DRI isn't yet supported in any "official" xorg release yet anyway. Other than the XPRESS chips, most other r3xx and r4xx chips seem to work pretty well.
Tried your patches (and adding only pci id for X600 pro) on a Linux 2.6.14 on i386 but had no luck at all with DRI. Still everything I have is a blank screen and a hard lock.
Created attachment 4539 [details] [review] 2 new radeon pci ids for xorg this patch adds 2 new pci ids to the xserver module. These definitely seem to exist (one is supported by catalyst, and the other one is some medion-specific mobility x700).
Created attachment 4540 [details] [review] add new pci ids for ddx this patch adds a couple of pci ids to the radeon driver, and also seperates out the rv410 and rs400 chip families (there is no separate code for these for now). Only pci ids which are known to exist are added, i.e. they are either supported by (mobility) catalyst, or there are bug entries for these chips or something. I did not remove any chips, though the list may still be incomplete - for instance I was unable to extract any ids for mac radeons (don't know if the driver contains them or not, I wasn't able to extract the archive). I have also renamed some entries if there was overhelming evidence the description wasn't quite correct. Not quite sure what to do with the 4c66 device, there is evidence it's both a (mac) m9 and a (pci) dual rv280 (firemv 2400 pci), it could be solved in ddx by using subsystem id (though for dri we'd need something different, maybe fake the id there). Since this card currently seems to lock up anyway I guess it's not really an urgent problem...
Created attachment 4541 [details] [review] drm part of the radeon pci id patch this is almost the same as the previous version, it adds all pci ids the ddx understands, and changes the family id enum to something similar to what's used in ddx/dri. The rs400 chips though should probably be removed for now (I don't think it's possible to comment them out?) as it will just lock up...
Created attachment 4542 [details] [review] dri part of new radeon pci ids and the last part, for dri. Again, same deal as the last version, with the same caveats that I don't really know what I did wrt to the small changes to the r300 driver...
Created attachment 4745 [details] [review] new radeon pci ids for drm All changes commited, except I didn't add ids newer than rv350/r350 because it might cause lockups (which is a bug of ddx, but nevertheless). New patch thus only contains the new ids.
Created attachment 4971 [details] [review] patch containing only the ids of the non-working rs400 igps I have commited the ids patch, with the exception of the rs400 igps, hopefully the chips won't just lock up with new ddx.
Should this bug be closed?
(In reply to comment #16) > Should this bug be closed? Yes, probably. Current code contains all ids known to exist at this point, except the drm which doesn't support rs400 igps. Since we don't quite know how to set them up that should be a different bug.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.