randy@erik.UUCP (Randy Brown) (08/02/89)
We are board-level integrators, making some of our own special-purpose boards (some of them very special purpose indeed... ) but preferring to buy display subsystems. TI340x0 board vendors are proposing to us that we should use boards with TIGA interface to support an X server. X performance, especially with large 8-bit pseudocolor images, is important to us, normalized by cost limitations that keep our cpu cards down well under $10k (no sneers, please). Porting costs prohibit simply trying everything out! Would any server writers care to comment on the closeness of fit between TIGA and the primitives that X servers require? How preferable would it be to use a board with a general purpose cpu as well, in order to better partition the workload between the main cpu (which has many other things to do) and the graphics card?
CCVQC@CUNYVM.BITNET (Christopher Vickery) (08/02/89)
I can't say anything about TIGA, but I can pass on some of the
issues we're dealing with in porting X to an 82786 based board.
OS: Intel's RMX operating system. "real-time, multitasking"
Display: SBX-279 attached to SBC/386-24. The SBX-279 has its own 80188
processor, RAM, ROM, and graphics memory. It also has an 82786
graphics processor that draws from graphics memory. Windows and
bitmaps are '786 primitives. The interface between the '386 and the
'279 is an 8-bit bus (the "SBX bus"). The 80188 interprets the
byte stream that passes over the SBX bus. Mouse and keyboard are
connected to the '279 and handled by the '188. SBC/386-24 is a
Multibus I board.
Some issues:
1. Where do you put the windows? You could create a pseudo frame-
buffer in '386 memory, but then you would have to copy every change over the
SBX bus to get the display updated. Advantage would be to be able to use
a lot of the sample server code from MIT to maintain the pseudo frame buffer.
Or, you could create a '786 window or bitmap for every X window or pixmap, but
the '786 can't handle large numbers of windows; more than a few being displayed
at a time causes problems. How many depends on the bits per pixel and their
horizontal layout. Our compromise: after an initial implementation using
a pseudo framebuffer (we're working on it now), we'll use '786 windows for
the root and each first level window in the tree. All windows below that
will be bitmaps that we'll blit into place on the first level windows. Note
that this gives us automatic backing store for all windows.
2. The preliminary version of the '279 firmware does not give us
the control we need over mouse and keyboard events, but this is expected to
be cleared up in the next release.
3. There is no acoustic signal available with the '279 for a terminal
bell.
4. The ideal solution would be to program the X server in the 80188
directly, and use the SBX bus as the "reliable byte stream" used for the X
protocol. We don't have the development tools to do that right now.
I believe that there have been some PC-based X servers that use the '786.
AT&T? Perhaps someone could pass on info about them.
The '279 costs about $2k (less once you have the support software).
I have a brief tech report on our work to date ("issues and strategies")
if you are interested.
Christopher Vickery
Queens College of CUNY