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