Subject: Re: fixes for i915 AGP
To: Blair Sadewitz <blair.sadewitz@gmail.com>
From: Eric Anholt <eric@anholt.net>
List: tech-x11
Date: 05/15/2007 13:05:53
--=-2ra1hun9+0sDpEAXpqon
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Mon, 2007-05-14 at 17:25 -0400, Blair Sadewitz wrote:
> The attached patch does the following:
>=20
> -- Sets the AGP aperture based upon its actual size, not the MSAC bit.
> -- Allows for the 10-page allocation xf86-video-intel-2.0 wants.
> -- Allows for up to 64MB of stolen memory, should the adapter want it.
>  Mine only ever seems to want 8MB, though.
>=20
> Also, anyone who has a "DVMT" option in their BIOS (or anything
> resembling "dynamic" memory allocation) should set this to "off" or
> "fixed".  If this is not done, you *will* experience crashes in X--at
> least with a 945GM (I have tested this extensively on an Intel D945GTP
> motherboard).
>=20
> There's also new DRM memory manager code which would help with
> performance if it were merged in.
> Right now, the performance is lackluster to say the least, i.e. slower
> than my Radeon X800GTO *without* DRI.  The advantage, of course, is
> the CPU utilization.
>=20
> If those with i915s could please test this, I'd appreciate it, as I'd
> like to see if it breaks anything.  Otherwise, it will probably just
> be committed at some point.

On i915/i945, you want to be using the actual aperture resource's size
(BAR 2), not the GTT resource's size (BAR 3), to detect the aperture
size.  The GTT resource is supposed to be 256kb on this hardware,
regardless of the size of the aperture and the size of the GTT
allocation out of stolen memory.

My comment about physical allocations not binding enough pages was at:
	if (mem->am_type =3D=3D 2) {
		WRITEGTT(offset, mem->am_physical | 1);
		mem->am_offset =3D offset;
		mem->am_is_bound =3D 1;
		return 0;
	}

You've got an allocation of one to ten pages (in current X
implementations), but you only write one GTT entry referencing a single
page.

Also, that unmap you re-enabled looks like it should break everything
other than i915-class hardware.  Am I reading things wrong?

An unrelated suggestion is to, at startup, bind every page other than
stolen memory to a single dummy page.  When unbinding, don't mark the
page as invalid, and instead just point it at the dummy page again.
This is a bit of a seatbelt that will help keep driver mistakes (or
strange hardware mistakes if they exist) from referencing invalid GTT
entries and potentially wedging the chip.

--=20
Eric Anholt                             anholt@FreeBSD.org
eric@anholt.net                         eric.anholt@intel.com


--=-2ra1hun9+0sDpEAXpqon
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)

iD8DBQBGShKhHUdvYGzw6vcRAhWJAJ9IuTEgxcA0SAzZZykyRYwR2S/XBQCcC+Wf
4L3fqqh8F6UzdzcIzPr3ixE=
=fsdZ
-----END PGP SIGNATURE-----

--=-2ra1hun9+0sDpEAXpqon--