From owner-freebsd-hackers Sat Nov 17 4:10:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from orange.csi.cam.ac.uk (orange.csi.cam.ac.uk [131.111.8.77]) by hub.freebsd.org (Postfix) with ESMTP id 7073C37B417; Sat, 17 Nov 2001 04:10:52 -0800 (PST) Received: from dr263.sel.cam.ac.uk ([131.111.129.153] helo=there ident=dr) by orange.csi.cam.ac.uk with smtp (Exim 3.22 #1) id 1654Ip-0000eO-00; Sat, 17 Nov 2001 12:10:31 +0000 Content-Type: text/plain; charset="iso-8859-1" From: David Rufino To: Vladimir Kushnir Subject: Re: -STABLE NVidia drivers Date: Sat, 17 Nov 2001 12:10:38 +0000 X-Mailer: KMail [version 1.3.1] References: <20011117022144.M4970-100000@kushnir1.kiev.ua> In-Reply-To: <20011117022144.M4970-100000@kushnir1.kiev.ua> Cc: freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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-hackers" in the body of the message