Fri, 08 Dec 2000 Bill Simpson wrote:
> I went through the mailing list archive and I saw one recent thread on
> this. The info I needed wasn't really there.
>
> I am doing vision research where I present a visual display (drifting
> grating embedded in Gaussian white noise) and get a response (button
> press) from a human observer. The timing is important: for the graphics I
> would like to present at some frame rate (e.g. 100 Hz) and know that is
No problem - use fbdev and hack a suitable modeline.
> the true value with no frames displayed twice or skipped; for the
There is an ioctl for that, and you should be able to get 100% reliability
using the Linux/lowlatency patch for user space SCHED_FIFO RT - we're using it
for critical audio stuff relying on sub ms worst case latency, so video at
100 Hz should be totally safe.
OTOH, if you're hacking around in kernel space anyway, you could just hook the
retrace sync code from the fbdev driver into your RTL/RTAI code in some way -
how depends on what video card you're using. (Some cards don't have a retrace
IRQ, so you need to do some tricks unless you're going to poll. The retrace is
usually polled by looking at a bit that's only set during the actual retrace,
so polling is no fun...)
> response, I want ms resolution or better.
You *could* probably get away with Linux/lowlatency for that as well, but
RTL/RTAI gives you lots of headroom to guarantee that every measured result is
really better than one ms in accuracy. (Better stay on the safe side when you
*can* - it's more problematic when coding for normal workstations.)
> I would like to get the response via a telegraph key hooked up to the
> parallel port (debounced in software).
Why? A telegraph key usually has one "down" switch and one "up" switch - just
hook a flip-flop onto those, and you should be fine. (Of course, you could do
that in software as well, provided you connect both switches - perhaps that's
what you had in mind?)
> I think using rtlinux for the response would be pretty trivial. But the
> graphics? I am currently using MSDOS with djgpp/Allegro for making my
> displays. I have no worries about the graphics on this platform. But I do
> have worries about the response collection. I am wondering if rtlinux
> would be a solution. (Otherwise I have to read a lot more about disabling
> interrupts under DOS so I can rely on the timing). The big snag is the
> graphics. Certainly X would not be the way to go.
Probably not, at least not if you also need to update the screen at specific
frames. (You can't guarantee that with X, as you can't get it to do RT
properly, even on lowlatency kernels - it's a design problem of X.)
> Does anyone know how to
> go about doing double-buffered realtime animation under rtlinux?
I think you should be able to get away with user space + lowlatency for the
animation. However, do note that there is no system RAM->VRAM DMA transfer
support in any Linux graphics architecture, and acessing VRAM directly with the
CPU is painfully slow, even with the hottest AGP cards. We have discussed this
on the SDL list, tried various methods on different hardware and different
driver architectures and so on, but it's just impossible to get anywhere near
the transfer rate of the video card bus using the CPU. It has been the law of
game programming for ages never to read VRAM, but now it seems that you should
never write it either... Busmaster DMA is the only way.
Now, if you're dealing with 320x240 256 color modes or something like that,
this is no issue, but you hit the wall before you get to 640x480 16 bit color
on the average machine. I can *barely* handle 640x480 24 bit color on my P-III
933 w/ Matrox G400 MAX, and that's about as fast as it gets with consumer video
cards...
I've been thinking about hacking sysRAM->VRAM DMA into some drivers, but I don't
have the time, and I don't even know if it fits into the driver architectures
without extending the APIs. Besides, for what I'm doing now in the graphics
field, hardware accelerated OpenGL on X is by far the best looking, most
powerful and fastest method for average and better systems - logical, as that's
what the cards and drivers are designed for. This seems to be the conclusion of
anyone who really cares about performance, so consequently, no one seems to be
going to hack the DMA support any time soon. Sorry. :-/
//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/
