Mon, 15 Jan 2001 marco zoncu wrote:
> Is it possible to use OpenGL libraries in a rtlinux
> task? I should not want to see my graphics scheduled
> in background (as a standard Linux process), 'cause
Well, you can always make sure that your process gets the highest priority, at
least on a dedicated system, but still...
As soon as you need disk access and other stuff going on in the background
(texture caching, video on textures, procedural textures, music, audio,...),
you'll start to get problems, especially if you have one of the flaky cards
and/or drivers that rely on polling the retrace bit for raster sync. (The sad
truth is that this goes for the majority of cards.)
> I'm gonna write a VR application (or I hope so)!
> Thank U very much!
Knowing what I know now, after thinking about all kinds of brutal solutions for
various problems, I wouldn't consider RTL or RTAI for any "normal" graphics
application, especialy not if it's going to run on a dedicated system.
First, you'd have to port the entire driver (Utah-GLX or whatever) to RTL, and
make sure that no one else is competing for the video card. Forget about X -
it will interfere with your RTL threads, especially on most non high end 3D
accelerators that can't do real context switches in the middle of any
rendering operation. If X starts blitting a big pixmap right before your
thread is scheduled, you're out of luck. You have to wait for the blit to
finish. (Or rather, your 3D accelerator commands will be queued in the command
FIFO until the blit is done.) Your code being scheduled exactly in the first
pixel of the retrace doesn't help.
Besides, you can't do anything on the screen more frequently than once per CRT
(or LCD) refresh anyway, so you'll be fine just getting each frame ready in
time for the next page flip.
Further, with tripple buffering, you don't even have to be in hard sync with
the raster to get access to 100% of the power and full frame rate. You can even
get away with occasional frames taking more than a refresh period to render
without dropping a frame. :-)
Now, what you *need* is a good 3D card (or two :-), a decent OpenGL driver,
and a lowlatency patched Linux kernel. It seems that you may also have to hack
X or GLX to get double buffering to work entirely without tearing. (I'm
currently working on that, actually, as I'm playing around with arcade quality
2D animation using OpenGL.)
Since modern OpenGL drivers bypass X almost entirely, you should be able to
run your rendering thread as SCHED_FIFO, which means that you cas get a
guaranteed worst case scheduling latency of well below 1 ms. However, I haven't
tried this yet, and it *might* not work properly without some hacking of the
OpenGL driver and/or X. (Using normal X from SCHED_FIFO threads, or running the
X server as SCHED_FIFO can cause freezes and other nasty things.)
As to latencies in the ms range rather than in the µs range, remember that one
video frame at 100 Hz is ten (10) ms. You lucky video dogs! ;-) Serious RT audio
requires at most 5 ms *input->output* latency, and that's using 4 buffers, ie
1.25 ms/buffer. For that, you need the slack that triple buffering cuts you in
order to avoid minor latency peaks causing dropouts.
Finally, what you *could* use RTL or RTAI for in a VR system is to "fix" the
retrace sync problem. Just measure the actual frame rate, set up a one-shot
timer driven thread with a slightly shorter period than the frame rate, and
finally poll the retrace bit from within that thread. Thanks to the accurate
scheduling of RTL or RTAI, you can tune the timer so that you actually poll for
just some 10-50 µs every frame, still without ever missing a retrace.
If you still think this is too many wasted cycles (hey, 50 µs *is* actually
some 25000 cycles on the average Intel! :-), the method can be refined down to
virtually no polling time at all. Can't really see why that would be worth the
effort, though. (It's required when doing this without RTL or RTAI, though.)
If you're interested in what I'm doing with OpenGL and Linux/lowlatency, stay
in touch! Some keywords:
SDL http://www.libsdl.org
Utah-GLX http://utah-glx.sourceforge.net/
retrace sync
double buffering
page flipping
full frame rate
no tearing
antialiasing
sub pixel accurate 2D rendering
refresh rate independent smoothscrolling
(Not that I'm working day and night on this in particular - I have waaaaay too
much going on. The MAIA plugin API is supposed to be used for some basic
processing pretty soon, among other things.)
//David
..- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------> http://www.linuxaudiodev.com/maia -'
..- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`--------------------------------------> [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/
