Date: Wed, 1 Dec 1999 16:12:20 -0800 From: Steve Reid <sreid@sea-to-sky.net> To: freebsd-multimedia@freebsd.org Subject: GLX, Matrox G200/G400, MTRR Message-ID: <19991201161220.A381@grok.localnet>
next in thread | raw e-mail | index | archive | help
I've whipped up a small kernel module that improves the performance of Utah GLX [http://glx.on.openprojects.net/] with the Matrox cards. It does this by setting write combining on the system heap. This assumes that you've set aside some memory for GLX by compiling a kernel with the MAXMEM option (which, if you care about mga 3D performance, you'll do). I'm pretty sure this only affects the Matrox cards. As far as I know the code for the NVidea cards doesn't use system heap. Also, this will probably only work on systems with a single Pentium Pro/II/III, Celeron, or (I think) Athlon processor. I don't think it works on the K6 series. Q3 timedemo, Before: DEMO001: 1346 frames, 66.7 seconds: 20.2 fps DEMO002: 1399 frames, 73.3 seconds: 19.1 fps Q3 timedemo, After: DEMO001: 1346 frames, 57.9 seconds: 23.3 fps DEMO002: 1399 frames, 62.4 seconds: 22.4 fps The source for the kernel module is at http://sea-to-sky.net/~sreid/mtrrhack.tar.gz (1281 bytes) Beware, it doesn't have a user interface. You'll have to hand-edit the .c file and adjust things in the mtrr_settings struct for your system. It's currently set for my system, which is 64 MB total with the top 8 MB set aside for GLX (options "MAXMEM=(56*1024)" in my kernel config, plus relevant stuff in my glx.conf). Edit the .c file, type "make", then (as root) "kldload ./mtrrhack.ko". You can immediately "kldunload mtrrhack" if you want; the MTRRs will remain set. If you can't figure this out for yourself, email me with your memory configuration and I'll send you the required changes in the .c file. This module only sets the MTRRs for one CPU, which will very likely cause problems if you try to use it on an SMP machine. It also doesn't flush the caches or do other cleanup while messing with the MTRRs, but this seems to be okay because (if you edited the .c file properly) the memory used by the OS is set write-back both before and after the MTRRs are changed. Technical trivia: This program sets the variable-range MTRRs, not to be confused with the fixed-range MTRRs set by "fastvid" (and now handled by the BIOS). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991201161220.A381>