On Fri, Nov 29, 2002 at 01:20:45PM +, José Fonseca wrote:
> On Fri, Nov 29, 2002 at 01:13:22PM +0100, Felix Kühling wrote:
> > On Fri, 29 Nov 2002 11:15:19 +
> > José Fonseca <[EMAIL PROTECTED]> wrote:
> > > I think that one thing that must be thought is whether the parallelism
> > > should
On Fri, Nov 29, 2002 at 01:13:22PM +0100, Felix Kühling wrote:
> On Fri, 29 Nov 2002 11:15:19 +
> José Fonseca <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Nov 29, 2002 at 10:19:52AM +0100, Felix Kühling wrote:
>
> > > First some high level considerations. Having each pipeline stage in a
> > > sep
On Fri, Nov 29, 2002 at 11:15:19AM +, 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 appli
On Sat, 30 Nov 2002 19:52:50 +
José Fonseca <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 30, 2002 at 08:04:55PM +0100, Felix Kühling wrote:
[snip]
> >
> > Vertex formats are the real problem. Driver functions are called
> > directly from the GL application and modify the driver state bypassing
>
On Sat, Nov 30, 2002 at 08:04:55PM +0100, Felix Kühling wrote:
> On Sat, 30 Nov 2002 17:20:04 +0100
> Felix Kühling <[EMAIL PROTECTED]> wrote:
> > I see the problem. On many state changes, a corresponding driver
> > function is called. In a parallel pipeline implementation, if there is
> > still ve
On Sat, 30 Nov 2002 17:20:04 +0100
Felix Kühling <[EMAIL PROTECTED]> wrote:
> On Fri, 29 Nov 2002 07:55:52 -0700
> Brian Paul <[EMAIL PROTECTED]> wrote:
>
> [snip]
> > Implementing a true threaded pipeline could be very compilicated. State
> > changes are the big issue. If you stall/flush the p
On Sat, 30 Nov 2002 16:24:59 +
Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Felix Kühling wrote:
[snip]
> > I found many state changing callbacks in dd.h which don't seem to be
> > used. Are they left-overs from earlier Mesa versions or did my grep miss
> > something?
>
> Which ones?
Ok, I go
On Fri, 29 Nov 2002 07:55:52 -0700
Brian Paul <[EMAIL PROTECTED]> wrote:
[snip]
> 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 assoc
Felix Kühling wrote:
On Fri, 29 Nov 2002 07:55:52 -0700
Brian Paul <[EMAIL PROTECTED]> wrote:
[snip]
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 alter
On Fri, 29 Nov 2002 22:46:08 +
Ian Molton <[EMAIL PROTECTED]> wrote:
> On Fri, 29 Nov 2002 14:54:30 +0100
> Felix Kühling <[EMAIL PROTECTED]> wrote:
>
> > When the red polygons are
> > to be run through the pipeline and the blue ones aren't finished yet
>
> What if the red ones are transpare
On Fri, 29 Nov 2002 16:59:16 +0100
Felix Kühling <[EMAIL PROTECTED]> wrote:
>
> Yeah, I hardly see 100% CPU usage with 3D applications on my Radeon
> 7500.
Heh me either. Q3 uses bugger all CPU here.
that said, the xmms default GL plugin uses 100% and its NOT software
rendering.
-
On Fri, 29 Nov 2002 16:59:16 +0100
Felix Kühling <[EMAIL PROTECTED]> wrote:
> > 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
On Fri, 29 Nov 2002 13:20:45 +
José Fonseca <[EMAIL PROTECTED]> wrote:
>
> Nevertheless, it isn't worth if you're processing 50 polygons at at
> time. Still if you have 50 polygons in blue, 50 in red, and 50 in
> texture A, and you run all them seperately in different processors
> will probab
On Fri, 29 Nov 2002 14:54:30 +0100
Felix Kühling <[EMAIL PROTECTED]> wrote:
> When the red polygons are
> to be run through the pipeline and the blue ones aren't finished yet
What if the red ones are transparent and overlap the blue ones? they
will have to wait, but perhaps not all of them?
how
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 p
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 propos
On Fri, 29 Nov 2002 13:20:45 +
José Fonseca <[EMAIL PROTECTED]> wrote:
[snip]
>
> Let'me ilustrate with an example. Image you have 1000 polygons to
> process (i.e., transform, clip, build vertex buffers, and render). If
> you have a SMP computer with 4 processors you can make use of
> paralle
On Fri, Nov 29, 2002 at 01:13:22PM +0100, Felix Kühling wrote:
> On Fri, 29 Nov 2002 11:15:19 +
> José Fonseca <[EMAIL PROTECTED]> wrote:
> > 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 a
On Fri, 29 Nov 2002 11:15:19 +
José Fonseca <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 29, 2002 at 10:19:52AM +0100, Felix Kühling wrote:
[snip]
> 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
> sho
On Fri, 29 Nov 2002 11:15:19 +
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
> >
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
On Fri, 29 Nov 2002 10:19:52 +0100
Felix Kühling <[EMAIL PROTECTED]> wrote:
>
> I think this task is not trivial but feasible. It would allow SMP
> systems to benefit from the inherent parallelism in the rendering
> process.
Sounds pretty sweet.
now make a patch ;-)
--
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
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
24 matches
Mail list logo
