On Wed, 2002-07-24 at 19:47, hy0 wrote: > > > On Tue, 2002-07-23 at 22:54, hy0 wrote: > > > > > > If you set ForcePCIMode on any other architecture, DRI support will be > > > > disabled. > > > > (FIXME: I'm probably misunderstanding this option. How would one > > > > force an AGP Radeon card to work on the PCI bus? Or a PCI Radeon card > > > > (are there any?) to work on the AGP bus? Are there "dual-bus" > > > > integrated Radeon cards floating around, which can sit on either the > > > > PCI or AGP bus?) > > > > > > For AGP board, you can force it to use PCI GART instead of default AGP > GART. > > > This option can be used in following cases: > > > (1) You have a PCI card. > > > > PCI GART will be used automatically in that case. > > That's what I thought when I tried this a few months ago, but it turned out > not the case. When I tried a PCI 7500 on a x86 machine with dri-tnl branch > code, I was expecting RADEONDRIAgpInit to return FALSE and the driver to > fall back to PCI mode. But amazingly, it went through RADEONDRIAgpInit > successfully (on a PCI board!) and treated the board as an AGP board with > DRI enabled. The driver went through all mode initialization stuffs > correctly, and of course, finally locked up when trying to do some > accelerated 2D drawings. When I used ForcePCIMode option, I got DRI working > correctly on that PCI board. It only failed after I played some 3D games for > a while, the cause of failure might not be PCI gart related after all (I > didn't look into it). In addition, I also got the pcigart worked with an AGP > 7500 board on that x86 system. > > To automatically identify a Radeon PCI card, the PCI subsystem ID (not > device id) has the info. But this is not implemented in the current driver. > If we can't figure out a more general and reliable way to identify a PCI > card (there should be), this method (subsystem ID) can be used.
Yes, I should have said 'should' instead of 'will'. :) That's how it's supposed to work and how it works in the r128 driver. > > > (2) You have an AGP card, but the agpgart kernel driver doesn't support > the > > > AGP bridge chipset on your motherboard. > > > > Ditto. (This has pros and cons which have to be considered carefully) > > > (3) The AGP GART doesn't work correctly. > > > I'm not sure the current status of pcigart support. It didn't work > reliably > > > a few month ago. > > > > Still doesn't seem to work on x86 but works fine on alpha and powerpc at > > least. Weird. > > As said above, I actually got it worked on a x86 system with both PCI and > AGP 7500 card, just not sure how reliably it works on all other systems. I was suggesting we should consider enabling it on the dri-devel list, as we could get rid of some ugly code if we did. Unfortunately, Charl P. Botha encountered a lockup on server startup when he tried it on his notebook with an M7. > > I still think we should consider carefully if we want to document these > > options. > > IMO, this is a very useful option, especially when a lot of systems appear > to have stability problems with AGP gart. Like the VT switching lockup > problem on some systems, this option is worth to try (you may need to enable > PCIGART_ENABLE compile option first in both 2D and kernel drivers). Well, we seem to have fixed the VT switching problems. And most other AGP problems I've seen seem to be related to high transfer rates or special features like Fast Writes. > Comparing to using AGP gart, using PCI gart might slow things down by 20-30% > in 3D applications, it's still a good option if your agp gart doesn't work > reliably. You're probably right, my concerns are mainly about the CP related options. -- Earthling Michel D�nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
