From: Yair Kurzion (yair++at++polygon.engr.sgi.com)
Date: 02/05/2001 12:09:24
Hello Paul !
> My data sets are all created using
> pfVec3 *coords = new(MAX_COORDS*sizeof(pfVec3)) pfMemory;
>
> I check to make sure I never make more than MAX_COORDS.
>
> I turned off the fluxed geoset altogether, and still got the same
> problem, but yes, I do make sure to update the vertices, and then the
> NumPrims.
>
>
> On a similar question. I create my fluxed geoset using
> pfFlux *line = pfFlux(pfFluxedGSetInit, PFFLUX_DEFAULT_NUM_BUFFERS);
Problem:
> line->setMode(PFFLUX_COPY_LAST_DATA, PF_ON);
This line defeats the purpose of the Fluxed geoset. It makes Performer
maintain a fluxed geoset body but makes the contents of the geoset (including
the geoset attributes) identical for all Flux copies.
The result of this is that all geosets in the flux have the same attribute
arrays -- You can not edit attributes in a MP-safe way.
You have two choices for doing this correctly:
1. Allocate attribute arrays and call pfGeoSet::setAttr in your pfFluxedGSetInit
function. This function is called for each copy of the fluxed geoset so
each copy will have independent attribute arrays.
2. Every time your application plans to write to a geoset, call
pfGeoSet::getAttr. If it is NULL, allocate memory for it and call
pfGeoSet::setAttr.
Another problem:
> pfGeoSet *gset=(pfGeoSet *)line->getCurData();
Whenever you plan to write on a Flux buffer (a fluxed geoset in your case),
you MUST call getWritableData on it. Calling getCurData when writing to a
Flux tricks Flux frame tags and can cause interesting/undefined errors.
> gset->setAttr(PFGS_COORD3, PFGS_PER_VERTEX,coords,NULL);
> ...
> gset->setNumPrims(num);
> gset->setPrimLengths(alen);
>
>
> Later on, when I modify coords:
>
> coords[i].set(blah blah blah);
>
> This change goes immediatly into the GeoSet right?
> It seems like I don't have to call:
>
> pfGeoSet *gset=(pfGeoSet *)line->getWritableData();
> gset->setAttr(PFGS_COORD3,PFGS_PER_VERTEX,coords,NULL);
> line->writeComplete();
>
> Is this the correct way to change geometry? It seems to work fine (other
> than this current bug) but I am wondering if I am missing something
> still...
>
> Paul Brewster
> NASA Langley Research Center
>
>
> "Dorosky, Christopher G" wrote:
> >
> > You aren't using non pfmalloced data for attributes of the geoset, are you?
> >
> > Make sure your fluxing is such that you don't increase the num prims before
> > you have valid vertex data for them.
> >
> > Christopher Dorosky
> > Lead Electronic Systems Engineer - Real Time Simulation
> > Lockheed Martin Missiles and Fire Control - Dallas
> > christopher.g.dorosky++at++lmco.com
> > 972-603-2349
> >
> > -----Original Message-----
> > From: Paul Brewster [mailto:p.f.brewster++at++larc.nasa.gov]
> > Sent: Monday, February 05, 2001 11:07 AM
> > To: Performer Mailing List
> > Subject: A problem using fluxed geosets
> >
> > My program has a bug in it that I was hoping someone could give me some
> > tips on tracking it down. I am using a fluxed geoset to dynamically
> > manipulate geometry while running. The program works fine for a while,
> > then crashes suddenly. On my Onyx2 it gives me the following message:
> >
> > WARNING: /hw/module/1/slot/n1/node/cpubus/0/a: UCE interrupt on PIO
> > access
> > NOTICE: /hw/module/1/slot/n1/node/cpubus/0/a: User Data Bus error in
> > IO space at physical address 0xec10004 (EPC 0xda5d790)
> > [ESP System Information Notification]:WARNING:
> > /hw/module/1/slot/n1/node/cpubus/0/a: UCE interrupt on PIO access
> > [ESP System Information Notification]:NOTICE:
> > /hw/module/1/slot/n1/node/cpubus/0/a: User Data Bus error in IO space
> > at physical address 0xec10004 (EPC 0xda5d790)
> >
> > On my Octane2, it just plain crashes the whole computer, requiring a
> > reset.
> >
> > I used cvd to check out the core file, and found this call stack:
> >
> > int pass_word_word_word(<stripped>) ["kon_vertarray.c":80,
> > 0x0da5d790]
> > int __glkonDrawArraysNCTV(<stripped>) ["kon_gvertarray.c":208,
> > 0x0db75058]
> > int __glkonim_DrawArraysEXT(<stripped>) ["kon_vertarray.c":513,
> > 0x0da5dc08]
> > int vertArrayGenDrawGSet(<stripped>) ["gsdraw.C":6332, 0x049a9b78]
> > int pfGeoSet::draw(<stripped>) ["pfGeoSet.h":613, 0x048d0188]
> > int _pfCuller::popQuick(<stripped>) ["pfCuller.C":860, 0x048229b4]
> > int _pfCuller::popSort(<stripped>) ["pfCuller.C":1063, 0x0481e1b4]
> > int _pfCuller::popXform(<stripped>) ["pfCuller.C":640, 0x0481db78]
> > int pfSCS::nb_cull(<stripped>) ["pfSCS.C":359, 0x047e86f4]
> > int pfScene::nb_cull(<stripped>) ["pfScene.C":293, 0x047eb3b0]
> > int _pfCuller::nb_cull(<stripped>) ["pfCuller.C":208, 0x0481d364]
> > int pfDraw() ["pfProcess.C":6460, 0x04845858]
> > int pfCAVEDrawCallback(<stripped>) ["pfcave.c":465, 0x1018ec60]
> > int pfChannel::pf_callDrawFunc() ["pfChannel.C":2326, 0x047fe930]
> > int pfFrame(<stripped>) ["pfProcess.C":6367, 0x04840084]
> > int main(int argc = 2, unsigned char ** argv = 0x7fff2f04)
> > ["tunnel.c":83, 0x100729a8]
> > int __start(<stripped>) ["crt1text.s":177, 0x100475f8]
> >
> > I suppose the bug is just a bad pointer, but I can't find it. I was
> > hoping someone could give me a hint on where to look.
> >
> > Thanks for the help.
> >
> > Paul Brewster
> > NASA Langley Research Center
> > -----------------------------------------------------------------------
> > List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> > Open Development Project: http://oss.sgi.com/projects/performer/
> > Submissions: info-performer++at++sgi.com
> > Admin. requests: info-performer-request++at++sgi.com
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Open Development Project: http://oss.sgi.com/projects/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
>
--
\_________ \_____ \__ \__ \_____ Yair Kurzion
\_________ \_____ \__ \__ \_____ yair++at++sgi.com
\__ \__ \____\__ \__ http://reality.sgi.com/yair
\__ \__ \__ Work: (650) 933-6502
\__ \__ \__ Home: (408) 226-9771
\__ \__ \__
This archive was generated by hypermail 2b29 : Mon Feb 05 2001 - 12:09:27 PST