mesa3d-dev

[Mesa3d-dev] rasterize or rendering?

[rt <rt...@um...>]

does PointFunc, QuadFunc, LineFunc and the like provide for
accelerated rasterization, or accelerated rendering, or both? it looks
like the 3Dfx driver acclerates the rendering - is this correct? the
xmesa driver, on the other hand, looks like it is concerned with
rasterization. if they provide for both, how does one get them to provide
for accelerated rendering working with a list of vertices?

thanks in advance,
rt

Re: [Mesa3d-dev] rasterize or rendering?

[Gareth H. <ga...@va...>]

rt wrote:
> 
> does PointFunc, QuadFunc, LineFunc and the like provide for
> accelerated rasterization, or accelerated rendering, or both? it looks
> like the 3Dfx driver acclerates the rendering - is this correct? the
> xmesa driver, on the other hand, looks like it is concerned with
> rasterization. if they provide for both, how does one get them to provide
> for accelerated rendering working with a list of vertices?

I'll take a stab at this...

It kind of depends on which version of Mesa you're looking at. 
Essentially what used to happen was core Mesa would allow a
rasterization-level driver (one that takes a batch of primitives and can
render them natively, like the pre-T&L hardware drivers) to hook out the
primitive functions.  Drivers would supply functions if it could handle
rendering with the current state.

If not, it would set them to NULL and mark the IndirectTriangles
bitfield with DD_TRI_SW_RASTERIZE and the like.  Core Mesa would then
plug in a software triangle function, which spits out spans that must be
handled by the span-level interface.  For hardware drivers, the
implementation of the span-level interface typically involves taking a
bunch of pixels and sticking them in the framebuffer (or vice versa, for
read functions).

In the latest, still-under-active-development Mesa code, if the driver
hooks out the primitive functions and it can't handle the primitives
natively, it must call the software rasterizer itself.  The same thing
happens with the software primitive functions, they still spit out spans
that are copyied to/from the framebuffer (typically).

This is a pretty rough overview, completely from memory (so it may be
slightly inaccurate).  I'm a little confused by the terminology you use
-- it's more a matter of rasterization-level versus
dumb-framebuffer-level (or perhaps the original Voodoo Graphics)
drivers, rather than rasterize versus render.

-- Gareth

Re: [Mesa3d-dev] rasterize or rendering?

[rt <rt...@um...>]

	what about specialized hardware that performs the rendering based
on a final list of vertices? how can a hardware driver deal with this
situation? do hardware drivers operate on lists of vertices?

rt

On Tue, 6 Feb 2001, Gareth Hughes wrote:

> rt wrote:
> > 
> > does PointFunc, QuadFunc, LineFunc and the like provide for
> > accelerated rasterization, or accelerated rendering, or both? it looks
> > like the 3Dfx driver acclerates the rendering - is this correct? the
> > xmesa driver, on the other hand, looks like it is concerned with
> > rasterization. if they provide for both, how does one get them to provide
> > for accelerated rendering working with a list of vertices?
> 
> I'll take a stab at this...
> 
> It kind of depends on which version of Mesa you're looking at. 
> Essentially what used to happen was core Mesa would allow a
> rasterization-level driver (one that takes a batch of primitives and can
> render them natively, like the pre-T&L hardware drivers) to hook out the
> primitive functions.  Drivers would supply functions if it could handle
> rendering with the current state.
> 
> If not, it would set them to NULL and mark the IndirectTriangles
> bitfield with DD_TRI_SW_RASTERIZE and the like.  Core Mesa would then
> plug in a software triangle function, which spits out spans that must be
> handled by the span-level interface.  For hardware drivers, the
> implementation of the span-level interface typically involves taking a
> bunch of pixels and sticking them in the framebuffer (or vice versa, for
> read functions).
> 
> In the latest, still-under-active-development Mesa code, if the driver
> hooks out the primitive functions and it can't handle the primitives
> natively, it must call the software rasterizer itself.  The same thing
> happens with the software primitive functions, they still spit out spans
> that are copyied to/from the framebuffer (typically).
> 
> This is a pretty rough overview, completely from memory (so it may be
> slightly inaccurate).  I'm a little confused by the terminology you use
> -- it's more a matter of rasterization-level versus
> dumb-framebuffer-level (or perhaps the original Voodoo Graphics)
> drivers, rather than rasterize versus render.
> 
> -- Gareth
> 
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> http://lists.sourceforge.net/lists/listinfo/mesa3d-dev
> 

