Prev: NdisDeregisterDeviceEx
Next: Need help to start learning device driver development
From: Rich on 14 Apr 2008 15:41
My device driver provides contiguous memory buffers to its vidcap h/w via
AllocateCommonBuffers. Is there a better way to make these capture buffer
contents visible to the user-level app than by copying their contents out to
user-space?

The kernel driver allocates common buffers, and the user-level app allocates
user buffers of the same size. The driver copies the common buffer contents
out to the user-space buffers on receipt of an ioctl, after performing a
probeandlock and map on the user-buffer MDL.

Thanks,
Rich
From: Tim Roberts on 18 Apr 2008 01:11
Rich <Rich(a)discussions.microsoft.com> wrote:
>
>My device driver provides contiguous memory buffers to its vidcap h/w via
>AllocateCommonBuffers. Is there a better way to make these capture buffer
>contents visible to the user-level app than by copying their contents out to
>user-space?

Not necessarily. Today's CPUs do big block copies pretty darned quickly.

>The kernel driver allocates common buffers, and the user-level app allocates
>user buffers of the same size. The driver copies the common buffer contents
>out to the user-space buffers on receipt of an ioctl, after performing a
>probeandlock and map on the user-buffer MDL.

It depends on the timing. You could, for example, probe and lock when the
user mode request comes in, and pass those buffer addresses to your
hardware instead of your common buffer. The "avshws" sample simulates
this.

If your hardware design requires the common buffer, then you have very
little choice except to copy.

Are you using an entirely custom interface, or is this an AVStream driver?
--
Tim Roberts, timr(a)probo.com
Providenza & Boekelheide, Inc.
From: Rich on 18 Apr 2008 17:42
I started the driver skeleton from the avshws sample, but it's so far a
custom interface.

The capture h/w requires a contiguous destination buffer, but as the
majority of my driver experience is in embedded systems with linear memory
models (vxworks), I'm not sure if a mapped/probe and locked user buffer
counts as a "contiguous" buffer from the h/w's perspective.

The only capture method I've gotten working so far is using
AllocCommonBuffer to program the capture buffer addresses, and I have then
been able to copy the common buffer contents with memcpy to userspace for the
app.

Any further insight would be appreciated,
Rich

"Tim Roberts" wrote:

> Rich <Rich(a)discussions.microsoft.com> wrote:
> >
> >My device driver provides contiguous memory buffers to its vidcap h/w via
> >AllocateCommonBuffers. Is there a better way to make these capture buffer
> >contents visible to the user-level app than by copying their contents out to
> >user-space?
>
> Not necessarily. Today's CPUs do big block copies pretty darned quickly.
>
> >The kernel driver allocates common buffers, and the user-level app allocates
> >user buffers of the same size. The driver copies the common buffer contents
> >out to the user-space buffers on receipt of an ioctl, after performing a
> >probeandlock and map on the user-buffer MDL.
>
> It depends on the timing. You could, for example, probe and lock when the
> user mode request comes in, and pass those buffer addresses to your
> hardware instead of your common buffer. The "avshws" sample simulates
> this.
>
> If your hardware design requires the common buffer, then you have very
> little choice except to copy.
>
> Are you using an entirely custom interface, or is this an AVStream driver?
> --
> Tim Roberts, timr(a)probo.com
> Providenza & Boekelheide, Inc.
>
From: Tim Roberts on 19 Apr 2008 20:17
Rich <Rich(a)discussions.microsoft.com> wrote:
>
>I started the driver skeleton from the avshws sample, but it's so far a
>custom interface.
>
>The capture h/w requires a contiguous destination buffer, but as the
>majority of my driver experience is in embedded systems with linear memory
>models (vxworks), I'm not sure if a mapped/probe and locked user buffer
>counts as a "contiguous" buffer from the h/w's perspective.

No, it doesn't. They will be contiguous in virtual space, but not in
physical space. If the hardware requires contiguous physical space, then
you must use a common buffer, and that means you must copy.

>The only capture method I've gotten working so far is using
>AllocCommonBuffer to program the capture buffer addresses, and I have then
>been able to copy the common buffer contents with memcpy to userspace for the
>app.

Yep, that's what you need.
--
Tim Roberts, timr(a)probo.com
Providenza & Boekelheide, Inc.
From: Ben Voigt [C++ MVP] on 8 May 2008 11:50
Tim Roberts wrote:
> Rich <Rich(a)discussions.microsoft.com> wrote:
>>
>> I started the driver skeleton from the avshws sample, but it's so
>> far a custom interface.
>>
>> The capture h/w requires a contiguous destination buffer, but as the
>> majority of my driver experience is in embedded systems with linear
>> memory models (vxworks), I'm not sure if a mapped/probe and locked
>> user buffer counts as a "contiguous" buffer from the h/w's
>> perspective.
>
> No, it doesn't. They will be contiguous in virtual space, but not in
> physical space. If the hardware requires contiguous physical space,
> then you must use a common buffer, and that means you must copy.

It should be possible to have zero-copy by mapping the buffer into usermode
directly though. Probably need to create a kernel mapping object and have
the usermode call VirtualAlloc(MEM_RESERVE) and MapViewOfFile. Just make
sure you don't trust the content of memory that can be written from
userspace.


 |  Next  |  Last
Pages: 1 2
Prev: NdisDeregisterDeviceEx
Next: Need help to start learning device driver development