On Fri, 15 Oct 1999, [iso-8859-1] Niklas H�glund wrote:
> It's obvious that a way to deal with this needs to be added to GGI.
There are API functions for it in the LibGGIMisc extension, and
they will work on the few targets that have it implemented in
their sublibs. Unfortunately that's not many targets as of yet.
> I don't say something as good as this could be implemented in
> software,
Most PC hardware is very far from being able to do what the Copper
did.
> or that there's need for it, but part of the functionality
> is really useful. Most notably modifying the visual position of the
> framebuffer, palettes, etc. at vblank.
It has long been planned to add automatic vblank-triggered page-flip
and a few other commonly performed operations, but we have not specified
an API for that part, yet. Right now all LibGGIMisc has is GetRayPos
and WaitRayPos. However, now that fbdev has a "load-values at next
vretrace" switch, we should define an API and hook it to a LibGGIMisc
fbdev extension-target.
> Also a command that send a
> message (signal?) to the application is needed to allow syncronizing
> with the display.
Signal latency we have to live with -- however, relying entirely
on signals for this wastes more than the latency time, because signals
would be driven by an interrupt and interrupts are usually issued
by most hardware when the vsync pulse is applied instead of at the
start of the "back porch"; which is fine if all you want to do
is a SetOrigin (but that's so simple an operation it might as well be
handled in-kernel on KGI and fbdev targets.) However if you want to
load full frames from main memory and stuff like that, having the
back porch to work with gives a very big advantage, and even drawing
on the top of the screen when the bottom is being traced may be
desirable.
Basically there are two situations to worry about. One is trying
to find the ray position from userspace when the process is running.
The other is trying to get the scheduler to run the process
promptly at a certain ray positions.
For the former, one possible way to snag the back porch is for the app
to be able to figure out the ray position from userspace efficiently. I've
started (but have absolutley no time for hacking on it right now) a way
to do this on a std VGA card with CPU's that have a TSC; there is bleak
hope for an inefficient/inaccurate implementation using an IOCTL to read
the CTC, and cards with better retrace registers than the VGA can
be worked with much more efficiently. This would constitute a
"polling wait" which is bad, but not if the program has other things
to do in the meantime.
For the latter, there is no elegant solution under standard Linux.
The closest interval a periodic task can be run at to check the
ray position without hacking the kernel (on i386) is 100 times a
second. This can hardly give an accurate reading/signal. So we are
stuck with either losing the back porch (using IRQs) or using a
different flavor of Linux scheduler (RTLinux, or maybe something
customized and collaborative with James's planned SMP resource scheduler.)
In short, frame flipping and anything else simple is doable now if
driven by the vSync IRQ, so we should do it, and I'm pecking away
at a full implementation of GetRayPos, but as it stands
WaitRayPos cannot be fully implemented under Linux.
--
Brian
