Date: Sat, 27 Apr 1996 01:00:06 -0700 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> To: hackers@freebsd.org Subject: locking user pages for dma access Message-ID: <199604270800.BAA03479@rah.star-gate.com>
next in thread | raw e-mail | index | archive | help
It seems that scsi raw i/o must locked the user page space. Can anyone shed some light on this ? This is with respect to the mode which Jim is talking about in his e-mail. At any rate, tnks in advance ! Amancio ------- Forwarded Message Return-Path: james@miller.cs.uwm.edu Received: from miller.cs.uwm.edu (miller.cs.uwm.edu [129.89.9.13]) by rah.star-gate.com (8.6.12/8.6.12) with ESMTP id HAA00879 for <hasty@rah.star-gate.com>; Thu, 25 Apr 1996 07:10:20 -0700 Received: (from james@localhost) by miller.cs.uwm.edu (8.7.3/8.7.3) id JAA19519; Thu, 25 Apr 1996 09:10:15 -0500 Date: Thu, 25 Apr 1996 09:10:15 -0500 From: Jim Lowe <james@miller.cs.uwm.edu> Message-Id: <199604251410.JAA19519@miller.cs.uwm.edu> To: hasty@rah.star-gate.com, tinguely@plains.nodak.edu Subject: Re: 30fps with vic? Cc: multimedia@freebsd.org > From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> > > My next question is: has anyone done a profile analysis on vic / h.261 to > see if vic's performance can be improved? > To answer to your question, no I have not done profiling of vic, but I have thought of ways to speed it and other algorithms like it up by making the device drivers we support for video capture a little smarter. One way vic/h.261 and other algorithms like it could be improved would be to eliminate the copying of data. I have thought of adding a ``vic'' capture mode to the meteor device driver to speed things up. Basically vic uses a buffer that looks like: xxxxxxxxxx .......... .......... .......... .......... .......... .......... xxxxxxxxxx The ``.''s are the actual video data and the ``x''s are scratch buffers for the encoding algorithm (h.261 or whatever). Vic's internal buffer is rows * cols + 2 * cols (see grabber.cc for details). If one used synchronous capture mode and could specify where the video capture driver was suppose to put the data, then one could create a buffer for vic, let the driver do the work (via dma) and avoid the copy from the mmaped area to a vic work area. This would save a fair amount of coping time and speed up the encoding rate. The time you would save is the time it takes to copy a 358x244x2x30fps from one memory location to another. Since the memory bandwidth of a Triton MB is about 40Meg/Sec (mem to mem), this copy alone would take up about 1/8 of total memory bandwidth. If you were going to create a user memory encoding capture mode, then you would want something that does 4:1:1 or 4:2:2 and dma's the data directly from the card into user space. A capture mode like this would come in handy for mpeg and jpeg encoders as well as a TV player :-). There is a bug with the Philips SAA7116 chip that would not allow range checking to work if you wanted to dma directly into user space. Also, the user memory would have to be locked into an actual physical location all the time. I am not certain if there is a FreeBSD kernel VM function that will allow one to do this. In any case, the source code is available :-). -Jim ------- End of Forwarded Message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604270800.BAA03479>