Prev | Next



Interpreting Frame Statistics

March 2006

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.


Peak MB
Current MB

Ray accelerator memory 55.31
0.00

Traceable prim memory 41.23
0.00

GUT caches 119.98
0.00

Shaded curve memory 0.00
0.00

GSM memory 0.01
0.00

Grid memory 37.65
3.22

GPrim memory 52.81
-0.01

Static GOP memory 0.96
0.01

Dynamic GOP memory 20.57
0.02

Crack reduction memory 2.08
2.08

Vertex vector memory 24.38
0.00

Vertex vector overhead memory 0.72
0.00

Catmull-Clark subdivision memory 330.23
0.00

Loop subdivision memory 0.00
0.00

Trim curve memory 0.00
0.00

Trim data memory 0.00
0.00

Total shading storage 6.82
6.63

Shader definition storage 0.99
0.99

Shader tag storage 0.24
0.12

Shader argument storage 0.59
0.59

Shader instance storage 0.50
0.50

Vertex instance storage 0.00
0.00

Executable storage 0.38
0.38

Local storage 4.11
4.05

Visible points storage 0.71
0.00

VP shading memory 11.33
0.00

Brick location table memory 0.00
0.00

Brick map octree memory 0.00
0.00

Texture cache 10.01
10.01

Deep shadow cache 21.01
21.01

Arbitrary output variable (AOV) storage 0.00
0.00

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).

Range
Current

Total

Peak

Average

Number


Grid size
430

82933723

867

5.45

15222285


Vertex vector count
0

10212

9406

1.00

10212



Grids allocated
15222285


Procedurals created
0


Procedurals expanded
0


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 from buckets
552187


Gprims found not to be visible
205131


Grids backfaced culled
0


Grids diced
249128


Grids shaded
109952


Grids pushed at least once
18548


Grids pushed more than once
30367


Grids culled during VP shade loop
0


Points in backface culled grids
0


Points in diced grids
12975494


Grids disp shaded before pre-hide
1651039


Points in shaded grids
8513282


Number of grid pushes
54438


Diced grids pushed right
29690


Diced grids pushed down
22014


Diced grids pushed far down
2734


Number of extreme displacements
0


Number of 'second sides' rejected
0


Backface culled

Frustum culled
original
3


split
6180



Placed in a bucket
original
4812


split
392070


grid
54438



Arbitrary clip planes culled

Occlusion culled
original
218


split
44136


grid
5472



Normal split
original
4351


split
94923



Diced into a grid
original
243


split
253011


grid
49563



Histogram of the size of diced grids
2
4
8
16
32
64
128
256
more
3
60573
37538
46598
18798
21133
21353
37082
6050

Histogram of the size of shaded grids
2
4
8
16
32
64
128
256
more
0
118
177
460
527
1634
7591
30425
6380

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


Range
Current

Total

Peak

Average

Number


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


Histogram of the depth of visible points
1
2
3
4
5
6
7
8
9
10
more
8228856
1169656
106399
32374
3810
4416
1272
85
29
5
2

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

This section displays information about the shading done in PRMan. In the web view of the statistics, a drop-down box allows you to view shading statistics for either all shading, reyes-only or ray-hit only shading.

Timer Elapsed
Shader definition cache timer 0:00.1
Memory Peak MB Current MB
Shader definition storage 0.36 0.36
Shader tag storage 0.00 0.00
Shader argument storage 0.01 0.01
Shader instance storage 0.00 0.00
Vertex instance storage 0.00 0.00
Shader object storage 0.11 0.01
Local storage 2.36 2.36
Sample storage 5.42 0.00
Shader profiler storage 0.00 0.00
Shader definition cache hit ratio 0
Shader definition cache misses 4
Shader object cache hit ratio 0

All shading/Reyes shading/Ray hit shading


