On Fri, Nov 29, 2002 at 11:15:19AM +0000, José Fonseca wrote: > 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.
The problem with that approach is that you have to do one of a) sort primitives in screen space and assign non-overlapping primitives to the different pipelines; b) keep multiple buffers and blend them together at some point. If you do a), you can have parallelism after the transformation stage or have a synchronization point in the middle of the pipelines. b) is horribly slow for a pipeline running completly in software. Stage parallelization is in this case a much better approach. Problem is the final stages of the pipeline are much more CPU intensive than the initial stages (think vertex processing vs. fragment processing), so you can't split pipeline stages equally across threads. -- Marcelo ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
