Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 Apr 2009 00:11:19 -0500
From:      Robert Noland <rnoland@FreeBSD.org>
To:        Norbert Papke <npapke@acm.org>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: dri + ATI: dramatic performance slowdown
Message-ID:  <1240463479.2142.21.camel@balrog.2hip.net>
In-Reply-To: <200904221938.12129.npapke@acm.org>
References:  <20090420152620.8f89edd5.lehmann@ans-netz.de> <200904221739.25097.npapke@acm.org> <1240448113.2142.11.camel@balrog.2hip.net> <200904221938.12129.npapke@acm.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--=-Az+JqAsHQIIOi2zukvtB
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2009-04-22 at 19:38 -0700, Norbert Papke wrote:
> On April 22, 2009, Robert Noland wrote:
> > On Wed, 2009-04-22 at 17:39 -0700, Norbert Papke wrote:
> > > 0x0/0x100000000 BIOS write-back set-by-firmware active
> > > 0x100000000/0x40000000 BIOS write-back set-by-firmware active
> > > 0xc0000000/0x40000000 BIOS uncacheable set-by-firmware active
> >
> > MTRR is failing in many cases... It seems that your BIOS is doing what
> > both of my newer machines are doing and setting a global range to
> > write-back.  I'm also guessing that 0xc0000000 is your framebuffer.=20
>=20
> Correct.  The framebuffer starts at 0xd0000000, still covered by that las=
t=20
> range.
>=20
> > We=20
> > aren't allowed to overlap either of these ranges with a write combined
> > region according to the specs.  We would have to handle
> > splitting/merging regions which we don't currently do.  I looked at thi=
s
> > just the other day, but it is reasonably complex to make that work righ=
t
> > and accommodate all of the merging/splitting of regions.
> >
> > We are allowed to use PAT on either of these types of regions to enable
> > write-combining.  The drm code already does this for some allocations
> > that are not mapped to user space.  The problem with PAT is that all
> > mappings of a given region need to have the same type and we don't
> > currently have any way to specify that for user space mappings.  This i=
s
> > fwiw, the last of Nvidia's feature requests as well.  I've started
> > looking at it, but I have a lot of learning to do on the vm system
> > still.
>=20
> Thanks for taking the time to explain.  Your posts are always very=20
> informative.  I am learning quite a lot about the complexities involved.
>=20
> There is yet another thing I don't understand.  With other graphics cards=
,=20
> including my G45 internal graphics adaptor, the /dev/agpgart device is=20
> created.  I don't see this device with the Radeon card.  Is this expected=
=20
> because it is not needed for PCIe?

That is correct.  If you have an agp based chipset, then the agp wriver
will attach to your chipset and give you an agpgart device.  All Intel
graphics chips emulate AGP, so you will always have an agpgart device.
With PCI-E based cards such as ATI or Nvidia, they don't use AGP.  In
those situations, we use a PCI GART (ati_pcigart.c) and map scatter
gather memory into the GART.  Nouveau is very similar in that respect.

robert.

> Cheers,
>=20
> -- Norbert Papke.
>    npapke@acm.org
--=20
Robert Noland <rnoland@FreeBSD.org>
FreeBSD

--=-Az+JqAsHQIIOi2zukvtB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (FreeBSD)

iEYEABECAAYFAknv+HcACgkQM4TrQ4qfROMa/ACfUiLgJ19ZQICztHMIbztsAqP0
HzwAn2eEgO/ZLrGxSFAcyShG2VhnuLfu
=5F8t
-----END PGP SIGNATURE-----

--=-Az+JqAsHQIIOi2zukvtB--




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1240463479.2142.21.camel>