Date: Sat, 03 Feb 1996 11:21:02 -0800 From: Paul Traina <pst@shockwave.com> To: Sujal Patel <smpatel@wam.umd.edu> Cc: Thomas Davis <Thomas.Davis@mnscorp.com>, multimedia@freebsd.org, linux-connectix@crynwr.com Subject: Re: real-world experience with QuickCam in the kernel Message-ID: <199602031921.LAA02828@precipice.shockwave.com> In-Reply-To: Your message of "Sat, 03 Feb 1996 05:18:08 EST." <Pine.BSF.3.91.960203050941.256A-100000@xi.dorm.umd.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
From: Sujal Patel <smpatel@wam.umd.edu> Subject: Re: real-world experience with QuickCam in the kernel On Sat, 3 Feb 1996, Paul Traina wrote: > I found a couple of small bugs in my driver (no big deal), but I'm > now convinced that without some serious head-scratching, doing this > in kernel mode is a big lose. In fact, due to the extra copies and > syscall overhead, I'm at least 5% slower than xfqcam. I guess that means I should go to sleep now? :-) This seems almost *inconceivable* that the driver could be slower :( Think about it, same I/O operations need to be done, and when you open /dev/io, you're doing them directly from user-mode. > It looks like the QuickCam has no serious way of generating interrupts, > and the spin loop synchronization locks up the system during transfers of > a frame. This is unnoticeable while doing single frame captures, but > completely sucks when doing movies. Yeah, this really bites. If only they wired up the ACK line, and sent an interrupt when it was ready to send some data. Even then, taking an interrupt per nibble would be ugly. > At this point, I think it's best if we could concentrate on documenting > the protocol and working out an _optimized_ library and standard API > for tools. By optimized, I mean that xfqcam's bit-shifting operations > run significantly faster than the standard ones everyone else is using. > Paul's code seems to run significantly faster, which is strange given > that his stuff is less unwound, and I see at least a few speed fixups > I could make over his stuff without much effort. Why not just write those scan routines in assembly... Seriously, it's not that much work, and you'll be absolutely sure that they are efficent. I was thinking that too, but before I drifted off to sleep, I realized that there's no need to put more effort into it. We can use "free" time during the spin loop to do the slow stuff. I bet if we unwound stuff a bit more, we could do our calcuations as slowly as we want. Watch: current proposed ------- -------- command 1 command 1 sync/wait 1 sync/wait 1 conversion ops 1 command 2 command 2 conversion ops 1 sync/wait 2 sync/wait 2 conversion ops 2 command 3 command 3 conversion ops 2 sync/wait 3 sync/wait 3 ... ... Since we're gated by the speed of the spin loop anyway, we may as well hit the "go" button as soon as possible and then do the stuff that's slow on the processor. You could probably code the shifts in LISP and it would still complete before the sync/wait completed. :-) > I'm really unhappy and upset about this because one of my goals through > doing this with the kernel is we would not require special privs for > accessing I/O memory. Unless we can figure out a way to handle this > without kernel threads or interrupt support comming back from the QuickCam, > I think this may spell death for all kernel drivers (at least for motion > use...). I dunno-- 5% speed loss vs a clean interface.... It's a though call. If it was just that, I'd be fine, but the machine is pretty much unusable when my modified xfqcam is running since we're doing spin-waits in the kernel. The cursor moves in jerky-bits. At least in user mode, other threads of execution get to run. > I'm going to bail for tonight and sleep on this. If someone has a good > idea for avoiding spin-loops while in the kernel, I'm all ears. Maybe > I'll have a better idea in the morning. I can't think of anything to avoid the loops.. You need to read the data from the QuickCam the INSTANT it offers it. Are you sure it's instant? I think we have several tens of microseconds of slack here, don't we? If not, then my proposal for reordering the xfer routines won't fly. Also-- For everyone: I finally got around to testing Bi-dir; Bi-directional modes are not working in any way (my code, xfqcam, and pst's driver). Any ideas? If not, I'll figure it out tommorow. I found a bug in my code comparing it to xfqcam, but I still haven't fixed my hardware to do bidir. Sujal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602031921.LAA02828>