Quick reactions on graphics post

[Jonathan S. Shapiro]

These are brief responses -- I'm working on something else at the
moment.

We should also look at the windowing primitives provided by MGR, which 
was done at BellCore.

In message <3548CBCD.4B55@key.cc.utah.edu>, bill One writes:
>   What is checkpointed?

First, let's frame the problem, as it were:  ;-)

1. The graphics card memory is now a substantial fraction of main
   memory.
2. A vertical scroll in a text window dirties essentially all of the
   frame buffer.  This is a frequent operation.
3. The combination of (1) and (2) means that COW is a highly
   undesirable solution for the frame buffer.
4. Redrawing may well have lower cost than copying those pages.

A variant solution to the ones that bill1 identified is described
below.  This is the one currently proposed for EROS, though I'ld be
delighted to revise or improve it:

1. Let the frame buffer be mappable via a kernel physical memory
region [in previous discussions I have referred to this as a physical
page key; a better abstraction is emerging from the malloc
think-through].

2. Physical memory regions are not included in the checkpoint
contract. 

    Rationale 1: the hardware you were talking to through it has
	         at the very least been reset, and therefore will not
	         know what to do with it.

    Rationale 2: that hardware may no longer be present or may have
                 been replaced by different, possibly incompatible
	         hardware.  E.g. video card upgrade (functionally as
                 capable but different HW interface) or downgrade.

3. On restart, all physical page keys are become undefined, and accesses
   to them generate a fault: either FC_InvalidAccess or
   FC_InvalidPhysAccess.

   I am inclined toward FC_InvalidPhysAccess.  It's easy to treat the
   two the same in the keeper, but a pain in the ass to distinguish
   them, and the kernel is standing in a position to know.  A
   principled account for this behavior probably requires that stale
   physical page keys turn into the (singleton) stale physical page
   key rather than a zero number key.  

   [Reactions from the KeyKOS crowd? Is this necessary?  Is it okay
   for the page fault handler to convert to DK(0) and yet special case
   this?  One does not seem intrinsically more offensive than another
   to me.]

   I see no problem in principle with this change in rescind behavior
   in this case.

   I am mildly inclined that this fault should go directly to the domain
   keeper, as it will be necessary for the "repaired" application to
   run re-initialization code and the segment keeper is not in a
   position to tell it so.

4. There is some agent, perhaps a window manager or perhaps a graphics 
   manager, that is mutually trusted and is responsible for low-level
   geometry arbitration (rights) and for redraw policy.  This agent is 
   responsible for (re)initializing the card and either performing the 
   redraw from backing store or demanding that the application do so.

   For the reasons that bill1 has outlined, it may be convenient to
   have this agent grok terminal (text) windows.

>     (Consider, for example, someone doing animation...  they
>     can easily be updating the screen at a rate that exceeds
>     the disk bandwidth.)

The checkpoint is a function of time, not a function of memory update
rate.  As a result, the issue you raise won't arise.  What will happen 
is a visible hickup in the update just after the checkpoint snapshot
occurs.

>     If, instead,  the "commands" that produced the graphics are
>     stored...

It is not clear to me how the graphics manager can determine which
commands to save -- there isn't really any equivalent to a formfeed
delimiter by which to know where the last screen ended and the current 
one begins.

> Structural issues:
> 
>     In any windowing system built on the graphics, to keep
>     consistant with the EROS philosophy we'd want programs
>     to only be able to write on their own windows, and not
>     on each other's windows or any system reserved areas.

Given the limits of current memory management hardware, it is probably
not feasible to allow applications to directly map their windows.  If
one adopts a "command stream" view of the graphics system, as has been
proposed, it probably doesn't make sense, as the drawing will only
ever be done on the frame buffer in most cases.

Once a call interface is interjected between the app and the window,
such limits can easily be enforced in software while leveraging
whatever supporting features the hardware provides (e.g. clipping).
This is part of the job of the graphics manager.

[I distinguish between graphics manager and window manager partly to
avoid confusion with existing terminology and partly because they
really are different.  The job of the graphics manager is to
virtualize the graphics subsystem.  The job of the window manager is
to present an interface and perhaps some interaction policies.]

>     The window manager would have to somehow inherent the
>     memory that is the frame buffer (How does one request
>     specific hardware memory locations in EROS?)

The graphics manager obtains a capability to the graphics card during
reinitialization, and asks the card for a physical region capability.

Device arbitration at the level of "who is entitled to what
capabilities" presents an interesting set of problems.  In this
instance I would suggest that a graphics metamanager permanently holds 
the graphics device creator capability.  On restart, the metamanager
re-enumerates the graphics cards and somehow binds them back to the
graphics managers.

This implies a need for graphics managers to do something sane when,
say, the second video card is removed from the machine.



shap