From owner-freebsd-hackers Thu Dec 7 13:05:20 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA21235 for hackers-outgoing; Thu, 7 Dec 1995 13:05:20 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA21227 for ; Thu, 7 Dec 1995 13:05:13 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA05586; Thu, 7 Dec 1995 14:02:38 -0700 From: Terry Lambert Message-Id: <199512072102.OAA05586@phaeton.artisoft.com> Subject: Re: Matrox Meteor & pal... To: tinguely@plains.nodak.edu (Mark Tinguely) Date: Thu, 7 Dec 1995 14:02:38 -0700 (MST) Cc: terry@lambert.org, hackers@FreeBSD.ORG In-Reply-To: <199512072052.OAA22145@plains.nodak.edu> from "Mark Tinguely" at Dec 7, 95 02:52:43 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > Out of curiousity, what would really be invovled in running a driver in > > its own linear address space so that this wasn't a problem? > > > > Or must it be physically contiguous? > > the card uses DMAs to physical memory, and needs physically contiguous memory > for each field. we interlace the field into one buffer to make a faster > user application use. so packed mode could use two seperate smaller contiguous > buffers and planer YUV could be split into 3 YUV (interlaced but seperate > Y, U, and V buffers) or 6 (non-interlace Y, U, V buffers) contiguous buffers. > > In the massive frame capture mode we could go with an array of smaller > contiguous chunks. > > I don't think breaking these up is wise because when you look at grabbing at > a high frame rate you want to keep driver and user processing to a minimum. > Besides, there is no guarrentee we can get the smaller chunks contiguous > after several minutes of allocations/free. Actually, you need a zone allocator that "knows" about high, medium, and low persistance allocations. The video capture buffer would be higher persistance. You *could* brute-force it by faulting the underlying pages to new locations out of LRU sequence, which would make the allocation slow the machine momentarily following processing, but guarantee you a nice flat contiguous window. This would require some addition VM hooks for the allocation process. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.