Bug 5413 - Radeon DRM appears capable of driving 5B62; X600 Pro
Radeon DRM appears capable of driving 5B62; X600 Pro
Status: RESOLVED FIXED
Product: DRI
Classification: Unclassified
Component: DRM/other
XOrg git
x86 (IA32) Linux (All)
: high normal
Assigned To: Default DRI bug account
: patch
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-24 12:53 UTC by Tony Vroon
Modified: 2006-07-29 15:16 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
dri part of radeon pci id patch (11.78 KB, patch)
2005-12-28 13:07 UTC, Roland Scheidegger
no flags Details | Splinter Review
drm part of radeon pci id patch (11.46 KB, patch)
2005-12-28 13:36 UTC, Roland Scheidegger
no flags Details | Splinter Review
2 new radeon pci ids for xorg (1.04 KB, patch)
2006-02-02 11:12 UTC, Roland Scheidegger
no flags Details | Splinter Review
add new pci ids for ddx (10.90 KB, patch)
2006-02-02 11:27 UTC, Roland Scheidegger
no flags Details | Splinter Review
drm part of the radeon pci id patch (12.58 KB, patch)
2006-02-02 11:32 UTC, Roland Scheidegger
no flags Details | Splinter Review
dri part of new radeon pci ids (11.95 KB, patch)
2006-02-02 11:49 UTC, Roland Scheidegger
no flags Details | Splinter Review
new radeon pci ids for drm (5.78 KB, patch)
2006-02-25 20:59 UTC, Roland Scheidegger
no flags Details | Splinter Review
patch containing only the ids of the non-working rs400 igps (1.58 KB, patch)
2006-03-17 12:41 UTC, Roland Scheidegger
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Tony Vroon 2005-12-24 12:53:22 UTC
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).
Comment 1 Roland Scheidegger 2005-12-26 11:00:08 UTC
(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). 
Comment 2 Alex Deucher 2005-12-26 14:48:07 UTC
(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
Comment 3 Markus Niemistö 2005-12-28 07:05:48 UTC
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.
Comment 4 Roland Scheidegger 2005-12-28 13:07:18 UTC
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.
Comment 5 Roland Scheidegger 2005-12-28 13:36:43 UTC
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?).
Comment 6 Dave Airlie 2005-12-28 13:41:33 UTC
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...
Comment 7 Roland Scheidegger 2005-12-29 12:07:41 UTC
(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).
Comment 8 Alex Deucher 2005-12-29 14:45:49 UTC
(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.
Comment 9 Markus Niemistö 2005-12-29 19:02:43 UTC
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. 
Comment 10 Roland Scheidegger 2006-02-02 11:12:45 UTC
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).
Comment 11 Roland Scheidegger 2006-02-02 11:27:16 UTC
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...
Comment 12 Roland Scheidegger 2006-02-02 11:32:49 UTC
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...
Comment 13 Roland Scheidegger 2006-02-02 11:49:32 UTC
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...
Comment 14 Roland Scheidegger 2006-02-25 20:59:09 UTC
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.
Comment 15 Roland Scheidegger 2006-03-17 12:41:30 UTC
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.
Comment 16 Erik Andren 2006-07-28 10:12:18 UTC
Should this bug be closed?
Comment 17 Roland Scheidegger 2006-07-29 15:16:59 UTC
(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.