Timer Elapsed
All shading 0:22.9
Shading setup time 0:00.0
Displacement shading time 0:00.0
Opacity shading time 0:00.0
Surface shading time 0:01.9
Light shading time 0:00.0
Atmosphere shading time 0:00.0
Time spent in shader methods 0:20.9
Imager shading time 0:00.0
Refinement method time 0:00.0
Shader Rewrite time 0:00.0
Memory Peak MB Current MB Total MB Count
Local storage 2.36 2.36
Sample storage 5.42 0.00
Range Current Total Peak Average Number
Points shaded (and gridding) 168 132,877 454 188.48 705
Points trimmed 0
Areashadow estimate rays 215,524
Areashadow pruned rays 5,675,614
Light cache hits 0
Light cache misses 186
Shader definition cache time:
The time spent retrieving shader definitions from the cache, or loading them if not available.
Shader definition storage:
This is the storage used for the in-memory representation of .slo files.
Shader tag storage:
The symbol table storage used by shader handles.
Shader argument storage:
Storage used to bind values from the graphics state and primitives to shader parameters.
Shader instance storage:
The subset of bindings that are different between two gprims sharing a shader tag, and thus overridden on the second one. This category is all instances other than vertex instances.
Vertex instance storage:
An instance where one of the binding differences is a vertex/varying/facevarying primvar bound to a parameter.
Shader object storage:
This is the storage used to create a shader object that executes a shader.
Shader profiler storage:
Memory used to store profiling data when shader profiling is enabled.
Shader definition cache hit ratio:
Ratio of shader definition cache hits to total accesses.
Shader definition cache misses:
Number of times a shader definition was not found in the cache and had to be read from the .slo file. Includes compulsory misses.
Shader object cache hit ratio:
Ratio of shader object cache hits to total accesses. This a symptotically approaches 1.0 with good cache re-use, but can never reach it due to compulsory misses. For low values, consider increasing the shader objectcache size.
Shading setup time:
This is the time spent setting up the shaders for execution, such as creating the shading variables and preping shaders and coshaders.
Displacement shading time:
This is the time spent executing displacement shaders/methods.
Opacity/Surface/LightAtmosphere/Imager/Refinement shading time:
This is the time spent in the corresponding type of shader/method.
Time spent in shader methods:
This is the time spent in custom methods in shaders.
Shader Rewrite time:
This is the time spent optimizing shaders at load time.
Local storage:
This is the storage used by local variables during shader execution.
Sample storage:
This is the storage used for sampling in the physically plausible shading framework.
Points shaded (and gridding):
The total represents the cumulative number of points shaded, while the average represents the average number of points shaded together. High averages represent large grids/good grid combining.
Points trimmed:
Shading points that were deemed to not need shading.
Light cache hits/misses:
This is the number of hits and misses for cached results of light shader invocations between multiple calls to illuminance.

Per-shader Statistics

This section displays statistics for individual shaders. Note that PRMan only tracks statistics per .slo file, so if a single shader class has both displacement and surface methods, that shader (and the same statistics) will be duplicated in both categories. The statistics are the cumulative values across all categories that shader belongs to.

displacement shaders

plausibleConductor2Lobe
Total time 0:08.9
Points shaded 1,299,490

surface shaders

lambert1_rfm
Total time 0:00.0
Points shaded 2,952

volume shaders

light shaders

plausibleArealight
Total time 0:14.0
Points shaded 1,311,058

method shaders

plausibleArealight
Total time 0:14.0
Points shaded 1,311,058
plausibleConductor2Lobe
Total time 0:08.9
Points shaded 1,299,490

imager shaders

Displacement/surface/volume/light/method/imager shaders:
The shader statistics are broken up into these categories. A shader may appear in more than one category if it contains methods for multiple categories, however the results are cumulative across categories.
Total time:
The total time spent shading by that shader.
Points shaded:
The total points shaded by methods of the shader. If the same points are shaded by multiple methods, the result is cumulative -- 100 points shaded by 2 methods will display 200 points shaded.

Ray Accelerator Statistics

