From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id DAA05744; Wed, 9 Jun 2004 03:19:42 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id DAA05844 for ; Wed, 9 Jun 2004 03:19:41 +0200 (MET DST) Received: from outbound28-2.lax.untd.com (outbound28-2.lax.untd.com [64.136.28.160]) by concorde.inria.fr (8.12.10/8.12.10) with SMTP id i591JdSH012591 for ; Wed, 9 Jun 2004 03:19:39 +0200 Received: from outbound28-2.lax.untd.com (smtp04.lax.untd.com [10.130.24.124]) by smtpout03.lax.untd.com with SMTP id AABANN3NLAX644GS for (sender ); Tue, 8 Jun 2004 18:19:06 -0700 (PDT) Received: (qmail 24087 invoked from network); 9 Jun 2004 01:18:32 -0000 Received: from 66-52-237-168.sttl.dial.netzero.com (HELO vangogh) (66.52.237.168) by smtp04.lax.untd.com with SMTP; 9 Jun 2004 01:18:32 -0000 From: "Brandon J. Van Every" To: "caml" Subject: [Caml-list] 3D graphics debate Date: Tue, 8 Jun 2004 18:28:15 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <200406090125.24112.jdh30@cam.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-ContentStamp: 18:9:688626010 X-UNTD-OriginStamp: CI84cOLHFqh7Zd2QWkwvEFvwyO3T/pIsPQZphDk9MRicE+as+Y5QMvCjL/DwYZ+5 X-Miltered: at concorde with ID 40C665AB.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; brandon:99 posts:01 brandon:99 mama:99 mamma:99 indicative:99 complexities:01 traversing:01 model:01 abstraction:01 reordering:01 divorced:99 higher-level:01 low-level:01 low-level:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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