> Andreas Beck wrote:
> > So IMHO one should rather _avoid_ multithreading, except for _large_
> > independent tasks. The natural way to do this is in the user program, like
> > separating input, scene calculation and rendering.
This is certainly necessary.
> Finally, this issue of having a multithreaded (potentially
> parallelized) 3D pipeline in itself is, IMHO, very different
> from having a THREADSAFE 3D pipeline.
> If the 3D pipeline can be put in a separate thread (as a
> whole), then it will probably be nice - because the application
> can do its own work in another thread (and another processor).
This is how glx now works, and means that dual processor boxes can
work very well (although the load balancing is not very good for
many programs, so much CPU time can be wasted).
> At this level, the granularity of the parallelism is adequate
> (I assume that the application does not redo the exact same
> job as GGI3D just for fun :-), and it is very possible that
> true parallelism is exhibited. The application-dependent
> part and the GGI3D-rendering part have probably rather different
> occupations. 
It is adequate perhaps on a dual processor system. It doesnt work well
above this. However paralllelising the pipeline has too many overheads
due to accessing the same data. What is needed is parallel renderers,
so that different threads can draw into the scene simultaneously.
Also remember that hardware 3D is here to stay, and parallelising
the operations that will be done in hardware in the future is not
> In short, I strongly support THREADSAFE programming, but
> I tend to have doubts with MULTITHREADED programming.
> Strange no ? Maybe we need some dynamic thread creation
> based on runtime data (and here the thread pool comes again!).
> Well, I closed the circle. I stop the wonderings... ;-)))