Date: Thu, 7 Dec 1995 14:02:38 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: tinguely@plains.nodak.edu (Mark Tinguely) Cc: terry@lambert.org, hackers@FreeBSD.ORG Subject: Re: Matrox Meteor & pal... Message-ID: <199512072102.OAA05586@phaeton.artisoft.com> In-Reply-To: <199512072052.OAA22145@plains.nodak.edu> from "Mark Tinguely" at Dec 7, 95 02:52:43 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512072102.OAA05586>