On Mon, 4 Oct 1999, [iso-8859-1] Rubén wrote:
> On 1999/Oct/04, Jos Hulzink wrote:
>
> > > into KGIcon, it's best (I have readed the GGI tech. docs, and it seems to be
> > > a bit difficult).
> >
> > The ViRGE has completely functional vertical retrace interrupt code, but
> > at the moment, nothing is done with it. Reason: I have not seen a
> > mechanism to get the sync to userspace neatly. (Maybe some
> > CHIP_WAITFORRECTRACE ioctl ? We never intended to be real-time, so some
>
> Not, FB has now a good way of use it:
> [ /usr/include/linux/fb.h ]
> #define FB_ACTIVATE_VBL 16 /* activate values on next vbl */
>
> It can be *very* usefull to do page flipping.
*Simple* page flipping, sure. Basic double buffering. But what
if you want to triple-buffer? What if you have to use the vblank
interrupt to balance a FIFO or flush texture state in addition to buffer
swapping? What is needed is full user and kernel level asynchronous
notification and kernel-only callback system.
Modern video chipsets can do quite a bit of stuff with interrupts,
hardware semaphores, AGP fault notification, etc. It seems a shame to
restrict this wonderful generalized capability to the ancient idea of VGA
pageflip-on-vsync. See my other post on 3D KGI ioctls for how I propose
to handle this in KGI.
> You still have the
> problem of dumping buffers into video memory, but at least, this is
> something... I understand that a waitretrace ioctl makes no sense.
It makes sense with manual userspace buffer flipping using VGA
splitline. IIRC, that is what informed the original design. However,
these days the vblank IRQ is just one of many sources of hardware RT
events that can come from a video card, and I do not see why it must be
treated differently or the async notification subsystem should not be
generalized.
> Well, let me imagine a bit. Applications has two main ways of
> writing his data into video memory, either with page-flipping (very easy to
> handle, I think) or with double (triple, ...) buffering, right, or I have
> *very* old ideas?.
I have always considered the terms "pageflipping" and "double
buffering" to mean basically the same thing.
> So, _maybe_ it would be a good idea if kernel could
> handle and dump the memory buffer for you...
> You only call the FBIODUMP_BUFFER ioctl, passing as parameter, a
> structure like this:
>
> struct kgi_buffer{
> void *buffer;
> uint16 x0, y0;
> uint16 width, height;
> }
>
> and the buffer is dumped when it's possible, getting the proccess locked
> until this is done.
Blocking I/O sucks and should be avoided like the plague wherever
possible, especially in quasi-RT situations like this.
> In some cards it it could be done with HW accel by AGP?
Yes, on some cards you can schedule pageflips on vsync. On lots
of cards you cannot, but the vsync IRQ is still available. You will drown
in a mess of spacial cases if you don't abstract this stuff carefully.
> It's a very simple idea, and surely more people thought in it
> before, what's the problem with it?
The problem is that it is a card-specific feature. Card-specific
features must be abstracted carefully in order to be able to support al
features of all cards while not losing performance. In particular,
though, exporting random asynchronous callback hooks from the kernel is a
real PITA unless you have something like devfs or procfs where you can
dynamically create files at will. We have this now, so I figure we might
as well do it right.
> I know that the idea of kernel doing it wouldn't like many people,
> and I know that in some systems it isn't possible to dump big buffers in a
> vertycal retrace/blank, but I can't see a best solution.
Dynamic asynchronous notification selector files.
> > > I'm still porting 3D routines from DOS to Linux, I have finished
> > > flat and gouraud, and will start with zbuffer. And a Cube is the easyest
> > > way, IMHO, for finding bugs in the ported routines, it isn't the demo itself
> > > :-D
> >
> > You're talking about software emulation of the functions you describe or
> > hardware support ?
>
> Both. In the port I'm using extensive the hardware accel if possible
> (is for demos, I _may_ use as much resources as available)
On new cards, you cannot really squeeze performance optimizations
unless you do extensive run-time balancing of the hardware state, and
without a good system to get the hardware info to the kernel and/or
userspace quickly much of the benefits will be lost.
> > Want to help writing 3D accelleration in the KGIcon S3 Virge driver ?
>
> Yes, I really want, where can I start searching the HW specs of the
> 3D commands?
See the draft proposal for 3D kgicommands that was recently
posted. Also read the techincal documentation on whatever video chipset
you want to work with.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
