Date: Mon, 13 Oct 2008 13:26:53 -0400 From: Robert Noland <rnoland@FreeBSD.org> To: Matt Dawson <matt@chronos.org.uk> Cc: freebsd-x11 <freebsd-x11@freebsd.org> Subject: Re: drm MSI support Message-ID: <1223918813.98566.19.camel@squirrel.corp.cox.com> In-Reply-To: <200810131801.06785.matt@chronos.org.uk> References: <1223134762.1619.32.camel@wombat.2hip.net> <200810101853.57259.matt@chronos.org.uk> <1223663456.65664.23.camel@squirrel.corp.cox.com> <200810131801.06785.matt@chronos.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-/q1/aiCKCXMqO4WDSW8a Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2008-10-13 at 18:01 +0100, Matt Dawson wrote: > On Friday 10 October 2008 19:30:56 Robert Noland wrote: > > On Fri, 2008-10-10 at 18:53 +0100, Matt Dawson wrote: > > > On Saturday 04 October 2008 16:39:21 Robert Noland wrote: > > > > When drm loads it will also report that it has enabled MSI. > > > > > > > > Please send me reports of what chips do/don't work. > > > > > > Yep, looking good on an X850XT: > > > > > > drm0: <ATI Radeon R480 X850 XT> on vgapci0 > > > info: [drm] MSI enabled 1 message(s) > > > info: [drm] Setting GART location based on new memory map > > > info: [drm] Loading R400 Microcode > > > info: [drm] Num pipes: 4 > > > info: [drm] writeback test succeeded in 1 usecs > > > drm0: [ITHREAD] > > > > > > Pre-MSI > > > 8800 FPS in texcyl demo > > > 4800 FPS in glxgears > > > 602 FPS in terrain demo > > > glxs completed OK > > > > > > With MSI > > > 7450 FPS in texcyl demo > > > 4450 FPS in glxgears > > > 598 FPS in terrain demo > > > glxs completed OK > > > > I assume that you are using drm-msi-3.patch? >=20 > The current patch from your people.FreeBSD.org page, this one: > http://people.freebsd.org/~rnoland/drm-msi.patch >=20 > > I'm a little curious why performance seems slightly lower with msi. We > > do have to re-arm the interrupt on radeons. Is the interrupt shared in > > the non-msi case? >=20 > No, it's on IRQ 16 on its own as far as I can see: >=20 > workstation2 /home/matt # devinfo -u = =20 > Interrupt request lines: = =20 > 0 (root0) = =20 > 1 (atkbd0) = =20 > 3 (root0) = =20 > 4 (sio0) = =20 > 5 (root0) = =20 > 6 (fdc0) = =20 > 7 (ppc0) = =20 > 8 (root0) = =20 > 9 (acpi0) = =20 > 10-11 (root0) = =20 > 12 (psm0) = =20 > 13 (root0) = =20 > 14 (ata0) = =20 > 15 (ata1) = =20 > 16 (vgapci0) = =20 > 17-19 (root0) = =20 > 20 (atapci2) = =20 > 21 (ohci0) = =20 > 22 (ehci0) = =20 > 23 (atapci1) >=20 > The board is an Asus A8N-VM-CSM. >=20 > > Yes, MSI seems to only be available on PCI-E radeons, so the only point > > of testing on these cards is to ensure nothing is broken. >=20 > It doesn't seem to break anything. Don't forget we're not supposed to be = using=20 > glxgears or any of the demos as benchmarks - case in point: I can remembe= r=20 > getting framerates of 12,000+ in glxgears on a 9000 Pro a while ago on 5.= x,=20 > which suggests to me that this number is almost meaningless. Sadly, the U= nix=20 > variant of GLExcess does not include benchmark functionality as does it's= =20 > Win32 counterpart, so I am unable to extrapolate performance data by runn= ing=20 > it. Even timing it to completion doesn't help as it doesn't run with the=20 > fastest speed possible (it's controllable with the A and Z keys). All I r= un it=20 > for is to ensure that GL doesn't bomb or fall back to software rendering = on=20 > the range of operations glxs requires. Perhaps I ought to install the=20 > linuxulator and slam Doom3 on there to run a timedemo to test this stuff? Very true, gears is not a benchmark... I know anholt used to suggest that things like that were more suited to be real world benchmarks. > > > Sorry for the delay. I had to set up -CURRENT on this box as it looks > > > like it will be handy to test these Radeons from time to time. > > > > Yes, particularly for newer chips being on -CURRENT is going to be > > helpful. I can make patches for STABLE in most cases, but I'm already > > working with several different repos / code branches, so the quickest > > best way to get the new bling is going to be on -CURRENT. >=20 > I was actually thinking more long term. All my production boxen are 7-STA= BLE,=20 > albeit with your drm patches added. It seems there's only a couple of us = with=20 > Radeon kit who are willing/daft enough to mess around with the source, so= the=20 > more of us with -CURRENT installed, the better chance we have of seeing t= his=20 > stuff MFC'd into releases. That, and the fact that FBSD is a doddle to mu= lti- > boot into however many environments you wish to run means there's no excu= se=20 > not to ;) Yes, the key bit lately has been that I'm taking advantage of some newer kernel features and so I have to coordinate MFCs. I think that what we have in HEAD now is ok to MFC, though I have a couple of patches that I'm getting ready to commit that will also be needed, at least once Xorg-7.4 hits the tree. > I'm going to try to get my hands on an R500 soon (probably something low-= end=20 > like an X1650, although I have seen an X1950Pro going for reasonable mone= y),=20 > so I should be able to at least test R200-500 based cards. Great, competent testers are a huge plus. I know one of my other testers is running a x1650 and MSI also seems to be working correctly for him, though I did have to slip him an advance patch of xorg-7.4 to get mesa going. robert. --=-/q1/aiCKCXMqO4WDSW8a Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAkjzhN0ACgkQM4TrQ4qfRON0YQCeILSD8i9KZy0BGLY4lGBH8oli 7EEAnjf1Ub4hN83dKf1xf6JcUqCX9U4y =F3Mc -----END PGP SIGNATURE----- --=-/q1/aiCKCXMqO4WDSW8a--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1223918813.98566.19.camel>