home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / graphics / research / 406 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  3.0 KB
  1. Path: sparky!uunet!olivea!spool.mu.edu!uwm.edu!caen!sdd.hp.com!swrinde!gatech!mailer.cc.fsu.edu!sun13!well.sf.ca.us
  2. From: rms@well.sf.ca.us (richard marlon stein)
  3. Newsgroups: comp.graphics.research
  4. Subject: Re: Scalability (was Re: comp.graphics.research)
  5. Message-ID: <11588@sun13.scri.fsu.edu>
  6. Date: 21 Dec 92 18:17:57 GMT
  7. References: <11561@sun13.scri.fsu.edu> <11566@sun13.scri.fsu.edu> <11579@sun13.scri.fsu.edu>
  8. Sender: news@sun13.scri.fsu.edu
  9. Organization: Whole Earth 'Lectronic Link
  10. Lines: 47
  11. Approved: murray@vs6.scri.fsu.edu
  12. X-Submissions-To: graphics@scri1.scri.fsu.edu
  13. X-Administrivia-To: graphics-request@scri1.scri.fsu.edu
  14.  
  15. In article <11579@sun13.scri.fsu.edu> leech@cs.unc.edu (Jon Leech) writes:
  16. <
  17. <In article <11566@sun13.scri.fsu.edu>, rms@well.sf.ca.us (richard marlon stein) writes:
  18. <|> Try muxing the outputs from 1000 framebuffers into a single analog stream.
  19. <|> I would rather pass on this approach.  The PixelFlow box captures the output
  20. <|> from a composition network rated at 4 Gbytes/s into a single frambeubffer.
  21. <|>
  22. <|> I don't believe this approach is truly scalable either, since its still
  23. <|> an example of the N to 1 mux problem.  So it is, in my opinion, contention
  24. <|> limited (the laws of physics won't cooperate and provide infinite digital
  25. <|> bus or network bandwidth).
  26. <
  27. <    PixelFlow should be extremely scalable. The composition network
  28. <has fixed bandwidth no matter how many renderers are used, and latency
  29. <due to the length of the composition network increases very slowly as
  30. <additional rendering boards are added.
  31. <
  32. <    If you're referring to some other aspect, please explain in more
  33. <detail.
  34. <
  35. <|> I advocate a tessellated display approach myself, where each tessellation
  36. <|> element owns a processor, framebuffer, and display.    The trick is to coordinate
  37. <|> the system temporally.  The scalable concurrent visualization system trades
  38. <|> contention for asynchronous execution.
  39. <
  40. <    If you mean that each processor is responsible for a fixed screen
  41. <area, this approach wastes most of the processors when looking at
  42. <something far away. It also trades off moving pixels for moving
  43. <primitives, and moving primitives is definitely not scalable.
  44. <Pixel-Planes 5 uses a considerably more complex variant of this
  45. <decomposition and partly addresses these concerns.
  46. <--
  47. <    Jon Leech (leech@cs.unc.edu)    __@/
  48.  
  49. I would like to PixelPlanes hammer on a 1 Terabyte dataset.  One things for sure
  50. though, I know when I've been beat.  Since the SCVS does not "subdivide" the
  51. screen by assigning processors to a specific region of a single display surface,
  52. I don't think you are in a position to judge the architecture.  Ask Molnar if
  53. he'll sign the non-disclosure agreement, and then you can judge.
  54. --rick
  55. -- 
  56. Richard Marlon Stein, Internet: rms@well.sf.ca.us
  57. To those who know what is not known;  The Chronicles of Microwave Jim!
  58.  
  59. --
  60. Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
  61. Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu
  62.