English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
[Caml-list] 32 bit floats, SSE instructions
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-06-09 (08:00)
From: Brandon J. Van Every <vanevery@i...>
Subject: RE: [Caml-list] 3D graphics debate
For the uninitated, what you are about to witness is best described as a
'culture clash'.  On the one hand you have Mr. PhD, represented by John
Harrop.  On the other you have an almost totally self-taught erstwhile
optimization jock, represented by yours truly.

Jon Harrop wrote:
> Brandon J. Van Every wrote:
> > Joh Harrop wrote:
> > >
> > > I think you are exaggerating cost of the "abstraction" of
> > > reordering the arguments of a function.
> >
> > And I'm thinking you've never done high performance
> > anything in a big
> > architecture for a living.  Prove me wrong.
> Oh ok then - I've just passed my PhD in computational and
> theoretical physics from the University of Cambridge.

Thank you for finally showing your true colors.  It is irritating to
waste time with people who give the appearance of knowing nothing about
3D graphics performance, yet have lotsa suggestions about why AoS vs.
SoA "really doesn't matter."  Frankly, you either know why it matters
and have been pulling my leg, or you are too far into the abstractions
of your problem domain to care about the performance implications of low
level 3D operations.  I suspect that happens frequently to researchers
whose products never become industrially mature, and consequently never
have code monkeys seeking to tweak the hell out of their basic
architectures.  You prototype, you ain't optimizing.

> One is a multiresolution representation of a planet which is
> dynamically tesselated to give just enough detail for rendering:
> http://www.chem.pwf.cam.ac.uk/~jdh30/programming/opengl/lod/index.html
> if the planet were represented to enough detail using flat
> data structures
> (equivalent to the cell grid) for that demo it would require
> 2^80 floats. Had
> I known OCaml at the time, this would have been a much
> smaller and faster program. :-)

I've obsessed about rendering planets the size of Mars (roughly 1/4
surface area of Earth) down to 10 km/hex detail on a GeForce2.  With
each hex containing unique type data, not some fractal repetitive thing.
It is too much detail to actually see and use in a game (your website
indicates interest in games).  I am not impressed with your argument
about "flat data structures," at least not from what you have given
above.  To make a game is about controlling visualization and zoom, so
that the data is actually usable.  I've worked on hierarchical methods,
compatible with spherical hexified icosahedral topologies.  Too much
hierarchy, you ain't gonna get through the rendering or the game.

If you consider the terrain mapping of *real* planets, with real unique
surface data, you have a lot more to consider.  My planet was only a
game planet, at a relatively coarse resolution, but it was all unique

All of your subtriangle stuff is stuff I've considered and abandoned as
too complex in the real world to implement a game, after reams and reams
of paper expended, and some code too.  A *game* surface has to be
addressable and fundamentally usable as a programming API for other
things, like the AI code.  I went with Barycentric coordinates and that
proved to be a mistake.  Too complex.  My next attempt will not be based
on the polygonally segmented icosahedron, but rather, upon a generalized
error reduction mesh with a simple grid for rapid lookup.

> Aren't we talking about a 4xn matrix rather than an nx4 matrix?

I don't even know why the hell you started talking about matrix
anything.  The vast majority of problems I've encountered in 3D graphics
are ad hoc accept / reject processing.

> > > Can these algorithms not be transformed so that they
> > > access more coherently?
> >
> > No, dammit!  You Just Don't Get It [TM].  When someone tells you
> > something is "an invasive programming model," they're telling you
> > they're not looking for the opportunity to rewrite their
> > whole software
> > architecture from scratch just because you personally think
> > SoA might be more kewl than AoS.
> Well, if you want to optimise your program and you wrote it
> badly the first time... ;-)

"Your program?"  Have you simply never worked in an industrial capacity?
Where did you get this UberDesigner control over "your program?"

> I would say that I am somewhat familiar with the concepts
> involved. My concern
> is that I have only ever come across your optimisation
> problems in the
> context of shoehorning algorithms into using flat containers.

Maybe you just don't think very well in terms of flat containers and
that's Your Nature [TM].  It is certainly not my nature to envision 3D
graphics problems as hierarchies, unless they're exceedingly flat
hierarchies.  I can definitely point to some problems where my approach
is appropriate and yours isn't.  In other scenarios it's a matter of
personal style, and I generally put my money on "simple implementation,
rely on 3D HW to speed up linearly."  For instance, a simple grid for
planetary addressing in buckets rather than your elaborate hierarchical

> > So was it 'dabbler' or not then?  I suppose you think that the
> > implementation complexity of multiresolution representations is
> > desireable in an industry where a significantly faster card
> > ships every 6 months?
> Absolutely. It separates the men from the boys...

In terms of "I'm some badass algorithm guy," or in terms of "I can
actually ship product and make profit?"  Here we separate the ivory
tower from industrial reality.

Cheers,                         www.indiegamedesign.com
Brandon Van Every               Seattle, WA

"We live in a world of very bright people building
crappy software with total shit for tools and process."
                                - Ed Mckenzie
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.693 / Virus Database: 454 - Release Date: 5/31/2004

To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners