Re: Fast memcpy in kernel space

From: Robert Redelmeier (redelm_at_ev1.net.invalid)
Date: 08/12/03 

Date: Tue, 12 Aug 2003 11:51:43 GMT

Jayr Al-Dyn <jayraldyn@jayraldyn.net> wrote:
> I am writing a kernel module that needs to access and copy framebuffer
> zones from /dev/fb*. Currently, I am trying to make it run faster, so I
> coded some controls to know where it is wasting more CPU. I am surprised
> by the results, because the most expensive routine is the one that does a
> memcpy from an mmaped framebuffer to a local buffer.
>
> So, my question is: is there any way to memcpy faster in kernel space?

Fast memcopy is an ASM FAQ. It is highly CPU dependant, and
there are some nice routines for AMD and others in bcopy(),
heavily used by the CoW memmory management in the kernel.

But you're asking about vidram, and that's a whole different
subject. You want to copy from system RAM to VRAM across
the AGP. This is speed limited to 64bits*66 MHz and the CPU
code hardly matters with this bottleneck.

Worst of all, you appear to be _reading_ the vidram!
The hardware isn't designed for it. Vidram has _heavy_
demands on it, and will probably only allow reading during
horizontal retraces. If even then. I'd be surprised if you
could read vidram at more than 10 MB/s while system RAM should
run 200+ MByte/s.

If you need to know what's in vidram, keep a copy in
system RAM. vidram is WOM (write only memory).

The way that games, etc get good performance is they do
not use the CPU to transfer bitmaps. They instruct the
GPU (on the vidcard) to do the bitblitting. Then the AGP
can run at 4x, and the CPU is free for other tasks.

Most unfortunately, there is NO STANDARD way to instruct
the GPU. The mfrs do not even release GPU docs/datasheets.
They do release middleware like DirectX libraries.

-- Robert