Andreas Beck wrote:
> A few thoughts about multithreading LibGGi3d:
> > - better scaling on SMP-machines
> And worse on non-SMP, or if the number of processes exceeds the number of
> CPUs. Note, that you will often have to switch between modules very rapidly
> to avoid having large queues that will introduce large latencies, which is
> quite as bad as slow rendering for 3D stuff. Thus scheduling overhead will
> get pretty large.
> 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.

Like Andreaas, I also have doubts concerning the actual concrete
usefulness of multithreading for 3d on (current) SMP-machines.

The real intended (and implicit) benefit that everyone (including
myself) think to is parallel execution in fact. But before choosing
a parallel execution mechanisms (the threads), one may wonder if
parallel 3D rendering is feasible in the architecture.
There seems to be some potential parallelism in the 3d pipeline
(especially as it is a pipeline :- so one can exploit temporal
 parallelism). But this parallelism is for the execution flow
(the program).
Is there also parallelism for data/memory accesses between
the various parts of the 3d pipeline (as it appears to be
defined within GGI3D) ? [1]

However, stricto senso 'better scaling' is probably true.

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).

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. [2] 

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... ;-)))

See you,


[1] As you may understand, it is not useful to have several
 parallel programs executing in parallel if they use the same
 data (for read&write): you need to arbitrate access to this
 data and you end up with a pretty sequential thing.
[2] This is just a probability. But it is hopefully higher
 than betweem two parts of the same rendering pipeline.

Reply via email to