🚀 go-pugleaf

Anders.Sundin@orgk2.lth.se (Anders Sundin) wrote:
] None of the replies to Maynard Handley's article has touched on the
] problems of fast interactive graphics, and I am curious, is it true
] that bad responsiveness is more or less an inherent flaw of serialised
] screen servers? Maybe it would be better to do it in parallell with
] one "graphics server" per window (since only changes of the position

Congradulations, you've turned off the X_SYNC flag.  8-).

] or size of windows could change the screen area that each window server
] owns, and only then would the drawing be postponed).

Congradulations, you've invented the MIT shm extension.  Several
years too late, though.  8-).

] What are the preferred methods of an OS which wants to support
] complex interactive graphics as a simultaneous control of, and
] feedback from heavy number crunching?

In real time?

Use different processors for the graphics processing and the number
crunching.

Or put the hardware entirely under application control instead of
trying to wedge the OS in there.

Of course, this isn't really what you are asking, it's only what
you think you are asking.

] For instance, think about virtual reality (no that's not what
] I am into, but I guess my programming problems are similar).

"Virtualy reality" as most people believe it should be is right
at the capabilities of the hardware -- and then some.  Writing
apps at that level basically requires building them as embedded
applications or drivers -- it is an issue of real time control.

As a real time issue (I assume from your address, you are wanting
to do chemical modeling or visualization?), you must do all of the
processing before the displaying, and do the displaying in what
is an unreasonably small amount of time if you aren't taking over
the hardware directly (or mapping a memory region of display
memory into the rendering software's display space -- the MIT
SHM extension which has been inn X servers for a long time).

Either way, your app ends up talking directly to the hardware
without the OS's involvement except to grant or deny the required
initialization operations.


To answer your question, the "preferred method" is to throw hardware
at the problem.  If you can't afford to throw hardware at it, then
you can't afford to do what you want.


For instance, a good chemical modelling program for an SGI system
will take advantage of the ability of the display hardware to do
Gourad shading on the little molecules without taking the main
CPU (which is presumably crunching the numbers to generate a layout
vector list) to do it -- hardware Gourad shading.


The less preferred method (apparently) is to throw a mathematical
programmer at the problem, since chemists make better chemists
than they do programmers.  He or she will then translate the
problem soloution into a program.


                                        Terry Lambert
                                        terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.