On Fri, 29 Nov 2002 07:55:52 -0700 Brian Paul <[EMAIL PROTECTED]> wrote:
> Felix Kühling wrote: > > > > My approach was basically inspired by the fact that there is something > > in mesa that is called "pipeline". So I thought, why not implement it > > like a real pipeline. If we really want to parallelize MESA, then we > > should consider all options. I'm probably biased towards my proposal ;-) > > > A few years ago another group developed "pmesa": http://pmesa.sourceforge.net/ > You might look at that. I had a look at their page. The last news is from april 2000. Looks dead. > I think someone else brought this up on the Mesa-dev or DRI list earlier > this year. I have to say I'm skeptical. I saw his post. He had a slightly different plan. He didn't want to have several chunks of vertex data processed in parallel but exploit independencies of pipeline stages for parallelization. > A hardware TCL driver like the radeon or r200 won't benefit from this. That's not quite true. With what I have in mind, the OpenGL client could continue while another thread is submitting the vertex data to the TCL unit. But you're right, drivers without hardware TCL would benefit more from this. > In most other cases, I think the overhead of parallelization will result > in very modest speed-ups, if any. > > The only situation in which I can see benefit is when applications draw > very long primitive strips (many thousands of vertices). In that case, > splitting the N vertices into N/P pieces for P processors and transforming > them in parallel would be the best approach. I think that's what pmesa did. That's right. > Implementing a true threaded pipeline could be very compilicated. State > changes are the big issue. If you stall/flush the pipeline for every > state change you wouldn't gain anything. The alternative is to associate > the GL state with each chunk of vertex data as it passes through the > pipeline AND reconfigure the pipeline in the midst of state changes. > Again, I think this would be very complicated. That's what I had in mind. > As for Chromium, there are situations in which multiprocessors can be > helpful, but it depends largely on the nature of the application and > the best speed-ups come from parallelizing the application itself so > that multiple threads of instances of the application all issue rendering > commands in parallel to an array of graphics cards. > > With modern graphics cards, the bottleneck is often the application itself: > the card starves because the app can't issue rendering commands and vertex > data fast enough. Yeah, I hardly see 100% CPU usage with 3D applications on my Radeon 7500. But the latest Quake3 point release has some multithreading support. They must have seen some benefit from this. > So, feel free to experiment with this but realize that you may be dissapointed > with the results with typical applications. I think I'll give it a shot. > > -Brian > Thanks for the pointers, 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
