I'm interested in trying the following:
(1) The ability to be notified when another process is accessing the
same piece of hardware, and a (2) 'pending dma transfer' table.
(1) This could probably be done by the device driver code, eg. in a
fbcon/kgi module.
Every time a process does a dma transfer, the kernel check to see if
this process was the last one accessing this hardware and if so, nothing
special happens.
If it weren't, the last process is notified and allowed to do some small
amount of work to 'clean up' (eg. save the hardware context state). The
process pending to do the dma transfer is also notified so it knows it
might need to do some more work before initiating the transfer.
This scheme would allow two or more concurrent graphic processes, eg.
the X server and an OpenGL process to share graphics hardware.
This is a lazy way of doing things, there is only extra work done
whenever necessary. Also, each process can decide for itself wether it
needs to restore its state. The X server needs much less state preserved
than an OpenGL process.
(2) Using a 'pending dma transfer' table, a process can allocate a range
of small dma buffers, fill it up and hand it over to the kernel. Since
some hardware can trigger and interrupt when a dma transfer is complete,
the kernel can then do the next dma transfer automagically, notifying
each process as the dma buffer is ready for reuse.
For some special purpose devices, some code in the kernel would be able
to do hardware context save/restore, so each process would only make a
syscall to hand off a dma buffer ready for transfer. It would also be
possible to flag a process as having precedence (eg. an X server) to
minimice latency for that particular process.
[Note that some special hardware have special requirements, eg. a
specific well known graphics chipset can do 'hierarchial dma', that is,
a command in a dma buffer can stop the current dma transfer and initiate
another. This is usefullwhen doing OpenGL display list by storing dma
buffers directly. Some special care must be taken for these kind of
systems.]
I would appreciate any comments on this.
-- Torgeir Veimo, Vertech AS,email: Torgeir.Veimo@vertech.no, mobile: 90673881, office: +47 55563755
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu