From: Dorosky, Christopher G (christopher.g.dorosky++at++lmco.com)
Date: 10/22/2003 09:48:22
Jurgen,
I don't have an answer for you, but I just had to say that this was one
of the most meticulously documented requests for information that I have
ever seen.
I hope that it is not ignored. CPU's will only get faster, and this
irratating problem needs explained.
Chris
-----Original Message-----
From: owner-info-performer++at++performer.engr.sgi.com
[mailto:owner-info-performer++at++performer.engr.sgi.com]On Behalf Of
jurgen.rusch++at++philips.com
Sent: Tuesday, October 21, 2003 11:05 AM
To: info-performer++at++sgi.com
Subject: [info-performer] Re: Re: no statistics (= the use of
PFCLOCKPERIOD)
Dear all,
those of us that have a fast CPU need to set PFCLOCKPERIOD,
at least on MS-Windows systems.
Searching for PFCLOCKPERIOD in the mailings (and from personal
e-mails) the advice was (and still is) to set that environment
variable to 2300000000000000.
Experiments with PFCLOCKPERIOD
------------------------------
Since we have to wait till Performer 3.1 (see e.g. Guillaume Millets
maling dated 10/09/2003, 01:18:46 titled "Re : Re: [info-performer]
No statistics") I thought it was a good idea to experiment with
the value of PFCLOCKPERIOD. For each value of PFCLOCKPERIOD I
ran RUN_TOWN.BAT (on Windows-XP on a dual Pentium 2.4 GHz Xeon
with 1GB RAM and an ATI FireGL X1 128 MB) and sent STDOUT (with
>) and STDERR (with 2>&1, yes, this also works on Windows-XP!)
to a different LOG file.
For each run of Performer Town I noted the APP/CULL/DRAW times
as observed in the timing statistics and noted whether I could
use the mouse for driving/flying or not.
The results are shown in the table below (the numbers in the first
two columns are represented using a , before each three zeroes for
legibility only):
PFCLOCKPERIOD picoseconds APP/CULL/DRAW in ms.
(set in RUN_TOWN.BAT) (reported in LOG) (from 'stats'-panel)
2,300,000,000,000,000 2,063,319,040 0.2/0.0/7.3
2,000,000,000,000,000 1,233,977,344 0.4/0.1/13.3
1,000,000,000,000,000 -1,530,494,976 0.0/0.0/0.0
100,000,000,000,000 276,447,232 1.7/0.3/60.0
10,000,000,000,000 1,316,134,912 0.3/0.1/13.0
1,000,000,000,000 -727,379,968 0.0/0.0/0.0
100,000,000,000 1,215,752,192 0.4/0.1/12.9
10,000,000,000 1,410,065,408 0.3/0.1/12.6
1,000,000,000 1,000,000,000 0.4/0.1/18.1
100,000,000 100,000,000 4.2/0.8/160
10,000,000 10,000,000 34/8.5/1800
1,000,000 1,000,000 1200/85 /16000
100,000 100,000 90000/750/230000
[column 3 was obtained by positioning the viewpoint just below the
clouds, south of the town, looking at the town (i.e., in northward
direction) and have the town and surrounding ranches in view. Thus
there were as much objects in the field-of-view as possible and
the DRAW time was as high as possible.]
In the cases that column 2 (picoseconds reported in LOG-file) was
negative the APP/CULL/DRAW times were all zero and the mouse could
NOT be used to fly or drive or whatever movement.
Please observe that the APP/CULL/DRAW timings are inversely
proportional to the number in column 2 (for positive values
in column 2).
A simple C-program
------------------
I was struck by the strange behaviour of column 2. How was it
derived from the value of PFCLOCKPERIOD? Well, quite easy:
I wrote a very short C program with this body:
int i;
int ret;
while (EOF!=(ret=scanf("%d",&i))) {
if (ret==1) { printf("%d\n",i); };
}
and fed this program with the values of column 1, i.e., with
the values that I had used for PFCLOCKPERIOD (without the ,).
And you know what? The output was EXACTLY column 2 !!
Conclusion
----------
+---------------------------------------------------+
| OpenGL Performer reads the value of PFCLOCKPERIOD |
| into a signed integer of length 4 bytes. |
+---------------------------------------------------+
A consequence of this is that setting PFCLOCKPERIOD to a value
N will result in the same behaviour of OpenGL Performer as
when setting PFCLOCKPERIOD to a value of mod(N,K) with K=2^32
(or N%K in C-language).
Final verification
------------------
As a final verification I ran Performer Town with PFCLOCKPERIOD
set to 2^31-1=2,147,483,647 (the highest positive integer that
can be represented by a signed 4 byte integer) and found that
very same number in the LOG-file (the value for column 2).
I then set PFCLOCKPERIOD to 2^31=2,147,483,648 (which maps to
the lowest negative integer that can be represented by a signed
4 byte integer, namely -2,147,483,648) and indeed found that
negative number in the LOG-file. Furthermore, the mouse could
NOT be used to control flying/driving.
My questions to SGI
-------------------
In older mailings I read that PFCLOCKPERIOD should be set to the
number of picoseconds per clock-cycle. Remembering that one
picosecond is 1E-12 seconds the number of picoseconds per
cycle for a 2.3 GHz system is (1/2.3E9)/(1E-12)= 1E12/2.3E9 =
1000/2.3 = (approx) 400.
What I found out was that for PFCLOCKPERIOD of 10,000,000 or
lower the timings were non-realistic and properly flying or
driving in Performer Town was impossible. So, to what value
should I set PFCLOCKPERIOD?
Hence:
QUESTION 1: What does PFCLOCKPERIOD exactly represent?
Furthermore:
QUESTION 2: Could SGI document the environment variable
PFCLOCKPERIOD?
As to the latter question: I looked in SGI document 007-1680-080,
the "OpenGL Performer Programmer's Guide" which documents release
3.0 and did not find PFCLOCKPERIOD as a string in it.
With kind regards, Jurgen Rusch
------------------------------------------------------
Drs. J.J. Rusch
member of cluster 'Support for Audio, Video & Graphics'
in the Computer Services department
Philips Research Laboratories
Prof. Holstlaan 4
5656 AA Eindhoven
The Netherlands
-----------------------------------------------------------------------
List Archives, Info, FAQ: 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
-----------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Wed Oct 22 2003 - 10:30:02 PDT