Skip site navigation (1)Skip section navigation (2)
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>