Very Computer

Thanks,
--

Louisiana Tech University, BSEE/Sr * These opinions are probably mine

The Trident will actually give you the same quallity as any other card but it
is very annoying to have to wait for text to scroll in xterms. I would
recommend a (generic) S3 card. You already invested probably $1000 in this
system, so why settle for 15 times slower graphics (if that is what you use)
to save $100 ?

Motherboards are pretty cheap too, so you might consider switching to a
VLB one.

--
+------------------------------------------------------------------+     |
| Jerry Cullingford  #include <std.disclaimer> +44 442 230000 x3875|   ,-|--

+-----(Work)--------------(Home)--------------(another alternate)--+ \___/

   The Trident is a good card, run on everything and has drivers for
everything. The downside is that it's one of the slowest card around.

   For good speed at 1024x768x256, I would suggest a 2 mb video card,
S3 based (except Diamond, which have a non-standard architecture) and
probably ET4000w32 would be good choices. The w32 is probably the best
around for text mode. S3 is better for graphics, but not very good
on text mode.

--
Alain Southiere                    | You can't always get what you want,

-----------------------------------| You might find you get what you need !
OS/2 2.1 Operate at a higher level |                -The Rolling Stones

Mark van Hoeij

: >   For good speed at 1024x768x256, I would suggest a 2 mb video card,
: >S3 based

: There is absolutely no point in having 2Mb for 1024x768x256 on an S3 card.

Depends on what you're doing.  The extra memory is used by the server
as a font cache and for pixmaps, cursors, backing store, etc.  Having
_some_ extra memory is pretty much required, and having a bunch is
nice.

Transfers of bitmaps between different regions of video board RAM is
_way_ faster than going from main memory to the video board.  If there
is enough RAM on the video board to store all of the pixmaps and fonts
you are using, there should be a significant performance increase over
having them all in main memory.

: If you have an S3 with 1Mb on an ISA bus then X runs perfectly. 2 Mb won't
: give a speedup.

Yes it should (though I haven't done any tests myself).

--
Grant Edwards                                 |Yow!  Where does it go when
Rosemount Inc.                                |you flush?
                                              |

Quote:> : If you have an S3 with 1Mb on an ISA bus then X runs perfectly. 2 Mb won't
> : give a speedup.

> Yes it should (though I haven't done any tests myself).

: Does this mean that changing the virtual display from 1600x1200 to 1024x768
: would "free" memory to be used as font cache etc, and thus give a performance
: boost ? All given that you have 2 MB video dram...

If it's a PCI or VLB board, then the bandwidth between main memory and
video memory is pretty good, so it might not be noticable.  I've got a
1M ISA Mach8 board at work, and a 2M VLB S3-928 board at home.  I'll
give some thougt to a benchmark of some sort (I suppose I could run
xbench, but that takes sooo long).

: Well, I'll give it a try on monday and see if I can notice any difference..

Good -- keep us posted.

--
Grant Edwards                                 |Yow!  CHUBBY CHECKER just had
Rosemount Inc.                                |a CHICKEN SANDWICH in
                                              |downtown DULUTH!

Quote:> Transfers of bitmaps between different regions of video board RAM is
> _way_ faster than going from main memory to the video board.  If there
> is enough RAM on the video board to store all of the pixmaps and fonts
> you are using, there should be a significant performance increase over
> having them all in main memory.

--

Rule # 1:  Network *is* computer

: > Depends on what you're doing.  The extra memory is used by the server
: > as a font cache and for pixmaps, cursors, backing store, etc.  Having
: > _some_ extra memory is pretty much required, and having a bunch is
: > nice.

: I don't have much expertise on low lever X.  But I got confused how
: the frame buffer can be used as a font cache?  I can't imagine how
: it can be used for backing store, either.  'cause XFree 86 use the
: extra frame buffer memory for those "extra virtual display area, you
: know what I'm talking about".  Can any X guru give me an good
: explaination?  Thanks a lot!

If you define the virtual display so that it takes up all of your RAM, then
it can't use any of it for those purposes.  Some of the drivers require that
you have 1K free for the cursor bitmap.

If you have a 2M board, and define your virtual display as 1280x1024,
then you're using up 1,310,720 bytes of video RAM for the frame
buffer, and have 786,432 bytes of video RAM left over for "other"
usage.

Some window managers also provide "virtual desktops" that are bigger than
the "virtual display" size (which itself might be bigger than the physical
display).  This "virtual desktop" is managed using normal memory.

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?

--
Grant Edwards                                 |Yow!  TAPPING?  You
Rosemount Inc.                                |POLITICIANS!  Don't you
                                              |realize that the END of the

                                              |MOMENT for most people?!

--

Rule # 1:  Network *is* computer

Quote:>Depends on what you're doing.  The extra memory is used by the server
>as a font cache and for pixmaps, cursors, backing store, etc.  Having
>_some_ extra memory is pretty much required, and having a bunch is
>nice.

>Transfers of bitmaps between different regions of video board RAM is
>_way_ faster than going from main memory to the video board.  If there
>is enough RAM on the video board to store all of the pixmaps and fonts
>you are using, there should be a significant performance increase over
>having them all in main memory.

>: If you have an S3 with 1Mb on an ISA bus then X runs perfectly. 2 Mb won't
>: give a speedup.

When a 16bit S3 server is available then you sure would be glad you have 2MB,
one of the reasons I haven't done anthing on adding 16bit support to the S3
server is that I only have 1MB on my 801, and I can't find anyone that sells
<=60ns DRAM to expand it...

Jon.

: > 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
     bus throughput.  

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
_lot_ slower).

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...
                                              |

: 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
[...]
:        b) Local bus (VLB or PCI).  This allows the entire 2M of video RAM
[...]

: 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
: _lot_ slower).

Oops, got that backwards -- should be "using 1a (a _lot_ slower) or 1b
(not too bad)."

--
Grant Edwards                                 |Yow!  I've got a COUSIN who
Rosemount Inc.                                |works in the GARMENT
                                              |DISTRICT...