drm MSI support
Robert Noland
rnoland at FreeBSD.org
Mon Oct 13 17:27:11 UTC 2008
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20081013/9ba0d1ba/attachment.pgp
More information about the freebsd-x11
mailing list