Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!apple!usc!ucsd!dog.ee.lbl.gov!pasteur!miro.Berkeley.EDU!seth
From: seth@miro.Berkeley.EDU (Seth Teller)
Newsgroups: comp.sys.sgi
Subject: Re:  feedback() limitations?
Message-ID: <9819@pasteur.Berkeley.EDU>
Date: 16 Dec 90 19:57:25 GMT
References: <9012151528.AA06259@karron.med.nyu.edu>
Sender: news@pasteur.Berkeley.EDU
Reply-To: seth@miro.Berkeley.EDU (Seth Teller)
Organization: University of California at Berkeley
Lines: 29

In article <9012151528.AA06259@karron.med.nyu.edu> karron@cmcl2.nyu.edu writes:
>My understanding from TFM and sgi is that they don't want people using the
>feedback buffer.... [Y]ou have to wait for the answer from the 
>pipeline, and that ruins any parallelism you might get from the pipeline.

>Cheers! [guess who this msg was from-- ed.]

i'm not sure what it means for sgi not to 'want' us to do something...
does that mean we shouldn't do it?

as for using feedback, i'm using it precisely because it's the ONLY 
way to get what i need (a description of the graphics that appear 
in my window, in screen coords), short of emulating the entire pipe
in (my own) software.

the context is that, with feedback, it's easy to write a package
that transforms gl program output into stuff suitable for page
description languages like postscript.  yes, gl() is a pdl too;
but it's got to be filtered by addition of viewpoint, lighting, 
clipping, etc.  to be worth anything statically.

so, can anyone answer my original questions?  what are the size
limitations on feedback?  why is the buffer size limited?  can this
be gotten around?  for example, if i'm drawing a NURBS surface and
want all the polygons back, how can i avoid overflowing the buffer?
[splitting the surface into subregions and drawing them separately
won't work for me, due to technical reasons that i can't go into here.]

seth