> > This would have to be added. I see from RTLinux it depends heavly on
> > FIFOs. What are FIFO watermark violations?
>
> Often, hardware (like video hardware) which must handle command FIFOs
> will provide settable high/low watermark values, which will either fip a
> status bit or fire an interrupt when the number of commands in the hardware
> FIFO goes above the high watermark or below the low one. This allows you to
> "balance" the hardware command FIFO against the software command FIFO which
> is feeding the hardware. What you do not want to have happen is a hardware
> FIFO over-run (can cause expensive software blocking until the FIFO is
> sufficiently drained) or under-run (the hardware will sit idle waiting for
> new commands to enter the FIFO, thus possibly causing flickering or framerate
> loss in streaming video, etc).
This should be minimum with RTLinux since we are filling the FIFO in
"real" time.
> Good hardware these days also has settable timeout warnings for
> asynchronous hardware events - z-test, texture read/write, DMA transfer, and
> many other types of internal hardware events. These settable timeout values
> also assist in balancing the hardware to ensure quality-of-service
> guarantees.
Their is so much to hardware these days. We have to get this down to write
a really good system. Of course I have to learn RTLinux inside and out.
That shouldn't take to long. While I do this could you get some ideas of
what we need to do in real time and to take advantage of all the hardware
features a card has to offer.
> As with any limited hardware resource, the kernel should make it
> available to userspace code to allocate (if available) and use, so that the
> device drivers can handle these hardware features in a more generic way, and
> possibly register userspace callback hooks as well. So, for example, the
> driver might not have to know that you are watching TV in a window - it just
> knows that some bit of user code requested a particular region-to-resource
> mapping at a particular resolution and framerate.
>
> Now, it may be quite easy for the hardware to maintain that
> framerate, so this process' FIFO watermark, timeout, etc settings would not
> have to be very extreme at all, and the kernel would be able to schedule the
> process less often and still keep the framerate up. But if Quake3 is being
> played in another window, its demands on the hardware will probably be quite
> a bit more extreme, and so the userspace Quake3 process will need to request
> more time-invariant resource guarantees from the hardware.
>
> > Well I have joined the RT linux team and I'm studing their code. Do you
> > really think going RT linux is the way to go?
>
> I cannot see any way in which it could be worse, but be prepared for
> some crazy hacking I'm sure |->.
Yeap. Let the games begin. From what above its going to be a challange.
> > The big thing always thrown
> > in my face is performace. If we can design a safe accel system that can
> > outperform DRI we got it made >:->
>
> I think we can outperform DRI in regular Linux anyway.
Its basically hitting the hardware directly. It has a chessy lock to
"protect" the system. So it is fast. But a RTLinux system would defintely
blow it away.
> If the video driver, input drivers and console subsystem were in
> RTLinux, Linux itself would have very little to do that was at all
> time-critical.
Well the console system doesn't need to be real time. Also my patch for
linux 2.5.x for fbcon seperates fbdev from the console system. On explict
opening of /dev/fb, the console system open fbdev implicitly, the console
system is turns off. You still need to get keyboard input from /dev/tty
but the console doesn't do any outputing to the screen. We don't even have
to worry about the console system when running a graphical program. Input
drivers. Well I don't know about that one. Image flickering is one thing
but just sitting their in a game because of heavy load isn't that bad. So
your character dies.
