Thu, 18 Jan 2001 Bernhard Kuhn wrote:
> David Olofson schrieb:
>
>
> > > Trust me: as long as the application itself doesn't do disk
> > > accesses (including swapping due to high memory usage),
> > > it's the only application running on the system at all and
> > > therefore running absolutly smoothly.
> >
> > Well, see above; that's no good for hard disk recorders and direct-from-disk
> > samplers! :-)
>
> Correctly, but we were discusing about visualization using OpenGL :-)
Yes, but even some games and other heavy multimedia applications stream from
disk and/or various forms of dynamic loading of world data. One reason to do
that is to reduce loading times, so one can't just dismiss this with "but you
can use more RAM".
> [ retrace sync ]
>
> two years ago, i did a simple RT-Linux program, that measures
> the time between two retrace signals and then sets itself asleep
> until 20 microseconds before the next retrace signal will apear.
> then it does the busy wait and performs a software interrupt.
> Worked rather well and went into the GGI-coda, afair,
> but modern GFX-card should generate an interrupt on vblank!?
On the contrary, the trend seems to be that modern cards do *not* generate
retrace interrupts like most of the old cards did. The reason seems to be that
they provide a better alternative; double or triple buffering with GPU commands
for flipping and sync. However, that doesn't help if no drivers make use of
it...
This reminds all too much of a discussion on the kernel list, regarding
WinModems and Linmodems (ie software modems; line interfaces without DSP
power). There has also been similar discussions related to other hardware.
The story is basically that RTlinux or similar *could* be made part of the
mainstream kernel, but that would only encourage hardware developers to release
more crap hardware, broken by design. The RT extension would allow drivers to
"fix" the problems, making it appear to end users as they got nice hardware.
The problem with that is that it would eventually result in Linux being loaded
with RT drivers fighting a latency war, and that in turn would render Linux
useless for hard RT work - back at square one!
So, if a retrace sync solution is going anywhere near mainstream releases of
Linux or drivers, I think the solution has to work without RTL or RTAI. The
hard part is that in order to be of much use, it still has to be very
reliable... No problem if the rendernig code and the GLX drivers run
SCHED_FIFO, and we have true hardware double or triple buffering, but with "blit
flips", it's getting complicated.
The question is basically "Try to fix it, or give up on all drivers without
real pageflipping support?"
I think one could hack Utah-GLX to do triple buffering with the current
back->front blit method, using two back buffers and a performance counter
check + occasional retrace sync somewhere in the low level driver, but I'm not
sure it's worth the effort. (Interesting hack though, so I might have a go at
it either way. :-)
> [ Watchdog mechanism ]
>
> > Will get back to it some time. It will very likely gain priority as I get
> > increasingly tired of looking at the fsck progress bar! ;-)
>
> Tip: Use ReiserFS - saves a lot of time and nerves ...
Yeah, planned to use it on the new 933, but never got around to it.
> I am using it for a year for now ... no loss of data even with
> hundreds of crashes because of unstable drivers and/or
> while developing on (rt-)kernel level.
Seems like a good idea when using unstable stuff! :-) (And it seems I pretty
much have to, as the stable versions of most of the stuff I depend on is
basically useless.)
> [ 10 ms pause in rt-app ]
>
> > Yeah, you give the kernel and all kinds of other things extra chanses to steal
> > the CPU from you and keep it for quite a bit longer than the desired 10 ms...
>
> Yes, but even then, things appear to be much smoother ...
The problem is probably that you're choking the rest of the system until you
run into a dead end and *have* to sleep for some reason - and at that time,
you're out for a good while...
If you're not running SCHED_FIFO, it could just be the normal operation of the
Linux scheduler, as I understand it. If you never sleep, you'll eventually
find yourself preempted by a thread that has the same or even ower priority than
you, and at that time, it'll take a while before the scheduler lets you in
again. (IIRC, the scheduler is using a kind of dynamic priority offsets to
implement the time sharing without explicitly "pulse width modulating" the
threads, and that's not what you want for real time work.)
> [ latency patch ]
>
> > Could potentially fix most of the problems, but we may still be facing problems
> > caused by the fact that X is not a real time application.
>
> You are probably right. At least. IMHO, these kind of application
> don't need to be done in "Real Time". Here, "Quality of Service"
> is needed.
I don't see QoS as very different from RT.
>From the implementation POV, it's clear that you need hard RT to implement
"hard QoS", but you can get away with soft RT for "soft QoS". For serious
gaming (2D games in particular; ocasional dropped frames are less visible in
3D games for some reason), I wouldn't consider "soft QoS" sufficient, so my
conclusion must be that hard RT is required.
As to what QoS really is, and why I don't consider it very different from RT;
QoS in it's simplest form basically means that you can have a certain amount of
things done within a certain amount of time.
Thinking about this in audio terms, that would be "you can play N samples in T
seconds". Obviously, if either the client or the server could get stalled for
longer than T (and there is no hardware buffering to cover it - or if
additional buffering can't be used for input->output latency reasons), there
would be no chance whatsoever to guarantee this.
For graphics, yes, it would be more accurate and useful to simply guarantee that
the server can output one frame per refresh (full frame rate), than to deal
with it on the level of client/server interaction and scheduling. In fact, the
client shouldn't even have to run in hard sync with the server on a frame by
frame basis at all; it would be sufficient to view glXSwapBuffers() as meaning
"push the current frame onto the queue for display". (This is actually what it's
*intended* to mean, AFAIK.) With 3 or more buffers in this queue, the client
will just push frames when there is room, and sleep in glXSwapBuffers() when
the queue is full. The retrace sync will be handled by the server/driver, or by
the hardware, meaning that the timing critical stuff can be kept there.
We have been doing this with sound cards for ages, so why should video be
different?
> The best solution for smooth 3D rendering
> is certainly the Linux resource kernel from Raj (maybe mixed
> with the low-latency patch), but Linux/RT doesn't
> seem to be open any more: Today, i tried downloading
> then new version 1.2.1, but the ftp-server is password
> proteced :-( You only can buy a CD for $49. Does anybody
> know more about this problem?
I think this is either a mistake, a server problem, your ftp client not doing a
valid anonymous login (seen that a few times), or someone violating the GPL.
//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/
