🚀 go-pugleaf

In article <11588@sun13.scri.fsu.edu>, rms@well.sf.ca.us (richard marlon stein) writes:
|> I would like to PixelPlanes hammer on a 1 Terabyte dataset.

    It would take an awfully long time, even if we had that much
memory :-) I'm kinda hoping to play with large terrain datasets on
Pixel-Flow, since they're a ready source of interesting, complex
geometry. I don't think even the Magellan Venus global topography map
approaches 1 TB, however.

    I'm also not sure what your point is. You originally made a claim
that Pixel-Flow was not "truly scalable", which I and Marc Olano, who
are both members of the Pixel-Flow team, have refuted. Pixel-Planes 5
is an older and different architecture. Part of the purpose of PxFl is
to build a machine that does not suffer from the constraints and
problems we learned about from Pxpl5.

    Switching gears (maybe this should be a different thread):

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

    I started with your one-sentence description:

	"I advocate a tessellated display approach myself, where each
	tessellation element owns a processor, framebuffer, and
	display."

    and made some comments about inherent problems with the
screen-space decomposition this *appears* (that's why I said "If you
mean that...") to refer to. We have a lot of experience with these
problems, since Pxpl5 suffers from them.

    I'd be interested in hearing what SCVS actually is, but if you
won't or can't provide any more detail, there's no basis for further
discussion. Good luck building your machine. I look forward to
discussing it whenever you can describe it in public.

    Jon (leech@cs.unc.edu)
    __@/

--
Moderated by SCRI Vis <>           Submissions to: graphics@scri1.scri.fsu.edu
Guy, John R. Murray   <> Administrivia to: graphics-request@scri1.scri.fsu.edu