Subject: Re: Any experince with this alpha?
To: Matt Thomas <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 08/26/1996 19:12:31
In message <199608262045.UAA29122@whydos.lkg.dec.com>Matt Thomas writes
>> As a small data point, here are some numbers for a TurboChannel sfb
>> (which uses an earlier generation of the chip that the multia uses)
>> running on a DECstation 5000/260 (R4400). With an XFree86/X11R6 X
>> server (which treats the sfb as a dumb framebuffer) I get around 20k
>> xstones. With the DEC supplied X server, this jumps to over 120k
>Digital has supplied to the XFree86 folks the accelerated ddx layer for
>the TGA X server (primarily for Linux). If anyone is really interested
>in a fast X server, I suggest you talk to them.
It's ... nice... that the accelearated ddx layer is available.
I'd kind of hoped to aim for an Xws-like user/kernel interface (as X11R6
and I think R5 used on Ultrix) on NetBSD/pmax and NetBSD/vax. That may
not be compatible with whatever user/kernel interface XFree86 has.
It also doesn't help with the turbochannel PixelStamp/ i860 2-d and
3-d framebuffers (PMAG-C, -D, -E, iirc), which also aren't yet
supported by netbsd on any platform.
>This also means with little effort you can have a fast X server for SFB
>based systems (Flamingo/Sandpiper or DECstations 5000) since the TGA and
>SFB chipsets are very similar (mostly just different buses).
I thought the TGA functionality was a strict superset of the sfb?
> [Of course,
>this begs the question of why we TGA console but no SFB console under
No lk-201-to-ASCII translation (and no mechanism to redirect
scc input streams to such translation) in the Alpha kernel.
The SFB is a supported console on TC pmaxes. Pmaxes use the
rcons "machine-independent" glass-tty-on-framebuffer interface.
Alphas use wscons, which is richer and can handle (S)VGA text modes
as well as raw pixels. If I had any spare time, NetBSD/vax would get
rcons-based fb support for the pmax-like 3100 framebuffer, qvss, and
qdss. If anyone _really_ wants to kill off qvss-style in-kernel
pointer-tracing and cursor-sprite movement and shared-memory
input-event ring-buffer, now is the time to speak. I'm afraid it
may still make sense on microvax-IIs, for performance reasons.
(anyone really want vaxstation-100 support? I hope not..)