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

[Jamie F. <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).
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.

Have you actually implemented VIPM on... that machine? :) Some sort of
algorithms-style section in the support newsgroup would be nice, and I could
stop waffling and talk specifics.... :) Talk about LoD would be useful. I'll
post something....

I know some stuff about other consoles... but AFAIK, I can't say which or how
much. Aren't NDAs fun? :)

Jamie


Tom Forsyth wrote:

> > From: Jamie Fowlston [mailto:j.f...@re...]
>
> [snip]
>
> > Not regardless of hardware. For us, drawing several instances
> > of the same model
> > saves us DMA bandwidth. CLOD trashes the ability to do that.
>
> VIPM won't. Since you use the same vertex data for all levels of detail,
> multiple instances are very cheap. All you change is a bunch of indices. On
> two of the future consoles I know well enough(*) to comment on, this will be
> nice and fast. You'll need to DMA across the new indices, but that's tiny
> amounts of memory. You may even be able to do the VIPM expands/collapses on
> the ... you know ... thing that does the transforms - the expand/collapse
> routine is absurdly simple. Which will make multiple instances awesomely
> cheap!
>
> Oh dear - I'm off again about VIPM. Sorry list :-)
>
> > Polygons are very
> > cheap to draw, so we might as well draw them.... Unless
> > anyone else knows
> > better? :)
> >
> > Maybe when we've had more experience of the machine we'll
> > change our minds. :)
> >
> > Jamie
>
> Tom Forsyth - Muckyfoot bloke.
> Whizzing and pasting and pooting through the day.
>
> (*) The one I don't know about, I knew exactly one hard fact about it - its
> name. And then they changed it, and I can't remember what to. So I now know
> precisely zero about it :-)
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list