Date: Thu, 30 Nov 2000 22:51:29 +0100 From: "Karel J. Bosschaart" <karelj@wop21.wop.wtb.tue.nl> To: Steve Reid <sreid@sea-to-sky.net> Cc: freebsd-multimedia@FreeBSD.ORG Subject: Re: XF86-4, Linux binaries, DRI? Message-ID: <20001130225129.A82445@wop21.wop.wtb.tue.nl> In-Reply-To: <20001126205915.A40068@grok>; from sreid@sea-to-sky.net on Sun, Nov 26, 2000 at 08:59:15PM -0800 References: <sreid@sea-to-sky.net> <200011230505.eAN553G15445@bloop.craftncomp.com> <20001124024742.A355@grok> <20001124042124.A367@grok> <20001124164516.A396@grok> <20001125200845.A8256@myhakas.matti.ee> <20001126205915.A40068@grok>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Nov 26, 2000 at 08:59:15PM -0800, Steve Reid wrote: > On Sat, Nov 25, 2000 at 08:08:45PM +0200, Vallo Kallaste wrote: > > Can we have a writeup? :-) > > I don't recall everything that I did (I should've written it down) but > here's the important stuff. Feel free to send me questions. > Thanks for summarizing! [lots of instructions] > check any time you have problems. Also, if you are using 4.1-R (and > probably other versions as well) you will see in dmesg (and at the > console and in /var/log/messages) messages about an ioctl not being > implemented, and indirect rendering will be the result. You need to > update your /sys/i386/linux/linux_ioctl.* with the files Stephen > Hocking posted, with paths modified for the FreeBSD 4.x kernel source > layout, along with the *drm.h from the XF86-4 source distribution. For > simplicity just grab my tarball of the relevant files from here: > http://sea-to-sky.net/~sreid/fbsdlinux_dri.tar.gz With these changes > you MUST now load your linux.ko very early in the boot process, so set > linux_enable="NO" in /etc/rc.conf and add the line linux_load="YES" to > your /boot/loader.conf. > It took me some time to find the correct place, I was getting the old linux.ko all the time... but finally found it. I guess those files moved recently to the new place (I have 4.2-Stable). > I must mention though, all is not well with my system in DRI-land. > OpenGL screensavers don't work properly: major flicker, as if there is > no double buffering. They work fine in a window though. I think I've Hmm, I don't have any flickering. But I have a G400 and didn't download anything from Matrox. I tried 3 Linux OpenGL programs: Quake3 demo version, Unreal Tournament (Loki version 4.36) and the Sin demo. In short: Quake3 works with some quirks, but UT and Sin fail. > - The graphics config screen is rather schizophrenic. Some of the > settings (like the texture detail slider) don't seem to have the > changes saved at all. Also, after making a change I get indirect > rendering until I completely exit and restart quake. > Well, my config screen looks OK, but when changing a video setting it also falls back to software rendering until restarted. Once it's running it runs quite well, although I'm not very impressed with the performance; I didn't have the time yet to do some decent FPS tests, but it feels like Voodoo2-SLI (which is still in the machine next to the G400 :-). Hmmm, would be about time to get the G400 running in Windows to see what it is supposed to do but I always find the installation procedures so complicated ;-P (installing drivers in Windows is something like Russian Roulette to me). > - With the "normal" graphics setting, my new config (G450/DRI) is > lots slower than my old config (G200/Utah). It's okay at other settings I didn't succeed in getting the G400 running with Utah. It's resulting in a DMA timeout (posted to this list) and I didn't find out how to resolve that problem. Maybe I'll have a look at it sometime. > (vertex lighting & low geometric detail), but the graphics seem jerky > even when the on-screen FPS counter (/cg_drawfps 1) shows over 80 fps. > It looks almost as if the position of the verticies is calculated with > really low-precision math. This is most noticable when looking at the > corner of two walls and sidestepping back and forth. After another > look, I think this is texture-related. On q3dm7 (single-play, no bots) > standing where the quad spawns and looking at the wall with the fire, > sidesteping back and forth across the whole width of the room, it looks > like different parts of the textures are jittering back and forth > independently of each other. > I'll need another look... but until now I didn't notice anything weird in Quake with textures or anything. > - The mouse control is barely playable. If I move my trackball too fast > I hardly turn at all; a quick 180 is completely impossible. The overall > responsiveness varies a lot. I needed to crank the mouse sensitivity > setting up to over 12 or so which makes the control very jittery, > although the "smooth mouse" option helps that a bit. > In my case I needed to set my mouse on the lowest sensitivity for a decent gameplay... it seems rather normal. It happened a couple of times though that my mouse was suddenly dead in the menu, while the arrow keys were still very responsive. Maybe it's related to DGA, I saw that I had it disabled so enabled it then. > - Q3 forgets my cdkey immediately after I enter it. This makes on-line > play impossible. Since I don't have a cdkey (demo version) I couldn't check that. Concerning UT and Sin: UT either falls back to software rendering or "hangs", and Sin complained about some stuff that could not be found. I'll have to look more carefully into it to get something useful out of it. For now I'm just glad that at least Quake works more or less :-). Karel. 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?20001130225129.A82445>