Yair Kurzion (yair++at++polygon.engr.sgi.com)
Wed, 6 Oct 1999 19:19:49 -0700 (PDT)
> Can you clear things up between these RTMON events and what
> is returned in a pfFStatsValPFTimesApp structure? You show
> 5 RTMON events. The pfFStatsValPFTimesApp structure has 6
> time stamps.
First, my previous e-mail has an error. Sorry.
So, thank you for forcing me to dive a little deeper into pfFrame/pfSync :-)
As from my last e-mail, there are three places where DBase paging may cause a
hit in App/Cull:
1. Cleaning up the newly added scene graph geometry.
2. Registering the new geometry in the App table (aka pfBuffer).
3. Registering the new geometry in the Cull/Isect tables.
pfFrame and pfSync clean the scene graph three times (Ah, This is where I got
it wrong last time):
o pfFrame cleans once - very close to its beginning.
This call cleans all the scene graph changes made by the application
between the calls to pfSync and pfFrame. For example - changing a pfDCS
matrix.
o pfSync cleans twice in this order:
pfSync()
{
Process new nodes.
Merge ready buffers (from DBase) - register new geometry.
// This call cleans the newly added scene graph portions
// (from DBase). It also cleans all scene graph changes made by
// the application between pfFrame and pfSync.
clean#1
Do APP traversal (call App callbacks where requested).
// This call cleans the nodes that App callbacks modified.
clean#2
...
}
The relevant clean for DBase process paging is the first one in pfSync
(clean#1). In my previous e-mail I talked about RTMON events
_PFRTMON_APP_PFFRAME_START and _PFRTMON_APP_SYNC_AFT_CLEAN. They bound the
clean operation in pfFrame so they don't measure the clean-up of new DBase
geometry.
The correct RTMON events are in pfSync. they happen in this order:
{
_PFRTMON_APP_SYNC_START (1270)
Process new nodes.
Merge ready buffers (from DBase)
clean#1
_PFRTMON_APP_SYNC_BEF_CLEAN (1271)
clean#2
_PFRTMON_APP_SYNC_AFT_CLEAN (1272)
...
}
Per your question, in the pfFStatsValPFTimesApp structure:
- enterSync records the time at the start of pfSync. Should be identical to
the RTMON event _PFRTMON_APP_SYNC_START.
- afterClean records the time after clean#2. Should be identical to
_PFRTMON_APP_SYNC_AFT_CLEAN.
- afterSync records the time at the end of pfSync.
- pfFrameStart records the start of pfFrame, slightly after the RTMON
event _PFRTMON_APP_PFFRAME_START.
- pfFrameEnd records the time where pfFrame send off all the downstream
processes to grab their scene graph updates. This is identical to
_PFRTMON_APP_PFFRAME_UPDATE.
So, you can query pfFStatsValPFTimesApp stats every frame and look for frames
where (afterClean - enterSync) is large. These will probably be frames
right after a DBase frame finished, and so the extra time is used to clean the
newly paged nodes. Note that pfFStatsValPFTimesApp does not count clean#1
alone. It includes the App traversal and clean#2. However, in most cases,
these should be constant every frame so you can probably ignore them.
Or, if you have access to irixview, you can view the RTMON generated events
on a time line (just like a logic analyzer). In irixview you can also see
the RTMON event _PFRTMON_DBASE_END_PFDBASE (2060) generated by the DBase
process at the end of the call to pfDBase. The App pfSync following this event
should show the exact paging hit.
As for the hit that Cull takes for registering the new geometry in its tables,
my previous e-mail was correct. The difference between RTMON events
_PFRTMON_APP_PFFRAME_UPDATE (1231) and _PFRTMON_APP_PFFRAME_START_FRAME (1210)
is where App waits for Cull and Isect to finish grabbing their scene graph
updates. The more updates, the bigger the hit.
Or, you can use the pfFStatsValPFTimesCull structure to gather stats information
on the Cull process. In this structure, the fields beginUpdate and endUpdate
record the time that Cull grabs its scene graph updates (including new nodes
that DBase paged in).
I hope this makes more sense,
-yair
--
\_________ \_____ \__ \__ \_____ 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 2.0b2 on Wed Oct 06 1999 - 19:19:57 PDT