[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [linrad] VESA

I found this on Red Hats web sight:
http://www.redhat.com/archives/shrike-list/2003-April/msg03037.html
Henry

-----Original Message-----
From: owner-linrad@xxxxxxxxxxxxxxxxxxxxxx [mailto:owner-linrad@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Leif Åsbrink
Sent: Monday, April 12, 2004 2:56 PM
To: Linrad
Subject: [linrad] VESA


Hi All,

The VESA driver of svgalib-1.4.3 is very slow because
Linrad writes pixels in the order order of increasing
frequency or time (the order in which the data points
are stored). This means that the VESA driver will have
to remap it's memory each time the vertical separation
between two pixels is too large (not very large)

Linrad-01.17 and earlier versions do not work well with
the VESA driver of svgalib-1.4.3. Overrun errors occur
when spectra change rapidly causing the need to move
many pixels. It has been possible to avoid these
problems by make the window sizes modest or by averaging
over many transforms so the pixels do not move so fast.

Linrad-01.18 works well with the svgalib-1.4.3 VESA
driver on reasonably fast computers - but not for the
oscilloscope functions.

I have installed svgalib-1.9.18 today. I needed assistance
from Matan Ziv-Av, head of svgalib.org because it does not
install automatically under Red Hat 9. The difference in
speed of the graphics is most remarkable. The VESA driver
"VESA driver, 65536KB VBE3" of svgalib-1.9.18 runs about
300 times faster than the 1.4.3 driver. Oscilloscopes run faster on the screen than one can see (I will have to add
a trigger function some day...)

Redrawing the timf2 oscilloscope at 100 Hz (9 tracks, half
the screen width) requires about 15 % of the CPU power
of my PentiumIV 2.7GHz with the new driver. The time to
redraw it once with the old driver was about half a
second (useless).

The problem with installing svgalib-1.9.18 is related to
a feature called -rmap VM which is included in Red Hat
distributions. (It is a feature that makes the handling of virtual memory more efficient.)

If there is anyone on this list who knows how one can find
out if the -rmap VM feature is enabled in the kernel for the svgalib Makefile to know, Matan Ziv-Av would be grateful for some help so he can make the next svgalib easier to install.

              ---------- (from Matan) -----------

> The problem is that RH kernel includes a feature (rmap VM),
> which is hard (at least, for me) to find. To compile
> the module anyway, make sure you have the latest version
> (1.9.18) and edit the file kernel26compat.h, changing line 10, so that
> it is a copy of line 22 ( so that io_remap_page_range() sees 5
> arguments). There might be similar issue with minor versus MINOR, which
> requires similar changes near the end of the file.
.
.
.
> Maybe you can help me here - all that is needed here is a
> gcc pre-processor trick that will find out if the rmap VM is used.
                     ---------------------------

I had to use Makefile.alt to compile svgalib_helper.

73

Leif  /  SM5BSZ




************************************
This email and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email
in error please notify the sender. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of ITT Industries, Inc.
The recipient should check this email and any attachments for the presence of viruses. ITT Industries accepts no liability for any damage caused by any virus transmitted by this
email.
************************************
LINRADDARNIL
I