Prev |
Next
Interpreting Frame Statistics
March 2006
|
![](images/prman_logo_small.gif)
|
Introduction
It has been possible to gather statistics about the renderer
since PRMan 3.8, and with the 13.0 release this output has been
greatly expanded and improved. This Application Note describes
how to interpret these statistics.
Users should also consult the
Extensible Stats Diagnostics
application note for additional information.
Enabling Statistics Output
Control over the printing of statistics is described elsewhere
(see Using XML Frame Statistics). In
brief, the printing of statistics at the end of the frame is
controlled by the "statistics" Option:
Option "statistics" "endofframe" [1] "filename" ["stats.txt"] "xmlfilename" ["stats.xml"]
Plain-Text Statistics Summary
The plain-text output of Option "statistics" "filename"
summarizes renderer version information, image format
information, and overall resource usage (time and memory).
Pixar PhotoRealistic RenderMan 13.0b3 (Win32.iP4)
Copyright (c) 1988-2006 Pixar.
linked Thu Mar 23 15:19:35 PST 2006
Rendered on Fri Mar 24 14:29:08 PST 2006
Rendering at 640x480 pixels, 3x3 samples
"dragons.tif" (mode = rgba, type = tiff)
Memory: 48.87 MB
Real time: 06:16
User time: 05:04
Sys time: 00:06
Max resident mem: 52.40 MB
Page faults: 0, Page reclaims: 63
- Memory:
-
The maximum amount of memory allocated on the heap over the
lifetime of the render. On some platforms, this number may not
include stack memory or the code and data segments, so the
renderer may need more memory than this to operate
effectively.
- Real time:
-
The amount of "wall clock" time elapsed since the beginning of
the frame render.
- User time:
-
The amount of time spent executing user instructions on behalf
of the renderer. Note that in multithreaded renders, the
amount of user time is summed over all CPUs, so this number may be
more than the real time.
- Sys time:
-
The total amount of time spent in the operating system kernel
executing instructions on behalf of the renderer. The sum of
this time and the user time is a good indication of the total
CPU time (summed over all CPUs).
- Max resident mem:
-
The maximum resident set size used by the renderer, measured
in megabytes. Basically, this is the maximum amount of
physical memory which the operating system sets aside for the
renderer.
- Page faults:
-
The number of "hard" page faults - the number of times that a
page of virtual memory in use by the renderer had to be
swapped out to disk.
- Page reclaims (platform dependent):
-
The number of page faults serviced without any I/O activity
(i.e. having to swap to disk); here I/O activity is avoided by
"reclaiming" a page frame from the list of pages awaiting
reallocation.
- Peak pagefile usage (platform dependent):
-
The maximum amount of space of page-file storage used by the
rendering process.
- Peak paged pool usage (platform dependent):
-
The maximum amount of paged pool used by the rendering
process.
This resource usage summary is useful for timing renders as well
as monitoring memory usage. For example, when the system memory
is low the operating system may undergo excessive virtual memory
paging ("thrashing"). This is something that should generally be
avoided, as shown by the wall clock time in the summary below
generated for the same scene above, rendered in a low memory
situation. Note the number of page faults, and compare the
maximum resident memory with the memory allocated by the
renderer.
Memory: 50.41 MB
Real time: 40:04
User time: 13:45
Sys time: 00:29
Max resident mem: 35.94 MB
Page faults: 24609, Page reclaims: 47207
Timing Summary
The timing summary portion of the XML statistics displays
information about where the time went in the major subsystems of
the renderer. It summarizes on a single page all the timing
information collected, and will typically look like the
following:
|
Elapsed |
|
User |
|
System |
|
|
Total time |
16:06.2 |
|
27:14.6 |
|
0:34.0 |
|
|
All procedurals |
0:06.1 |
|
0:05.3 |
|
0:00.2 |
|
|
./menger.so |
0:06.1 |
|
0:05.3 |
|
0:00.2 |
|
|
All shading |
52:00.7 |
|
|
Displacement shading time |
1:06.9 |
|
|
Surface shading time |
48:23.9 |
|
|
Atmosphere shading time |
0:00.0 |
|
|
Light shading time |
5:18.7 |
|
|
Reyes shading |
28:35.9 |
|
|
Displacement shading time |
0:26.9 |
|
|
Surface shading time |
27:11.9 |
|
|
Atmosphere shading time |
0:00.0 |
|
|
Light shading time |
1:20.6 |
|
|
Ray hit shading |
23:24.8 |
|
|
Displacement shading time |
0:40.0 |
|
|
Surface shading time |
21:12.0 |
|
|
Atmosphere shading time |
0:00.0 |
|
|
Light shading time |
3:58.0 |
|
|
Total texture3d() time |
0:00.0 |
|
|
Brick read time |
0:00.0 |
|
|
Texture |
0:37.2 |
|
|
- All procedurals:
-
Total time spent executing user procedurals (RiProcedural). This
category is followed by time reported on a per-procedural
basis.
Memory Summary
The memory summary gives detailed information on the current and
peak amount of memory allocated on the heap by different aspects
of the renderer.
- Ray accelerator, Traceable prim:
-
Memory needed to maintain acceleration data structures for ray
tracing. This memory is generally proportional to the amount
of geometry visible to ray tracing.
- GUT caches:
-
Memory devoted to tessellation caches for ray tracing. This
memory is a fixed cost per thread, and the amount dedicated to
the cache can be controlled with Option
"limits" "int geocachememory".
- GPrim:
-
Memory allocated to store geometric primitive information,
exclusive of vertex variable information and extra subdivision
overhead.
- GSM and GOP:
-
Memory allocated to store graphics state
information.
- Trim curve and data:
-
Trim curves store the trim definition as defined with
RiTrimCurve at parsing time. Trim data is generated
at render time to determine which micropolygons are will be
affected by trim curves.
- Vertex vectors:
-
Memory for vertex vectors, which store vertex variables
(including P and user-defined variables) associated with
primitives.
- Grids:
-
Memory allocated for grids (two-dimensional arrays of
micropolygons which are shaded in parallel).
- Crack reduction memory:
-
Memory allocated for stitching (used for crack elimination in
single primitives).
- Catmull-Clark, Loop subdivision memory:
-
Due to the nature of subdivision, the memory requirements of
subdivision surfaces are generally higher than that of other
primitive types. This category tracks the memory usage over
and above that which is normally tracked in the GPrim memory
category.
- Texture cache:
-
Memory associated with the texture system. Most of this is
reserved for caching textures read from disk. The maximum
amount of memory in the cache can be controlled by setting the
"texturememory" limit; for example, in this
particular scene, it was set with the following RIB statement:
Option "limits" "texturememory" [20480]
See the PRMan Options
section of the User Manual for more details.
- Deep shadow cache:
-
Memory associated with the deep shadow system. Most of this is
reserved for caching deep shadows read from disk. The maximum
amount of memory in the cache can be controlled by setting the
"deepshadowtiles" limit;
See the PRMan Options
section of the User Manual for more details.
- Visible points:
-
Memory associated with each subpixel z-buffer sample. This
includes color, opacity, and depth information about the
micropolygons overlapping the sample, sorted by depth; these
are composited together to compute the final color of the
pixel. The amount of memory devoted to visible point memory
is directly related to the pixel
samples setting, the size of
the bucket, and the amount of transparent geometry in the
scene. The effect of the latter may be mitigated through usage
of the opacity
culling option.
- Micropolygons:
-
Memory needed for allocating micropolygons. This category is
especially important to monitor when dealing with issues such
as displacement bounds that are too loose. If memory in
micropolygons becomes an issue, it may be mitigated through
the use of the micropolygon
caching option.
The memory breakdown is useful when tweaking the various knobs
in the renderer in order to trade off memory against speed
against quality. Lowering the shading rate will improve quality
at the expense of more micropolygons (and more memory needed to
store them). Raising the bucket and grid sizes directly
increases memory usage, but increases the renderer's efficiency,
up to a point.
Appnote #3 provides more information
on these tradeoffs.
Geometry Statistics
The geometry statistics present detailed information about some
of the geometry types handled by PRMan, as well as some
information about diced grid sizes and vertex vectors (data
structures which store vertex variables associated with
primitives).
- Grid size, Grids allocated:
-
Statistics about the number and sizes of the diced grids in
PRMan. The maximum size of diced grids is controlled by Option
"limits" "gridsize".
- Procedurals created, Procedurals expanded:
-
The number of RiProcedurals
that are created, and the number of those that are expanded
due to bounding box intersection or visibility.
Reyes Rendering Statistics
The Reyes rendering statistics shows general information about
the Reyes algorithm used by PRMan.
- Gprims extracted:
-
In PRMan, geometric primitives are placed in a list attached
to the first bucket where it will matter, based on which
buckets its bounding box overlaps. The "Gprims extracted"
number indicates the number of times a geometric primitive is
taken out of a bucket list.
- Grids pushed:
-
If the primitive which is taken out of the list for a bucket
can be determined to be invisible in that bucket, it is
"pushed" forward to a future bucket for future
processing. These may be pushed right or pushed down,
depending on factors such as displacement bounds or motion blur.
- Grids backface culled, Points in backface culled grids:
-
The number of grids that can be backface culled (have Sides 1
and face away from the camera). This only counts the geometry
that have to be diced before backface culling can take place;
most geometry types can do the determination before dicing.
- Frustum box, Arbitrary clip planes culled:
-
Geometric primitives undergo checks against the viewing
frustum and arbitrary clip planes. Ones that lie completely
outside the frustum or outside the arbitrary clipping planes
are culled, while ones that are completely inside the regions
of interest can be optimized against further checks. The
categories listed here describe the "source" of the geometry
(high level geometry, geometry that was created from splits,
geometry created by procedurals, intermediate grid
representations).
- Occlusion culled:
-
Geometric primitives which are entirely behind opaque geometry
can undergo occlusion culling, and be removed early on. Scenes
with highly transparent geometry do not lend themselves to
much occlusion culling, and consequently can take much longer
to render. The categories listed here describe the "source" of
the geometry (high level geometry, geometry that was created
from splits, geometry created by procedurals, intermediate
grid representations).
- Normal split:
-
In the REYES algorithm, geometry which is not "flat" and can't
be diced directly will undergo splitting. This statistic
measures the amount of splitting that occurs. The categories
listed here describe the "source" of the geometry undergoing
splitting (high level geometry, geometry that was itself
created from splits, geometry created by procedurals,
intermediate grid representations).
- Diced into a grid:
-
In the REYES algorithm, geometry which is "flat" will be diced
into a "grid" (an aggregate of micropolygons). This statistic
measures the amount of dicing that occurs. The categories
listed here describe the "source" of the geometry undergoing
splitting (high level geometry, geometry that was created from
splits, geometry created by procedurals, intermediate grid
representations that will be "rediced").
- Histogram of the size of diced grids:
-
This histogram displays the number of points in all diced
grids, where each grid corresponds to one piece of flat
geometry. This should not be confused with the number of
points in shaded grids.
- Histogram of the size of shaded grids:
-
This histogram displays the number of points in all shaded
aggregate grids. Due to combined shading, each shaded grid may
actually correspond to multiple pieces of geometry; hence,
this number should not be confused with the number of points
in diced grids (above).
Hider Statistics
Visible points contributing to image
|
0
|
|
1.10723e+007
|
|
6.66829e+006
|
|
1.00
|
|
1.10723e+007
|
|
|
Gprims occlusion culled
|
48359
|
|
|
Micro-polygons occlusion
culled
|
2806901
|
|
|
Micro-polygons created
|
7107490
|
|
|
Micro-polygons needing to be
split
|
0
|
|
|
Micro-polygons frustum culled
|
96194
|
|
|
Micro-polygons back faced
culled
|
0
|
|
|
Micro-polygons trim culled
|
0
|
|
|
Visible points occlusion
culled
|
2.17364e+007
|
|
|
Visible points opacity culled
|
1.00724e+006
|
|
|
Visible points with wrong LOD
|
0
|
|
|
Samples that hit a micro-polygon
|
1.10723e+007
|
|
|
Samples that missed a micro-polygon
|
3.05916e+007
|
|
|
- Visible points contributing to image:
-
A visible point contains information associated with each
subpixel z-buffer sample. This includes color, opacity, and
depth information about the micropolygons overlapping the
sample, sorted by depth; these are composited together to
compute the final color of the pixel. The number of visible
points is directly related to the pixel
samples setting, the size of
the bucket, and the amount of transparent geometry in the
scene. The effect of the latter may be mitigated through usage
of the opacity
culling option.
- Histogram of the depth of visible points:
-
Each subpixel sample in the render keeps track of a list of
visible points, since a subpixel sample can overlap multiple
micropolygons. This histogram displays the length of all of
these lists. Usually these lists are small (1 or so) after
backface culling, although if there is transparency in the
scene, the lists can be larger - these visible points will
need to be composited together for the final subpixel
value. The length of the lists may be shortened through usage
of the opacity
culling option.
- Samples that hit/missed a micro-polygon:
-
After micropolygons are shaded, they are tested against pixel
subsamples to determine visible point information. These two
statistics measure the hit and miss rate of sampling.
Shading Statistics
All shading
|
52:00.7
|
|
|
Surface shading time
|
48:23.9
|
|
|
Light shading time
|
5:18.7
|
|
|
Displacement shading time
|
1:06.9
|
|
|
Atmosphere shading time
|
0:00.0
|
|
|
Atmosphere shading time
|
0:00.0
|
|
|
Executable storage
|
0.38
|
|
0.38
|
|
|
Local storage
|
4.11
|
|
4.05
|
|
|
Points shaded
|
1214
|
|
52706790
|
|
2025
|
|
4.22
|
|
12498766
|
|
|
Points trimmed
|
0
|
|
|
displacement shaders
Lunar_Bump_0
|
Full shader name
|
rmanshader/Lunar_Bump_0
|
|
|
Lunar_Bump_0
|
0:50.1
|
|
|
Points shaded
|
862566
|
|
|
|
surface shaders
visindirectsurf
|
Full shader name
|
visindirectsurf
|
|
|
visindirectsurf
|
24:45.6
|
|
|
Points shaded
|
8981066
|
|
|
|
Chromium_FX
|
Full shader name
|
rmanshader/Chromium_FX
|
|
|
Chromium_FX
|
5:46.0
|
|
|
Points shaded
|
14396203
|
|
|
|
atmosphere shaders
light shaders
skylight
|
Full shader name
|
rmanshader/skylight
|
|
|
skylight
|
5:16.2
|
|
|
Points shaded
|
27602960
|
|
|
|
Ray Accelerator Statistics
This section of the XML statistics displays information about
the ray acceleration data structures used by the renderer.
Primitive tests by type
|
sphere
|
14329248
|
|
|
nurb
|
30538890
|
|
|
curve
|
2985979
|
|
|
points
|
3000209
|
|
|
implicit
|
891635
|
|
|
catmarkface
|
25111095
|
|
|
bsplinepatch
|
28975142
|
|
|
|
Primitive hits by type
|
sphere
|
14329248
|
|
|
nurb
|
4844432
|
|
|
curve
|
167339
|
|
|
points
|
77806
|
|
|
implicit
|
197243
|
|
|
catmarkface
|
3246764
|
|
|
bsplinepatch
|
4488030
|
|
|
|
Rays by type
|
specular
|
1.81523e+006
|
|
|
diffuse
|
1.23656e+007
|
|
|
transmission
|
1.42323e+007
|
|
|
|
Ray depth histogram
|
27386632
|
1026480
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
|
- Traceable prims:
-
The count of high level primitives in the scene that are visible to ray tracing.
- Prims after splits:
-
The count of primitives (after all splits) in the scene that are visible to ray tracing.
- Total rays:
-
The total number of rays fired during ray tracing.
- BBox tests:
-
The total number of bounding boxes tested during ray tracing.
Generally, this is the dominating cost in ray tracing.
- Primitive tests and hits:
-
The total number of tests and successful hits of geometric
primitives during ray tracing. Generally, this number should
be much lower than the number of bounding box tests.
- Useful hits:
-
The number of primitive hits that are "useful", in the sense
that the hit object was opaque enough to be counted as an
actual hit. The hit object's opacity and the shading
hit-mode attributes have a direct control over this
statistic.
- Ray continuations:
-
The number of trace or gather rays that are fired due to
continuation through partially transparent surfaces. Directly
controlled by Option
"trace" "int continuationbydefault".
- Total ray length:
-
The sum length of all rays fired in the system.
- Primitive tests, hits by type:
-
The total number of tests and successful hits of geometric
primitives during ray tracing, broken down by the type of primitive.
- Rays by type:
-
The total number of rays fired during ray tracing, broken down
by ray type. The ray types are determined by the shadeop being
used (occlusion, gather, trace, etc) and the width of the cone
used in the shadeop.
- Rays depth histogram:
-
This histogram breaks down the depths of all rays in the
system. A scene with very many shiny objects may exhibit a
histogram with many deep rays, whereas a scene with only a
single level of occlusion may exhibit a histogram with rays
only at depth one. The histogram may be directly tweaked via
the use of Attribute
"trace" "maxdiffusedepth" and "maxspeculardepth" as well as
Option
"trace" "maxdepth".
Ray Geometry Statistics
This section of the XML statistics displays information about
ray tracing, specifically in its handling of the geometry in the
scenes rendered.
- Hemisphere samplings:
-
The number of points where a hemisphere sampling is done for
computation of ambient occlusion and/or indirect diffuse illumination.
- Stored HSRs:
-
The number of points where hemisphere sampling results are stored
(and possibly shared).
- Triangle hit tests and hits:
-
The number of triangle tests and successful intersections that
occur during ray tracing. Most curved geometry is ultimately
hit tested as triangles.
- Flat and Curved BLP hit tests and hits:
-
The number of bilinear patch tests and successful
intersections that occur during ray tracing. Patch "bilinear"
and Polygons are hit tested as either flat or curved bilinear
patches.
- Rejected hits due to Sides 1:
-
The number of successful intersections that are rejected due
to intersection on the wrong side of objects marked with Sides
1.
- GUT cache cold tessellations:
-
The number of compulsory tessellations that occur when
accessing the tessellation cache used for ray tracing of
curved surfaces. A compulsory tessellation can not be avoided
by resizing of the GUT cache. This statistic is collected for
each of the three levels of the tessellation cache.
- GUT cache lookups, hits, misses:
-
The GUT cache refers to the cache used to store tessellations
of curved geometry. Since these are generally impossible to
store for all geometry entirely in memory, PRMan uses a
multi-level caching scheme. The statistics gathered here
relate to the efficacy of the tessellation cache. If the cache
misses begin to dominate the number of lookups, it indicates
that the amount of geometry in the scene or the incoherency of
the rays are too much for the GUT cache size. This will lead
to slowdowns in ray tracing performance. The size of the GUT
cache can be adjusted by changing Option
"limits" "int geocachememory".
Unusual Displacements
This section of the XML statistics displays information about
unusual displacements encountered during the render.
2.107
|
1.347
|
1.564
|
|group80|nurbsSphere1|nurbsSphereShape1
displacement: rmanshader/Lunar_Bump_0
|
4.626
|
3.596
|
1.286
|
|group80|nurbsSphere4|nurbsSphereShape4
displacement: rmanshader/Combine_2_0
|
15.640
|
13.400
|
1.167
|
|group81|nurbsSphere4|nurbsSphereShape4
displacement: rmanshader/Combine_2_0
|
Geometry which undergoes displacement typically requires a displacement
bound to be set. If the magnitude of this displacement falls
far below the displacement bound, it is generally being
inefficiently rendered both in speed and in memory. On the other
hand, if the magnitude of displacement is above the displacement
bound, this may lead to tearing artifacts. Geometry whose
displacement is in one of these two categories is reported in
these statistics. The table consists of the amount of
displacement, the displacement bound, and the ratio of
displacement to bound, as well as the name
identifier and the shaders bound to the geometry. The
verbosity of this table is controlled by Options "stats"
"displace_ratios".
Texture Statistics
PRMan uses a very efficient texturing system which brings in
texture data from disk only when necessary. Texture data is
brought in as tiles which are stored in a cache, and organized
to optimize cache hit rates. Detailed information about the
operation of the cache is printed in a table similar to the
following.
Texture cache
Read
|
0:20.1
|
|
|
Decompress
|
0:03.0
|
|
|
Cache size
|
10.01
|
|
10.01
|
|
|
Max tiles
|
2560
|
|
|
Num tiles used
|
2560
|
|
|
Lookups
|
116461473
|
|
|
Hits
|
116413284
|
|
|
Misses
|
48189
|
|
|
Bytes read
|
80591653
|
|
|
- Read:
-
The time taken to read tiles from disk that are not found in the cache.
- Decompress:
-
The time taken to decompress tiles read from disk.
- Cache size:
-
The size, in bytes, of the cache.
- Max tiles:
-
The maximum number of tiles allowed.
- Num tiles:
-
The number of tiles actually used.
- Lookups:
-
The number times a tile is requested from the cache.
- Hits:
-
The number times a requested tile is found.
- Misses:
-
The number times a requested tile is not found.
- Bytes read:
-
The number of bytes read from disk. Because of compression,
this is typically smaller than the number of misses times the
size of a tile.
Texture filtering
Filtering time
|
0:00.5
|
|
|
Requests
|
74959
|
|
|
Samples
|
1075543
|
|
|
# samples per request
|
0
|
5525
|
20587
|
43167
|
4189
|
992
|
268
|
80
|
26
|
86
|
31
|
8
|
0
|
|
Max filter width
|
0
|
5525
|
12035
|
44018
|
2676
|
4547
|
939
|
1440
|
657
|
975
|
244
|
328
|
1575
|
|
- Filtering time:
-
Time spent in texture filtering. This includes the time spent reading data from disk.
- Requests:
-
The number of points textured.
- Samples:
-
The number of texels used to create filtered values.
- # samples per request:
-
A histogram of the number of texels used to create each filtered value. This gives
an idea of the average area of filter footprints.
- max filter width:
-
The largest dimension, in texels, of a filter footprint.
Environment filtering
Environment filtering stats follow the same format as texture filtering.
Shadow filtering
Shadow filtering stats follow the same format as texture filtering.
Soft shadow filtering
filtering time
|
0:00.0
|
|
|
Line walks
|
0
|
|
|
Surf Samps
|
0
|
|
|
Hi Res Hits
|
0
|
|
|
Num Same Hits Blck
|
0
|
|
|
Num Same Hits Clr
|
0
|
|
|
Max Hit Pt List Size
|
0
|
|
|
Total Hit Pt List Size
|
0
|
|
|
Num Warp Iterations
|
0
|
|
|
depth of minmax
accesses
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
|
# minmax drawn
|
|
- Filtering time:
-
Time spent in doft shadow filtering. This includes the time spent reading data from disk.
- Line walks:
-
- Surf sampls:
-
- Hi res hits:
-
- Num Same Hits Blk:
-
- Num Same Hits Clr:
-
- Max hit pt list size:
-
- Total hit pt list size:
-
- Num warp iterations:
-
- depth of minmax accesses:
-
A histogram of how far back the minmax accesses were.
- # minmax drawn:
-
Histogram of how many minmax drawn.
Deep shadow cache
Read
|
0:02.1
|
|
|
Decompress
|
0:20.3
|
|
|
Cache size
|
21.01
|
|
21.01
|
|
|
Max tiles
|
66
|
|
|
Num tiles used
|
66
|
|
|
Lookups
|
9812609
|
|
|
Hits
|
9782910
|
|
|
Misses
|
29699
|
|
|
Bytes read
|
1652795551
|
|
|
- Read:
-
The time taken to read tiles from disk that are not found in the cache.
- Decompress:
-
The time taken to decompress tiles read from disk.
- Cache size:
-
The size, in bytes, of the cache.
- Max tiles:
-
The maximum number of tiles allowed.
- Num tiles:
-
The number of tiles actually used.
- Lookups:
-
The number times a tile is requested from the cache.
- Hits:
-
The number times a requested tile is found.
- Misses:
-
The number times a requested tile is not found.
- Bytes read:
-
The number of bytes read from disk. Because of compression,
this is typically smaller than the number of misses times the
size of a tile.
Deep shadow filtering
Filtering time
|
0:26.6
|
|
|
Requests
|
91026
|
|
|
Analytic filters
|
52225
|
|
|
Sampled filters
|
38801
|
|
|
# samples per request
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
91206
|
0
|
0
|
0
|
|
Max filter width
|
12103
|
46
|
251
|
783
|
1893
|
4682
|
9605
|
11261
|
8327
|
6161
|
5045
|
4238
|
26631
|
|
walk histogram
|
10212024
|
36641
|
54962
|
78956
|
121239
|
161539
|
38008
|
112297
|
0
|
0
|
|
- Filtering time:
-
Time spent in deep shadow filtering. This includes the time spent reading data from disk.
- Requests:
-
The number of points textured.
- Analytic filters:
-
The number of filter requests computed using an optimized analytic filter.
- Sampled filters:
-
The number of filter requests computed using the standard deep shadow filter.
- # samples per request:
-
A histogram of the number of texels used to create each filtered value. This gives
an idea of the average area of filter footprints.
- max filter width:
-
The largest dimension, in texels, of a filter footprint.
- walk histogram:
-
A histogram of how long the deep-pixel walks were.
Brickmap Statistics
Total texture3d() time
|
0:00.0
|
|
|
Brick read time
|
0:00.0
|
|
|
Brick map lookups (texture3d() calls)
|
0
|
|
|
Brick maps accessed
|
0
|
|
|
Brick map header bytes read
|
0
|
|
|
Bricks read
|
0
|
|
|
Brick bytes read
|
0
|
|
|
Brick cache lookups
|
0
|
|
|
Brick cache hits
|
0
|
|
|
Brick cache misses
(compulsory and capacity)
|
0
|
|
|
Compulsory cache misses
|
0
|
|
|
Capacity cache misses
|
0
|
|
|
Size of each brick cache
|
10485760
|
|
|
Total size of the brick caches
|
41943040
|
|
|
Brick slots in brick caches
|
3032
|
|
|
Actual memory used by brick caches
|
0
|
|
|
- Brick map lookups:
-
The number of texture3d() calls looking up in a brick map file.
Each brick map lookup (texture3d() call) will typically result
in more than one brick cache lookup.
- Brick maps accessed:
-
The number of brick map files that have been opened for reading.
- Brick map header bytes read:
-
The size of brick map header information that was read from
file (in bytes). This includes a table of brick locations for
each brick map file.
- Bricks read:
-
The number of bricks read from file.
- Brick bytes read:
-
The total size (on disk) of all bricks read from file (in bytes).
- Brick cache lookups:
-
The number of lookups in the brick cache. Each cache lookup will
result in either a hit or a miss.
- Brick cache hits:
-
The number of brick cache hits.
- Brick cache misses:
-
The number of brick cache misses. Cache misses are either compulsory
or due to limited cache capacity.
- Compulsory cache misses:
-
The number of compulsory cache misses (a.k.a. "cold misses").
These cache misses happen the first time a given brick is accessed,
and cannot be avoided no matter how large the cache size is.
- Capacity cache misses:
-
The number of capacity cache misses, i.e. bricks that are read in
that had also previously been read in (but had been since been
replaced in the cache). Capacity cache misses can be reduced by
increasing the cache size.
- Size of each brick cache:
-
The maximum size of each brick cache (in bytes).
- Total size of the brick caches:
-
The maximum size of the brick caches (in bytes). In multithreaded
execution, there will be one cache pr. thread plus one shared
second-level cache.
- Brick slots in brick caches:
-
The number of slots in the brick caches. This number depends on the
brick cache size and the size of the bricks (i.e. how much data
each brick voxel can contain).
- Actual memory used by brick caches:
-
The actual size of the brick caches (in bytes). This size can
be smaller than the maximum brick caches size if few (or no) bricks
have been read in. The size can be larger than the maximum brick
caches size if the brick map data consist of more than 6 floats per
voxel.
System Statistics
The system statistics presents mostly the same information as
the plain-text statistics summary in
XML form. In addition, a list of all files accessed during the
render is provided.
Total time
|
16:06.2
|
|
27:14.6
|
|
0:34.0
|
|
|
Total heap memory
|
61.60
|
|
61.60
|
|
|
Peak process size
|
845.35
|
|
845.35
|
|
|
pageFaults
|
673540
|
|
|
peakPageUsage
|
8.95918e+008
|
|
|
peakPagePoolUsage
|
42708
|
|
|
Files accessed
|
./rmanshader/AdditiveFX_4_0.slo
./rmanshader/BrushedMetal_0.slo
./rmanshader/Chromium_FX.slo
./rmanshader/Combine_2_0.slo
./rmanshader/EnvSphere.slo
./rmanshader/Layer_8_0.slo
./rmanshader/Lunar_Bump_0.slo
./rmanshader/Lunar_Surface_0.slo
./rmanshader/Plastic_0.slo
./rmanshader/Plastic_grass.slo
./rmanshader/imagemap.slo
./rmanshader/magicSurf.slo
./rmanshader/matte.slo
./rmanshader/mirror.slo
./rmanshader/mtorLambert.slo
./rmanshader/points_blinn.slo
./rmanshader/skylight.slo
./rmanshader/visindirectsurf.slo
//c|//home/jfong/projects/rmanext/built/windows.icc81.x86.external/etc//d_tiff.so
//c|//home/jfong/projects/rmanext/built/windows.icc81.x86.external/lib/shaders/defaultsurface.slo
dragons_large.rib
|
General Information
This section summarizes some general information about the
renderer and the scene being rendered.
- version, linkTime
-
The version of the renderer used. This should be the same
string reported by prman -version.
- timestamp
-
The time at which the rendering took place.
- xRes, yRes
-
The dimensions of the image rendered. Corresponds to the
xresolution and yresolution passed to RiFormat.
- xSamples, ySamples
-
The pixel
samples setting used when rendering the image.
- cropLeft, cropRight, cropTop, cropBottom
-
The crop window
setting used when rendering the image.
- bucketXres, bucketYres
-
The size of
the bucket used when rendering the image.
- gridSize
-
The maximum
size of grids set when rendering the image.
- zThreshR, zThreshG, zThreshB
-
The RGB settings of the opacity
threshold option.
- oThreshR, oThreshG, oThreshB
-
The RGB settings of the opacity
culling option.
Prev |
Next
Pixar Animation Studios
Copyright©
Pixar. All rights reserved.
Pixar® and RenderMan® are registered trademarks of Pixar.
All other trademarks are the properties of their respective holders. |