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