Re: [Mesa3d-dev] rasterize or rendering?

[Gareth H. <ga...@va...>]

rt wrote:
> 
>         what about specialized hardware that performs the rendering based
> on a final list of vertices? how can a hardware driver deal with this
> situation? do hardware drivers operate on lists of vertices?

Perhaps you should take a look at some of the DRI drivers.  Basically
all of them do exactly this (mga, i810, r128 and radeon at least).

-- Gareth

Re: [Mesa3d-dev] rasterize or rendering?

[Keith W. <ke...@va...>]

rt wrote:
> 
>         what about specialized hardware that performs the rendering based
> on a final list of vertices? how can a hardware driver deal with this
> situation? do hardware drivers operate on lists of vertices?
> 

This handled by overriding the decomposition to triangles at one of two
levels.

The render stage is parameterized with a table of functions which handle whole
begin/end objects.  In mesa 3.5 these are called ctx->Driver.RenderTabXYZ. 
These are called for unclipped primitives only.  You can override these to
just emit vertices directly. 

The drivers we have don't do this.  Instead they take a seperate approach of
overriding the whole render stage.  In the mesa-3-5 branch on dri cvs, the
i810 and radeon drivers implement a specialized render stage that emits strips
and other primitives directly to hardware in strip (or whatever) order.  This
is probably closest to what you are looking for.

Keith

Re: [Mesa3d-dev] rasterize or rendering?

[rt <rt...@um...>]

> The drivers we have don't do this.  Instead they take a seperate approach of
> overriding the whole render stage.  In the mesa-3-5 branch on dri cvs, the
	
	Is this the approach in 3.4? 

	rt

-------------
rt
734-332-4562

"Most people's lives are taken up with 
a great many trivial things that
they don't really care about, but 
which they feel they have to
do. I just don't do that."
	- esr

Re: [Mesa3d-dev] rasterize or rendering?

[Keith W. <ke...@va...>]

rt wrote:
> 
> > The drivers we have don't do this.  Instead they take a seperate approach of
> > overriding the whole render stage.  In the mesa-3-5 branch on dri cvs, the
> 
>         Is this the approach in 3.4?
> 

To a certain extent -- the 'fastpath' stuff in the dri drivers and in
Mesa/src/FX overrides the whole pipeline, and does clipping, etc in an
hardware-optimized fashion.  It doesn't attempt to make use of hardware strip
support as it's not appropriate for the DrawElements case that is being
accelerated.  The mga 'eltpath' uses hardware indexed vertices, which is
another way of reducing bus traffic.

Keith

Re: [Mesa3d-dev] rasterize or rendering?

[rt <rt...@um...>]

	Okay. I see. A quick grep in src/FX doesn't reveal exactly where
the fastpath stuff hooks into the driver framework. How does it, or
rather, who calls fxDDFastPathInit()?

	rt

On Tue, 6 Feb 2001, Keith Whitwell wrote:

> rt wrote:
> > 
> > > The drivers we have don't do this.  Instead they take a seperate approach of
> > > overriding the whole render stage.  In the mesa-3-5 branch on dri cvs, the
> > 
> >         Is this the approach in 3.4?
> > 
> 
> To a certain extent -- the 'fastpath' stuff in the dri drivers and in
> Mesa/src/FX overrides the whole pipeline, and does clipping, etc in an
> hardware-optimized fashion.  It doesn't attempt to make use of hardware strip
> support as it's not appropriate for the DrawElements case that is being
> accelerated.  The mga 'eltpath' uses hardware indexed vertices, which is
> another way of reducing bus traffic.
> 
> Keith
> 
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> http://lists.sourceforge.net/lists/listinfo/mesa3d-dev
> 

-------------
rt
734-332-4562

"Most people's lives are taken up with 
a great many trivial things that
they don't really care about, but 
which they feel they have to
do. I just don't do that."
	- esr

Re: [Mesa3d-dev] rasterize or rendering?

[Keith W. <ke...@va...>]

rt wrote:
> 
>         Okay. I see. A quick grep in src/FX doesn't reveal exactly where
> the fastpath stuff hooks into the driver framework. How does it, or
> rather, who calls fxDDFastPathInit()?
> 
>         rt
> 

The init function is called at startup to initialize some static data.

The faspath code hooks into 'BuildPrecalcPipeline' or something like that. 
Consider looking at 3.5 or at least a DRI driver; the 3.4 fx driver is pretty
crufty.

Keith