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.
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.
I think this task is not trivial but feasible. It would allow SMP
systems to benefit from the inherent parallelism in the rendering
process.
Regards,
Felix
On Thu, 28 Nov 2002 20:59:08 +0100
Felix Kühling <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I came across the mesa pipeline a couple of times now, reading the mesa
> sources. It struck me that all the pipeline stages are actually executed
> sequentially. Does anyone who is more involved think it would be
> worthwile to process several vertex buffers at a time in parallel
> pipeline stages by having each stage in its own thread? I realize that
> only drivers/cards without hardware TCL would benefit from this (or
> fallback cases where TCL doesn't work).
>
> Thoughts? In case this is considered useful I'm volunteering to make
> this a small project of mine.
__\|/__ ___ ___ ___
__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
