: > So, you might have a physical display of 800x600, a virtual display of
: > 1280x1024, and a virtual desktop of 3x3 virtual displays (3840x3072).
: > And you would still have 700K of Video RAM that can be used for font
: > caching and pixmaps.
: > Confusing, isnt' it?
: Not at all. I'm quite clear with how much memory left in each case.
: My question is can the X-server really use the video RAM for other
: purpose like font cache and pixmaps? I hope you could explain this to
: me. (say, how the system access the video ram, using memory mapping,
: etc?) Thanks a lot.
I haven't actually spent any time examining Xfree86 server code, but I
can explain how I would guess it is done. (Somebody who actually
_knows_ can jump in at any time...) We'll assume that your video board
has 2M of ram.
First, the server can manipulate video ram two ways:
1) It can read/write the ram directly. This happens in two general
ways depending on what type of video board or motherboard:
a) ISA bus. By writing to I/O registers on the video board you
can map a selected portion of the 2M video RAM into a 64K
segment of the ISA bus address space. Once you've selected
which "page" you want, you access it as normal RAM at ISA
bus speeds (typically 8MHz).
b) Local bus (VLB or PCI). This allows the entire 2M of video RAM
to appear in the processor's address space as a single block of
memory (no page selecting needed). Thus the server software
can access all of video memory with normal read/write cycles
at the speed of the local bus (typcally 25-50MHz).
2) The server (which is a program running on the 80x86) writes a
command to the processor on the video board. These commands
implement (in hardware -- sort of, probably microcode) common
operations like move an HxWxD bitmap from x1,y1 to x2,y2, or draw
a line from x1,y2 to x2,y2. This is handled entirely on the
video board without using up or being limited by the ISA/VLB/PCI
Font caching would then be done like so:
The first time the server gets a request for a font, it reads the font
bitmaps from a disk file into video ram (using 1a or 1b) in a spot
that is not being used as part of the frame buffer -- it doesn't show
up on the screen. Now when we need to draw characters on the screen,
we can do it by method 2 above. We just tell the graphics processor
to copy a bitmap from one spot in video ram (where the font is cached)
to another spot in video ram (where the displayed window is). Some of
the video processors can actually queue up several commands so that
you don't have to wait for each one to finish.
Likewise, when a pixmap is created, the server reserves a section of
non-displayed video ram for that pixmap. When the server gets
requests to draw lines and characters on the pixmap, it does so with
method 2 above. (The pixmap is still off-screen.) Then when the server
gets a request to write the pixmap to a window, it also does that with
a single command telling the video processor to copy it from one spot
in video ram to another.
If you don't have enough video ram to hold all of the active fonts,
pixmaps, and cursors, then you have to save them in main memory and
copy them back and forth to video ram using 1a (not too bad) or 1b (a
If the functions implemented by the video processor closely match the
operations required by the X server, this can result it amazingly good
X performance for not too many bucks. I've got a 20MHz 386 (no cache,
ISA bus) with an ATI video board with a Mach8 video processor. The
Mach8 server program takes pretty good advantage of the video boards
capabilities and it's several orders of magnitude faster than the
previous generic VGA board that didn't have a video processor (method
2 wasn't available, nor was 1b, everything was done using 1a -- paged
access to video ram). The difference in text scrolling speed in an
xterm was astonishing. With the old board, text scrolled like I was
connected to a 2400 baud modem.
Grant Edwards |Yow! Hold the MAYO & pass
Rosemount Inc. |the COSMIC AWARENESS...