[Caml-list] 3D graphics debate

["Brandon J. Van Every" <vanevery@indiegamedesign.com>]

I'm gonna break this into 2 posts, 'cuz I think the 3D graphics debate
should be separated and then die.

Jon Harrop wrote:
> Brandon J. Van Every wrote:
> > ...
> > What utter nonsense!
>
> Yo Mama.

Yo mamma duzn' like yu an dressus yu funny.

> > You ever written a 3D device driver?
>
> Are you trying to write a device driver in OCaml?

3D device driver problems are indicative of graphics problems in
general.  There's not much 'new' at any level of the game.  Just things
that have been committed to HW vs. things that are still waiting to be
committed to HW, with some interrupting complexities in between.
Traversing a cell grid database is no different from rasterizing a
triangle.  3D graphics is one giant self-similar fractal.

> > You do *not*
> > engineer your most basic data structures for infinite flexibility.
>
> You appear to be approximating the two in "two transpose
> formats" with infinity. Are you an astrophysicist?

I don't know why on Earth you'd describe "transposing a matrix" as
representative of implementation options for arbitrary classes of
algorithms.

> > Almost nobody has the luxury of defining things so
> > abastractly that they
> > can switch SoA for AoS whenever they like.  It's a highly invasive
> > change of programming model.
>
> 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.

> > The experiment of SoA has been tried in the 3D graphics industry and
> > found wanting.  All the HW is AoS.
>
> Apart from that "CPU" thing. ;-)

I suppose you think CPU approaches are divorced from the realities of
what underlying HW expects?  You want to retire things quickly, you
don't spread them out all over memory.  Not unless you've got some kind
of super duper programmer visible scatter-gather DMA, and I'm not aware
of anyone building PCs in such configurations.

> My point is that there are likely to be much more productive,
> higher-level optimisations that you could be doing.

It is a wasted point.  Performance jock do that *and* the low-level
optimizations.  The key is sane architecture so you don't have to do
more than a handful of low-level optimizations.

>
> > > The only algorithms which would be significantly affected are
> > > those for which
> > > accesses are to (x_i, y_i, z_i) for random "i" rather than to
> >
> > Oh, the 'only' algorithms.  Crikey.
>
> Are you saying that most of your algorithms require random
> access of that form?

No, I said that *in addition to* that rather common class of algorithms,
even sequential processing is usually accept / reject.  Let's say you've
got SoA for a 4-field vector.  When you accept, you're going to be
touching all 4 arrays.  If you often accept, then your cache is going to
be polluted by all the rejects.  You have made your problem 4 times less
cache coherent than it otherwise would be.  The reality of 3D graphics
processing is you usually need all that info in the structure.  That's
why it's a structure.

> 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.

> > You ever written a 3D graphics pipeline???
>
> I have dabbled in 3D graphics.

Great, a dabbler.  I hope you just have a penchant for understatement.
Otherwise, you're wasting our time.

> > The vast
> > majority of 3D graphics processing is accept / reject
> > testing.
>
> I'd like more, specific examples here. What determines the
> accept or reject?
> What is the consequence of an accept or reject?

I don't have time to educate you on the fundamentals of 3D graphics
processing.  You can find all the classical, basic information via
newsgroups such as comp.graphics.algorithms.  If you want to save a lot
of time going up the learning curve, you could post something like "AoS
or SoA?" and see what people say.  Or Google the archives for them.

> If your programs are bottlenecked by lots of very low-level
> arithmetic over
> huge, flat data structures then you will almost certainly
> benefit from using
> more structured, hierarchical (ideally, multiresolution)
> representations.

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?


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