Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!rutgers!att!tut.cis.ohio-state.edu!ucbvax!UCBVAX.BERKELEY.EDU!"Dan Karron From: Dan Karron@UCBVAX.BERKELEY.EDU Newsgroups: comp.sys.sgi Subject: Re: feedback() limitations? Message-ID: <9012151528.AA06259@karron.med.nyu.edu> Date: 15 Dec 90 15:28:56 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: karron@cmcl2.nyu.edu Organization: The Internet Lines: 27 My understanding from TFM and sgi is that they don't want people using the feedback buffer. I had major problems migrating from 2400, 3000 class machines to the risc machine because I used the geometry pipeline to overcome cpu bottlenecks. I would now use another cpu thread before I would use the pipeline. Besides, you have to wait for the answer from the pipeline, and that ruins any parallelism you might get from the pipeline. If you are doing picking and pruning, what we need is a "parallel non screen" geometry pipeline. What I mean is a process running on another threaded cpu to do the same geometry operations on your data stream (matrix xformation and picking/pruning). The output would not go to the video processor, but would return values about visibility. This would be really nice for robotics app's where you need to know if there is a line of sight between two points on arbitrary shapes in arbitrary orientations. Eventually, we will need one cpu for each point to scan w/r/t the rest of the domain of points. Cheers! +-----------------------------------------------------------------------------+ | karron@nyu.edu (E-mail alias that will always find me) | | Fax: 212 340 7190 * Dan Karron, Research Associate | | . . . . . . . . . . . . . . * New York University Medical Center | | 560 First Avenue \*\ Pager <1> (212) 397 9330 | | New York, New York 10016 \**\ <2> 10896 <3> | | (212) 340 5210 \***\_________________________________________ | | Main machine: karron.med.nyu.edu (128.122.135.3) IRIS 85GT | +-----------------------------------------------------------------------------+