Re: [Algorithms] VIPM on a machine with DMA :)

[Jamie F. <j.f...@re...>]

Tom Forsyth wrote:

> > From: Jamie Fowlston [mailto:j.f...@re...]
> >
> >
> > Still have to DMA the vertex data, which is larger for VIPMed
> > models (am I
> > right? I've not implemented VIPM, but think I've understood
> > the general idea).
>
> No, the vertex data is precisely as big as your most-detailed model - that
> is, the most detailed model you want to draw that frame (or that instance or
> whatever). There is zero bloating of vertex data.

That sounds a lot saner then.

>
>
> The index data is indexed lists, so that's very slightly bloated from
> indexed strips in some cases, but probably not so you'd notice - indices are
> tiny compared to the vertices anyway.

True. Just using indices in the first place can significantly slow things down,
though.... Hmmm. Rethink time on aspects of inherited graphics engine. Not so
sure about that now... depends on vertex reuse.... Possibilities there.

> And the collapse/expand info is
> moderately big thinking about it (12 bytes per collapse on average I think -
> I can't remember), so it may not be a win to do the collapse/expand on the
> "non-CPU unit" - who can tell? It's pretty quick on both to be honest.

That's too much data for us if it turns into roughly 12 bytes per vertex.

>
> > So total transfer is larger than it would be for non-VIPMed
> > model. We're
> > expecting to be DMA speed constrained rather than draw speed
> > constrained.
>
> Indeed, that's what I woudl expect too - the DMA seems to be the hardest
> thing to get right about the machine. But fortunately there is no bloat. Go
> and read Charles Bloom's excellent VIPM tutorial (one day I'll get around to
> doing my own - actually, there's not much point - it'll be identical to
> Charles'). (http://208.55.130.3/3d/ - sixth link down).

I've been meaning to :) I'm too busy to do the things that would save me
time.... :)

Jamie