Date: Sat, 17 Nov 2001 12:10:38 +0000 From: David Rufino <dr263@cam.ac.uk> To: Vladimir Kushnir <vkushnir@Alfacom.net> Cc: freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: -STABLE NVidia drivers Message-ID: <E1654Ip-0000eO-00@orange.csi.cam.ac.uk> In-Reply-To: <20011117022144.M4970-100000@kushnir1.kiev.ua> References: <20011117022144.M4970-100000@kushnir1.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 17 November 2001 12:41 am, you wrote: > Hi, Hey, > Well, since nobody seems to be interested (I can't for the life of mine > understand why), thanks and a couple of (perhaps silly) questions. > > > i) any plans on porting to -CURRENT? On GLX stuff? And does it work with > DEVFS? I have no plans to port to -CURRENT, as I'm perfectly happy running -STABLE; but perhaps someone else might be interested. GLX stuff should be coming soon. It all depends on when the nvidia ppl will produce some object binaries which I can link to produce the GL libraries, and glx extension module. I haven't tried with DEVFS to be honest, but there doesn't seem to be any reason why it shouldn't work. > ii) any problems that should be addressed? The long-running ioctl issue which is reportedly going to be fixed by the nvidia guys in 2 releases time. I have a perfectly good (if annoyingly hacky) workaround in the kernel module itself, though, so it's not a problem i would concern myself with too much. Having said that it might be worth getting someone to add a flag to the cdevsw structure that ensures the userland address is always passed to the kernel driver. There's also the problem with mmap allocation, which would take a while to explain, needless to say I have another hacky workaround, which limits the number of allocation buffers to 7. Perhaps a better way would be to use an anonymous mmap followed by mlock, and then map it into kernel space (which I don't know how to do). Also there may well be problems with 2 processes simultaneously accessing the same /dev/nvidia0 device, since there's no simple way, in the current (-STABLE and -CURRENT :) framework, to differentiate between two distinct instances. This might be changing in -CURRENT soon. > iii) (sorry, this goes before reading your code) is your port very > different from Matthew Dodd's (which I run right now)? A lot of Matthew Dodd's code is derived from mine, especially the memory allocation stuff. The only real difference is that he modifies nvidia_drv.o, while I try to provide an almost full emulation of the linux kernel module, without modifying anything in userspace. The reason being that LD_PRELOAD doesn't work in the case of static binaries, and just modifying nvidia_drv.o won't work in all cases because the same code for using /dev/nvidia? is repeated in the shared libraries (apparently). Also, I think I'm correct in saying that his code assumes that there are only 3 allocation mmap calls made in the entire session, which is true if you're just running a normal 2D session, but XVideo (I think) uses an additional allocation call and glx likewise.. > iv) any help you need? A few things on my wishlist :> It would be very nice if an ELF wizard could magically hack the linux libglx driver and libGL libs to work on FreeBSD . If someone could figure out why it crashes when switching to console, I would also be very grateful. Someone to look at my code and sanity check it might be useful. > v) thanks again, this kind of work is a miracle which no-one seems to > have noticed - usage for alien _kernel_ modules is not something one can > see very often. thank you! > Regards, > Vladimir Thanks, David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1654Ip-0000eO-00>