Quick reactions on graphics post
Jonathan S. Shapiro
Thu, 30 Apr 1998 13:19:22 -0400
These are brief responses -- I'm working on something else at the
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
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
2. Physical memory regions are not included in the checkpoint
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
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
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
> If, instead, the "commands" that produced the graphics are
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
> 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
This implies a need for graphics managers to do something sane when,
say, the second video card is removed from the machine.