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>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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? > > The current patch from your people.FreeBSD.org page, this one: > http://people.freebsd.org/~rnoland/drm-msi.patch > > > 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? > > No, it's on IRQ 16 on its own as far as I can see: > > workstation2 /home/matt # devinfo -u > Interrupt request lines: > 0 (root0) > 1 (atkbd0) > 3 (root0) > 4 (sio0) > 5 (root0) > 6 (fdc0) > 7 (ppc0) > 8 (root0) > 9 (acpi0) > 10-11 (root0) > 12 (psm0) > 13 (root0) > 14 (ata0) > 15 (ata1) > 16 (vgapci0) > 17-19 (root0) > 20 (atapci2) > 21 (ohci0) > 22 (ehci0) > 23 (atapci1) > > The board is an Asus A8N-VM-CSM. > > > 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. > > It doesn't seem to break anything. Don't forget we're not supposed to be using > glxgears or any of the demos as benchmarks - case in point: I can remember > getting framerates of 12,000+ in glxgears on a 9000 Pro a while ago on 5.x, > which suggests to me that this number is almost meaningless. Sadly, the Unix > variant of GLExcess does not include benchmark functionality as does it's > Win32 counterpart, so I am unable to extrapolate performance data by running > it. Even timing it to completion doesn't help as it doesn't run with the > fastest speed possible (it's controllable with the A and Z keys). All I run it > for is to ensure that GL doesn't bomb or fall back to software rendering on > the range of operations glxs requires. Perhaps I ought to install the > 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. > > I was actually thinking more long term. All my production boxen are 7-STABLE, > albeit with your drm patches added. It seems there's only a couple of us with > Radeon kit who are willing/daft enough to mess around with the source, so the > more of us with -CURRENT installed, the better chance we have of seeing this > stuff MFC'd into releases. That, and the fact that FBSD is a doddle to multi- > boot into however many environments you wish to run means there's no excuse > 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 > like an X1650, although I have seen an X1950Pro going for reasonable money), > 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. [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAkjzhN0ACgkQM4TrQ4qfRON0YQCeILSD8i9KZy0BGLY4lGBH8oli 7EEAnjf1Ub4hN83dKf1xf6JcUqCX9U4y =F3Mc -----END PGP SIGNATURE-----home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1223918813.98566.19.camel>