> 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.
> > (2) You have an AGP card, but the agpgart kernel driver doesn't support
the
> > AGP bridge chipset on your motherboard.
>
> Ditto.
>
> > (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 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).
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.
>
> > > AGPMode
> > > Legal values for the AGPMode Option are 1 through 4 inclusive. (Note
that
> > > although 3 is accepted as a legal value, very few systems will support
> > it.)
> > > (FIXME: on PCs, does XFree86 actually override the AGP mode as set in
> > > the system BIOS?)
> >
> > During initialization, 2D driver calls into the kernel agpgart driver to
set
> > specified AGP mode. There is no 3x AGP mode. If you set it to 3, the
agpgart
> > kernel driver will set it to 2x.
>
> Actually, the value of this option is processed in this switch
> statement:
>
> switch (info->agpMode) {
> case 4: mode |= RADEON_AGP_4X_MODE;
> case 2: mode |= RADEON_AGP_2X_MODE;
> case 1: default: mode |= RADEON_AGP_1X_MODE;
> }
>
> As you can see, anything except 2 and 4 will set 1x. Even 4 and 2 may
> fall back to lower transfer rates depending on the capabilities of the
> chip and the AGP bridge. agpgart handles that.
There is no break in above switch statement. 3 LSBs will fall through.
If agpMode=7, 7 will be passed to the agpgart driver. This is not a bug,
agpgart driver
(see agpgart_be.c) will use the highest bit according to AGP bridge's
capability.
That's why I said if you use AGPMode = 3, you'll end up with 2x.
Hui
> --
> 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
>
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
