From owner-freebsd-hackers Sat Apr 27 01:00:14 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA04289 for hackers-outgoing; Sat, 27 Apr 1996 01:00:14 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA04271 for ; Sat, 27 Apr 1996 01:00:10 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with ESMTP id BAA03479 for ; Sat, 27 Apr 1996 01:00:07 -0700 Message-Id: <199604270800.BAA03479@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: hackers@freebsd.org Subject: locking user pages for dma access Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Apr 1996 01:00:06 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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 ; 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 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." > > 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