On Fri, 29 Nov 2002 11:15:19 +0000 José Fonseca <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 29, 2002 at 10:19:52AM +0100, Felix Kühling wrote: > > Hi, > > > > I got pretty excited about this idea and spent some more thought on it. > > I'm going to share my insights in this mail. Any comments are > > appreciated. > > > > First some high level considerations. Having each pipeline stage in a > > separate thread would lead to a large number of threads (e.g. 9 in the > > case of the radeon driver). Most of the pipeline stages take rather > > short time so that the extra overhead of multi threading and > > synchronization could have a significant impact. Alternatively one could > > use a fixed number N of threads and schedule pipeline stages on them, > > the main thread and N-1 "free" threads. If a "free" thread is available > > the next pipeline stage would be executed on that thread and the OpenGL > > client could continue on the main thread without waiting for all > > pipeline stages to complete. Note that on a non-SMP system there would > > be only the main thread which is equivalent to how the pipeline is > > currently executed. > > 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. > 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. 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. > > There are some functions that would have to flush the pipeline. I'm > > thinking of glXSwapBuffers and glFinish. There might be more (functions > > that access the color or z-buffers directly). Extra care has to be taken > > if there are several pipeline stages which access the color or z-buffers > > like a hardware rendering stage + a software rendering stage for > > fallbacks. I'll call them "drawing" stages. They have to be executed one > > at a time and in the correct order. This can be ensured by flushing all > > higher pipeline stages before running a drawing stage. I'm not sure if > > textures would require any special attention. I'd have to read a bit > > more about that. > > > > If several pipeline stages are running at the same time for different > > vertex buffers, they have to work with separate copies of the GLcontext > > reflecting the state at the time the buffer was fed into the pipeline. > > It is enough the copy a context only once, when it moves from the main > > thread to a free thread. > > All assumptions have to be very well verified against all existing Mesa > drivers, otherwise a discrete hack can cause havoc... All the hardware specific stages are drawing stages. So only one of them will be executed at a time. I don't see any problem here. One tricky part could be to find out, how much of the context actually has to be copied. Obviously, all data that is modified by the pipeline stages needs to be copied. Everything that is read only can be shared by all context copies. > > > > > I think this task is not trivial but feasible. It would allow SMP > > systems to benefit from the inherent parallelism in the rendering > > process. > > It surely seems interesting! ;-) > > José Fonseca Felix __\|/__ ___ ___ ___ __Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____ [EMAIL PROTECTED] >o<__/ \___/ \___/ at the same time! ------------------------------------------------------- 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
