From: Michael Gersten <michael@stb.info.com>
  To  : ggi-develop@eskimo.com
  Date: Tue, 17 Aug 99 18:28 PDT

Re: Accels and /dev/gfx.

I just thought of something on the //dev/fb, terminal switching,
lack of dynamic allocation of virtual terminals for efficiency,
and the 56 MB video cards that make it impossible for frame buffer
switching.

My understanding is that to support switching VT's, you have to
preallocate all of the possible terminals for memory efficiency.
And, for 56 MB frame buffers, allocating this much memory isn't
possible.

One possible work around, only allocating memory for a VT when it
is actually needed, which could solve the 56 MB swap, isn't usable
because it would waste 3-7K of memory per terminal.

Are we really talking a factor of 10,000 times here? That to avoid
wasting 3-7K per terminal (say 20-45K total), we won't be able to
swap a 56 MB card?

I could understand if the concern is "10 MB/sec SCSI will take 11
seconds to swap out and in, that's too long". So require that you
have enough memory to swap the displayed image to ram, page in the
new one (5 seconds, about what it takes to re-synch from X to text
anyways), and then page the old one out when the disk queue isn't
busy.

[ Assumption: The kernel can actually tell what load it has. It's
not just "Here swap system, have 56 MB to play with", but "Ok disk
drive, are you not busy now? Ok, here's a meg, tell me when you
are not busy again". ]

Lets face it: We want Linux, and the graphic console system, to
run equally well on 1-4 MB cards on 386/486 systems, or 56 MB cards
on P2's and P3's with 32-128 MB of memory, right?

Isn't it safe to assume that if someone puts a 56 MB video card
into a machine, that that machine isn't a tiny underpowered box?
That it might have a high speed (20 MB/sec) SCSI, or 64-128 MB ram,
or something else along those lines?

Or perhaps the user is willing to wait the 10 seconds that it takes.
Or perhaps the frame buffer isn't in use on the other VT, and it
just takes a text restore

>From what I understand (and if this summary isn't right, please
tell me):

1. You want the user space program to be able to tell that the
terminal is being switched, and give it the choice of what to do.
2. You expect that the user program will decide whether to save
the FB or redraw it later (no backing store).
3. You expect the user program to be able to respond -- that
it will not be suspended, waiting for a non-responsive NFS
server, etc, and that the user program has no way to tell the
system "It's ok to throw the screen away on a terminal change"
ahead of time.

4. History note. Microsoft windows was originally designed on a
non-backing store model, when graphics cards were 1/2 to 1 MB,
systems were 640K, programs were small, and bringing a program into
memory to redraw was the best way to go. Today, we have 4-8 MB
video, and redrawing a screen means bringing 2-4 large, multi-
megabyte programs into memory, having each of them do all of their
drawing again, etc.

We went from a system where having the programs redraw was best
to having a system where a straight memory dump/restore would be
best. Programs didn't change.

You are now looking at the same thing, a factor of 1000 times
larger. High end video cards that are usable in mid-sized machines.
You are talking about a system that sounds like it will be making
the same decisions that microsoft made, with the same predictable
results 2-5 years from now -- system being horribly slower than
it could be, with backwards compatibility preventing it from being
fixed.

A program that has the frame buffer open can be in one of these
categories that I can see:
	1. I need the FB stored, swap it out and restore it for me. 56 MB
	2. I need the display stored, swap just that for me. 8 MB.
	3. I just need the graphics mode settings restored for me.
	4. Throw it all away, I can re-create it as needed.

	5. Either throw or swap, here's my 0-1 preference factor: n
	(and also the whole or just displayed flag).
	Depending on N, and the local system, the OS can either
	do the swap/restore, or tell you "You'll lose it"/"You're back".

Leaving it all up to userspace may seem like a good, flexible idea.
But that program written today may have assumptions that are not
appropriate for all machines today, and almost certainly not for
any machine in the future. The OS can be told the specifics of a
given machine, and be given a guidance factor by the program.

A program can tell how easy it will be to recreate the display or
not. The OS can tell, based on that ease, and the system specifics,
whether it needs to save or not. The user program cannot be assumed
to be able to make that determination.