Brian Paul wrote:
>
> Kendall Bennett wrote:
> > Currently Mesa does all geometry and lighting transformations into
> > its own internal geometry pipelin, which is in it's own internal
> > format. The geometry pipeline is then read by the back end graphics
> > hardware driver (ie: our Direct3D or the 3dfx driver), re-formatted
> > into the format required by the hardware driver (ie: 3dfx vertex
> > format, or Direct3D vertex format) and then that re-formatted data is
> > passed to the hardware. Hence every vertex undergoes an unneeded
> > copying and re-formatting step between the internal geometry pipeline
> > and the hardware specific geometry structures.
> >
> > In essence this means that all the work that Keith W. and others have
> > been doing on speeding up the geometry pipeline is for nothing unless
> > this data copying and re-formatting can be avoided.
> >
> > The only way I can see that this can be avoided, it to re-structure
> > the Mesa geometry pipeline so that it's internal geometry pipeline
> > can be restructured to be in the exact same format as the hardware
> > driver requires. This may in the end require that hardware drivers
> > also contain the back end geometry pipeline, so that we can still
> > have plug in back end hardware drivers, but they are optimised for
> > the hardware in question (this will also tie in nicely with hardware
> > geometry processing). Also this re-formatting avoidance will be
> > rather important for DMA driven hardware, since in that environment
> > maximum performance will only be achieved if Mesa can be transforming
> > vertex data directly into the hardware DMA buffers where appropriate.
Correct. In general, the problem as I see it is that the internal
structure of Mesa is insufficiently modular. We need to be able to cut
in hardware-specific rendering backends at any point in the pipeline.
Someone saying almost exactly this a while back was what motivated me to
design LibGGI3D, which is an abstract framework for constructing 3D
rendering pipelines out of modules.
My goal is to introduce a LibGGI3D target into Mesa and gradually over
time expand the number and scope of the available modules until all of
Mesa's guts (including all of the existing targets) have been
re-implemented as a set of pluggable rendering modules and the Mesa API
itself is just an administrative layer which implements the Mesa API
using whatever LibGGI3D modules are appropriate for the platform and
available acceleration resources.
But, LibGGI3D is not ready for prime time yet, and we do have an
immediate need for the higher-level pipeline cutins as Kendall
mentioned.
> I don't have experience with hardware DMA data formats. Perhaps
> someone can educate us.
Well in principle the data formats can be whatever the hardware
designers want. In practice, all the newest PC-based accelerators use
Direct3D immediate mode as the front-end to the triangle setup engine,
which means that you fill your DMA buffers with full or partial
D3DTLVERTEX structures, set up texture buffers and blend states and
whatnot and then kick off the DMA transfer. A D3DTLVERTEX structure
looks like this:
typedef struct D3DTLVERTEX
{
float32 x, y, z, w;
uint32 diffuse_color, specular_color;
float32 u0, v0, u1, v1;
}
Jon
_______________________________________________
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
