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

Re: [linrad] VESA

I have been asking about regarding the -rmap VM problem on www.experts-exchange.com ... a neat place to ask questions

See http://www.experts-exchange.com/Programming/Programming_Platforms/Linux_Programming/Q_20952531.html

-Joe KM1P aka GSIJoe

"Sunnycoder" writes:

>If enabling this feature provide you some command or API, you can try running that command and check the return value ... >If you can elaborate a bit on this feature I can try to find out the details ...

>Also if this feature appears in kernel configuration options in make xconfig, then there will be a corresponding variable in >arch/<your arch>/config.in file and a corresponding header C file (I cant recollect the name!!)... the names are pretty >descriptive so you will have no difficulty in detecting the variable ...

>If it is configurable option let me know and I will try to search the name of the header file too !!


Leif Åsbrink wrote:

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.


Leif / SM5BSZ