> > Thank you for responding to my original request. As a result I read a little
> > on RRM. You have clever friends. This idea of multiplexing the graphics
> > registers is interesting. I guess you would have to put graphics context into
> > the task struct in order for it to work. When the kernel switches tasks, not
> > only does it set the cpu registers it sets the graphics registers too.
> > Or something like that.
>
> I doubt, that Linus will accept that in this way, because that slows down the
> task-switching rapidly...
This only works for high level hardware. Low end PC hardware doesn't
allow interruption of graphics commands to the pipeline. If you
transfering a texture for example you can't stop in the middle of it
and start sending new info. For high end cards you can do this.
It does NOT slow it down. SGI has O2000 servers with 256 processors
and 16 different graphic pipelines are living proof. My friend from SGI
wrote the OpenGL drivers for linux on SGI Visual workstations for the
SIGGRAPH conference using this method. The way the RRM works is it ensures
only one graphics pipe is in use at any one time. In other words for each
video card only one process is using the graphics engine. SGI hardware
considers them graphics pipelines because the hardware design is very
different from PC hardware. You don't just program a few registers and you
get a triangle. The graphics hardware works very similar to the hay a CPU
works with pipelining and fetching new instructions. Once the process is
done another process is placed on the run queue. So it is a matter of
managing the run queue. Sort of a lazy change. The details are quite
complex. In fact someone asked me to post something to the GFX list but it
is quite a write up on RRM.
