On Fri, Nov 29, 2002 at 01:13:22PM +0100, Felix Kühling wrote: > On Fri, 29 Nov 2002 11:15:19 +0000 > José Fonseca <[EMAIL PROTECTED]> wrote: > > I think that one thing that must be thought is whether the parallelism > > should be in the pipeline stages or in the pipeline data, i.e., if we > > I am not sure I understand the difference. The idea of a pipeline is > that you split the tasks performed on data into several stages. Mesa > does this part already. Then while one package is in stage 1 another one > can be processed in stage 2 at the same time. So I think I have > parallelism both in pipeline data and the stages. >
Let'me ilustrate with an example. Image you have 1000 polygons to process (i.e., transform, clip, build vertex buffers, and render). If you have a SMP computer with 4 processors you can make use of parallelism in at least two ways: a) Have a processor do the transform of the 1000 polygons, another do the clipping, ... etc. b) Have a processor do the transform+clipping+... of 250 polygons, have another do the same for another 250 polygons, ... etc. > > should partition a stage for each thread (as you're suggesting), or if > > there is enough data running through the pipeline making it worth to > > have to a whole pipeline for each thread, each processing a part of the > > primitives. > > Having one thread for each pipeline stage was my first idea. The > alternative approach I tried to explain could be implemented in a way > that, once data is processed by a free thread, it runs through all > remaining pipeline stages in that same thread. Only, if no free thread > is available, processing starts on the main thread. I understood your second proposal, but you still have one thread doing a a pipeline stage processing all the data (case a) above). > > Still semaphores have to be used to synchronize the threads (including > the main thread) so that data packets cannot "overtake" each other. In the > end, the drawing has to occur in the same order as data was fed into the > pipeline. > > > The later is the approach taken e.g., in chromium > > http://chromium.sourceforge.net , but actually I don't know if for any > > application besides scientific visualization a pipeline handles so many > > primitives at a time. For applications such as games, state changes (like > > texture changes) seem to happen too often for that. > > I just had a look at their web page. They take a very different approach > to parallelizing the rendering task. They are targeting clusters, > not SMP systems. Why do you dismiss it so quickly? Have you seen http://www.cs.virginia.edu/~humper/chromium_documentation/threadedapplication.html ? There is nothing in their approach specific to clusters. Using approach b) yeilds much better parallelism than a) because each thread can work independently of each other, and therefore there is less waits/lock contentions/etc. Nevertheless, it isn't worth if you're processing 50 polygons at at time. Still if you have 50 polygons in blue, 50 in red, and 50 in texture A, and you run all them seperately in different processors will probably still have better parallelism. I'm not sure which approach will give better speedups, but this has to be considered. Perhaps it would be a good idea to talk with the Chromium guys to know what the order of speedups they achieve in SMP systems on usual applications. José Fonseca __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com ------------------------------------------------------- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