This section of the XML statistics displays information about the ray acceleration data structures used by the renderer.

Traceable prims
4815


Prims after splits
414342


Disabled prims
97356


Total rays
28413112


BBox tests
3462933030


Re-bbox nodes
13362599


Re-bbox prims
550855


Primitive tests
105832198


Primitive hits
27350862


Useful hits
18665356


Ray continuations
17080


Total ray length
1.50192e+010


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
2
3
4
5
6
7
8
9
9
more
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.
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
83943


Stored HSRs
83943


Triangle hit tests
99193670


Triangle hits
13024998


Flat BLP hit tests
0


Flat BLP hits
0


Curved BLP hit tests
0


Curved BLP hits
0


Rejected hits due to Sides 1
0


NURB hits
4844432


NURB hits that were trimmed
0


Catmark grid cache hits
1015753


Catmark grid cache misses
542182


GUT cache cold tessellations
firstTessellationsSum_0
475867


firstTessellationsSum_1
331866


firstTessellationsSum_2
153865



GUT cache lookups
lookupsSum_0
1.49628e+007


lookupsSum_1
1.67528e+007


lookupsSum_2
5.4934e+007



GUT cache hits
hitsSum_0
1.42927e+007


hitsSum_1
1.5785e+007


hitsSum_2
5.41903e+007



GUT cache misses
missesSum_0
670079


missesSum_1
967746


missesSum_2
743687



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.

Disp
Bound
Ratio
Object/Shaders
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
Timer
Elapsed


Read
0:20.1


Decompress
0:03.0



Memory
Peak MB

Current MB


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
Timer
Elapsed


Filtering time
0:00.5



Requests
74959


Samples
1075543


# samples per request
2
4
8
16
32
64
128
256
512
1024
2048
4096
more
0
5525
20587
43167
4189
992
268
80
26
86
31
8
0


Max filter width
1
2
3
4
5
6
7
8
9
10
11
12
more
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
Timer
Elapsed


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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
more
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0

# minmax drawn
2
4
8
16
32
64
more
0
0
0
0
0
0
0

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
Timer
Elapsed


Read
0:02.1


Decompress
0:20.3



Memory
Peak MB

Current MB


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
Timer
Elapsed


Filtering time
0:26.6



Requests
91026


Analytic filters
52225


Sampled filters
38801


# samples per request
2
4
8
16
32
64
128
256
512
1024
more
0
0
0
0
0
0
0
91206
0
0
0


Max filter width
1
2
3
4
5
6
7
8
9
10
11
12
more
12103
46
251
783
1893
4682
9605
11261
8327
6161
5045
4238
26631

walk histogram
2
4
8
16
32
64
128
256
512
more
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

Timer
Elapsed


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


Cache lookup levels
0
1
2
3
4
5
6
7
8
9
more
0
0
0
0
0
0
0
0
0
0
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.

Timer
Elapsed

User

System


Total time
16:06.2

27:14.6

0:34.0



Memory
Peak MB

Current MB


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.

copyright
Copyright (c) 1988-2006 Pixar.


version
Pixar PhotoRealistic RenderMan 13.0b3 (Win32.iP4)


linkTime
linked Thu Mar 23 15:19:35 PST 2006


licenseDigest
= #$$Q|mnuOwmoy#uHH|v'xzrpsz-*%o !sooz.'|m'xzrpqzy,t)y.vot0xy|v'vzsp'zwqvs.-y#v+"(


timestamp
Fri Mar 24 15:44:04 PST 2006


xRes
1024


yRes
576


xSamples
4


ySamples
4


cropLeft
0


cropRight
1


cropTop
0


cropBottom
1


bucketXRes
16


bucketYRes
16


gridSize
289


textureMemory
0


brickMemory
0


deepShadowTiles
0


geoCacheMemory
0


zThreshR
0.996094


zThreshG
0.996094


zThreshB
0.996094


oThreshR
0.996094


oThreshG
0.996094


oThreshB
0.996094


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.