🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.graphics.research
Article #19

Re: Scalability (was Re: comp.graphics.research)

#19
From: richard marlon stein
Date: Mon, 21 Dec 1992 18:17
47 lines
3101 bytes
In article <11579@sun13.scri.fsu.edu> leech@cs.unc.edu (Jon Leech) writes:
<
<In article <11566@sun13.scri.fsu.edu>, rms@well.sf.ca.us (richard marlon stein) writes:
<|> Try muxing the outputs from 1000 framebuffers into a single analog stream.
<|> I would rather pass on this approach.  The PixelFlow box captures the output
<|> from a composition network rated at 4 Gbytes/s into a single frambeubffer.
<|>
<|> I don't believe this approach is truly scalable either, since its still
<|> an example of the N to 1 mux problem.  So it is, in my opinion, contention
<|> limited (the laws of physics won't cooperate and provide infinite digital
<|> bus or network bandwidth).
<
<    PixelFlow should be extremely scalable. The composition network
<has fixed bandwidth no matter how many renderers are used, and latency
<due to the length of the composition network increases very slowly as
<additional rendering boards are added.
<
<    If you're referring to some other aspect, please explain in more
<detail.
<
<|> I advocate a tessellated display approach myself, where each tessellation
<|> element owns a processor, framebuffer, and display.	The trick is to coordinate
<|> the system temporally.  The scalable concurrent visualization system trades
<|> contention for asynchronous execution.
<
<    If you mean that each processor is responsible for a fixed screen
<area, this approach wastes most of the processors when looking at
<something far away. It also trades off moving pixels for moving
<primitives, and moving primitives is definitely not scalable.
<Pixel-Planes 5 uses a considerably more complex variant of this
<decomposition and partly addresses these concerns.
<--
<    Jon Leech (leech@cs.unc.edu)    __@/

I would like to PixelPlanes hammer on a 1 Terabyte dataset.  One things for sure
though, I know when I've been beat.  Since the SCVS does not "subdivide" the
screen by assigning processors to a specific region of a single display surface,
I don't think you are in a position to judge the architecture.  Ask Molnar if
he'll sign the non-disclosure agreement, and then you can judge.
--rick
-- 
Richard Marlon Stein, Internet: rms@well.sf.ca.us
To those who know what is not known;  The Chronicles of Microwave Jim!

--
Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu
Technical Details
Message-ID: <11588@sun13.scri.fsu.edu>
Path: arc1-ca.pugleaf.net!sparky!uunet!olivea!spool.mu.edu!uwm.edu!caen!sdd.hp.com!swrinde!gatech!mailer.cc.fsu.edu!sun13!well.sf.ca.us
References: <11561@sun13.scri.fsu.edu> <11566@sun13.scri.fsu.edu> <11579@sun13.scri.fsu.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!olivea!spool.mu.edu!uwm.edu!caen!sdd.hp.com!swrinde!gatech!mailer.cc.fsu.edu!sun13!well.sf.ca.us
From: rms@well.sf.ca.us (richard marlon stein)
Newsgroups: comp.graphics.research
Subject: Re: Scalability (was Re: comp.graphics.research)
Message-ID: <11588@sun13.scri.fsu.edu>
Date: 21 Dec 92 18:17:57 GMT
References: <11561@sun13.scri.fsu.edu> <11566@sun13.scri.fsu.edu> <11579@sun13.scri.fsu.edu>
Sender: news@sun13.scri.fsu.edu
Organization: Whole Earth 'Lectronic Link
Lines: 47
Approved: murray@vs6.scri.fsu.edu
X-Submissions-To: graphics@scri1.scri.fsu.edu
X-Administrivia-To: graphics-request@scri1.scri.fsu.edu