home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / graphics / research / 408 < prev    next >
Encoding:
Internet Message Format  |  1992-12-24  |  2.5 KB
  1. Path: sparky!uunet!munnari.oz.au!spool.mu.edu!sdd.hp.com!swrinde!gatech!mailer.cc.fsu.edu!sun13!cs.unc.edu
  2. From: leech@cs.unc.edu (Jon Leech)
  3. Newsgroups: comp.graphics.research
  4. Subject: Re: Scalability
  5. Message-ID: <11602@sun13.scri.fsu.edu>
  6. Date: 24 Dec 92 17:58:48 GMT
  7. References: <11588@sun13.scri.fsu.edu>
  8. Sender: news@sun13.scri.fsu.edu
  9. Lines: 47
  10. Approved: murray@vs6.scri.fsu.edu
  11. X-Submissions-To: graphics@scri1.scri.fsu.edu
  12. X-Administrivia-To: graphics-request@scri1.scri.fsu.edu
  13.  
  14.  
  15. In article <11588@sun13.scri.fsu.edu>, rms@well.sf.ca.us (richard marlon stein) writes:
  16. |> I would like to PixelPlanes hammer on a 1 Terabyte dataset.
  17.  
  18.     It would take an awfully long time, even if we had that much
  19. memory :-) I'm kinda hoping to play with large terrain datasets on
  20. Pixel-Flow, since they're a ready source of interesting, complex
  21. geometry. I don't think even the Magellan Venus global topography map
  22. approaches 1 TB, however.
  23.  
  24.     I'm also not sure what your point is. You originally made a claim
  25. that Pixel-Flow was not "truly scalable", which I and Marc Olano, who
  26. are both members of the Pixel-Flow team, have refuted. Pixel-Planes 5
  27. is an older and different architecture. Part of the purpose of PxFl is
  28. to build a machine that does not suffer from the constraints and
  29. problems we learned about from Pxpl5.
  30.  
  31.     Switching gears (maybe this should be a different thread):
  32.  
  33. |> One things for sure though, I know when I've been beat. Since the SCVS
  34. |> does not "subdivide" the screen by assigning processors to a specific
  35. |> region of a single display surface, I don't think you are in a
  36. |> position to judge the architecture. Ask Molnar if he'll sign the
  37. |> non-disclosure agreement, and then you can judge.
  38.  
  39.     I started with your one-sentence description:
  40.  
  41.     "I advocate a tessellated display approach myself, where each
  42.     tessellation element owns a processor, framebuffer, and
  43.     display."
  44.  
  45.     and made some comments about inherent problems with the
  46. screen-space decomposition this *appears* (that's why I said "If you
  47. mean that...") to refer to. We have a lot of experience with these
  48. problems, since Pxpl5 suffers from them.
  49.  
  50.     I'd be interested in hearing what SCVS actually is, but if you
  51. won't or can't provide any more detail, there's no basis for further
  52. discussion. Good luck building your machine. I look forward to
  53. discussing it whenever you can describe it in public.
  54.  
  55.     Jon (leech@cs.unc.edu)
  56.     __@/
  57.  
  58. --
  59. Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
  60. Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu
  61.