Sun, 13 Aug 2000 daniel sheltraw wrote:
[...]
> >If you really need h/w acceleration for the RT stuff, the driver has to run
> >in
> >RT context, and on nearly all non-pro cards you also need to dedicate the
> >card
> >to the RT task, since consumer video cards in general cannot switch context
> >in
> >the middle of an operation.
>
> David
>
> Would you please explain what you mean by "context switch" amd how this
> applies to RT?
Ok... This all started out when accelerated cards became popular for heavy CAD
and 3D graphics applications. Standardized APIs, multitasking and windowing
systems ended up in the need for real time animation in multiple windows,
driven by separate threads.
Fine; just push accelerator commands from all applications onto a FIFO queue,
and have the video driver (or the hardware) pop commands from the other end of
that queue!
Problem:
Some commands require time consuming operations (such as moving extures to
VRAM) before they can be executed correctly. Other commands simply take a lot
of time to execute. Further, it's not always possible to queue commands
indefinitely so that the actual execution of commands is kept from affecting
the applications.
Now, the OS scheduler isn't aware of these issues, and will try to do it's
usual timesharing. As soon as one thread sleeps on some operation involving the
video card, the scheduler will try to run another thread - only to find that
this other thread will almost imediately go to sleep again, since it needs the
video card, which is in the middle of a lengthy operation started by the first
thread! How to find something useful to do!? Both the CPU and the video
accelerator must be kept working all the time rather than waiting for each
other! There's no way to tell which thread is best to run, since that would
require the scheduler to know how much time each thread would need to get to
it's next video operation, and how long the current video operation will take
to finish. (Kind of similar to EDF [Earliest Deadline First] scheduling.)
Solution:
"Simply" have the video card switch context whenever some other thread is ready
to use it! These professional video cards can stop rendering in the middle of
a big textured polygon (or whatever) and do something else for a while. In
other words, the video accelerators are adapted to the multitasking OS, rather
than the OS trying to figure out information that probably not even the authors
of the applications can provide.
As to how this applies to RT; well, on any card that cannot do context switches
in the middle of accelerated blits (ie most cards that cost less than $500),
you *can't* get the card to perform your operation within any well defined
amount of time - you have to wait for any operation in progress to finish. (You
may be able to queue your operation in the hardware buffer of the card, though,
but you never know when the card gets around to do the job.)
If your card *does* support these low level context switches, you still need to
port the whole driver to RTL and provide some kind of interface to standard
Linux, if you want to share the card with non-RTL applications. If the card is
dedicated to a single RTL thread, you can access the card directly, or hack a
simple RTL-only driver. If true RT sharing of the card is required, you need a
more sophisticated driver.
Anyway, why bother with all this at all...? Nothing will be visible before the
next CRT refresh anyway, and the nature of video accelerators is such that
you'll either have to busy-wait, or do it the intended way; use the hardware
command buffers. I'd guess that even the pro cards which *can* switch blitting
jobs at "any" time will actually require more than just a few CPU clock cycles
to do so.
The most sensible solution I can see is to design an API that lets the RT
threads queue up all their operations, so that the actual work can be performed
elsewhere, such as in a SCHED_FIFO/lowlatency thread using svgalib or GGI/KGI.
(Probably a lot easier to do than using SCHED_FIFO with XFree86, which seems
to eventually freeze the system if you do it with a standard setup.) If you
need the X API, XGGI might be a good place to start, but it's probably not
exactly a single weekend hack... (And, if the card cannot do context switches,
make sure that no application can start operations that take more than a
fraction of a video frame to carry out - or you won't be able to give RT
clients any timing guarantees despite all that work!)
David Olofson
Programmer
Reologica Instruments AB
[EMAIL PROTECTED]
..- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
..- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> [EMAIL PROTECTED] -'
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
