FAQ

This FAQ is a collection of technical tips and other relevant information regarding the optimal use of PTC applications on Sun systems. It is the result of experience of many Sun engineers who have been working with Pro/ENGINEER and other PTC applications trying to get the best performance and quality on Sun systems.

PTC applications are constantly changing (typically every few weeks), therefore some of the information in this FAQ may not be entirely up to date.

With regards to performance, keep in mind that the advice given here does not guarantee that your performance will necessarily improve. Please use common sense and pay attention to details. Test each change separately and note the performance difference.

One way to determine the graphics card used in your Sun machine is to run this command:

% /usr/sbin/prtconf -F
/pci@1f,700000/SUNW,XVR-2500@0:kfb0

The output contains a code name of the graphics card attached to the console (kfb in the above example).

The following are the Sun hardware-accelerated graphics cards currently used with the Sun Solaris/SPARC systems, in reverse chronological order:

Code name			Marketing name
--------------			--------------
KFB                             XVR-2500
IFB3-Lite			XVR-600
jfb				XVR-1200
IFB-Lite+			XVR-500
gfb, zfb			XVR-1000
IFB-Lite			Expert3D-Lite
IFB				Expert3D
AFB				Elite3D
double-buffered FFB2+	        Creator3D Series 3

If the output does not contain any of the above code names, it means that your system does not have a hardware-accelerated 3D graphics card installed that is certified to work with Pro/E.

To determine which hardware platforms are certified to work with specific versions of Pro/E see: PTC Hardware Support Pages

To configure the graphics card for Pro/E, do the following.

If you have configured the window system to use the 24-bit mode, or if you are using the XVR-1000 (gfb, zfb) card, no further configuration is necessary.

Otherwise, use the following recommendations.

For Expert3D or later graphics cards (code names IFB, IFB-Lite, IFB-Lite+, IFB3-Lite, or jfb), run these commands (either as root or as the user who logged the windowing system.):

fbconfig -defaults (to make sure all defaults are used)
fbconfig -defoverlay true



This will configure the graphics card for overlay planes to be used with Pro/E menus and dialog boxes correctly. In addition, this will prevent repainting of the main graphics window when Pro/E menus and dialog boxes overlap it.

For Elite3D (code name AFB, AFB-Lite), the corresponding commands are:

afbconfig -defaults (to make sure all defaults are used)
afbconfig -defoverlay true -extovl enable



The "-extovl enable" setting will help prevent color-flashing.

For Creator3D series 3 (code names FFB2+), run the following commands:

ffbconfig -defaults (to make sure all defaults are used)
ffbconfig -defoverlay true
ffbconfig -extovl enable



This setting will help prevent color-flashing.

For these changes to take effect, restart the window system by logging out and then logging in again.

These fbconfig/afbconfig/ffbconfig settings are only needed to be set once. They will persist across window system restarts and reboots.

To find out exactly what version of the graphics card you have, run one of the following commands:

Expert3D or later:	fbconfig  -prconf
Elite3D:		afbconfig -prconf
Creator3D:		ffbconfig -prconf

To make sure your configuration is correct, run one of the following commands:

Expert3D or later:	fbconfig  -propt
Elite3D:		afbconfig -propt
Creator3D:		ffbconfig -propt

The output should say (among other things):

Default Visual: Non-Linear Overlay Visual (word Overlay is important)
Extended Overlays: enabled

Dual-headed configurations are supported starting with Pro/E Wildfire. If you have two graphics cards and two monitors connected to your system, you can run two PTC graphics applications at the same time, for example two sessions of Pro/E.

To configure dual-heads, add the following to the last line of file /etc/dt/config/Xservers (If /etc/dt/config/Xservers does not exist, copy /usr/dt/config/Xservers to /etc/dt/config/Xservers):

-dev /dev/fb0:/dev/fb1

To configure the graphics card correctly for the second head:
fbconfig -dev /dev/fb1 -defoverlay true

Starting with Pro/E Wildfire, we recommend that you start the window system in 24-bit mode. Also, if you use JDS/GNOME instead of CDE, configuring the window system in the 24-bit mode is a very good idea.

For the earlier versions of Pro/E, and if you are not using JDS/GNOME, the answer depends on whether you experience color-flashing with the default 8-bit mode or not. If you don't see color-flashing the answer is no. You'll probably be better off using the default 8-bit mode.

With JDS/Gnome or CDE, you can start the window system in the 24-bit mode by adding "-dev /dev/fb defdepth 24" to the end of the last line of file /etc/dt/config/Xservers (If /etc/dt/config/Xservers does not exist, copy /usr/dt/config/Xservers to /etc/dt/config/Xservers). You must be root to do this.

Here is an example of the Xservers file setting the window system to the 24-bit mode for two monitors and two graphics cards. It assumes that the graphics cards are attached to /dev/fb0 and /dev/fb1 as shown in the output of the ls -l /dev/fb* command.

:0 Local local_uid@console root /usr/openwin/bin/Xsun :0 \
    -dev /dev/fb0 defdepth 24 -dev /dev/fb1 defdepth 24 -nobanner

The window system mode (8-bit or 24-bit) can be checked by using the /usr/openwin/bin/xwininfo command and clicking on the workstation background (that is "desktop"). The command will print out information about the depth (8 or 24).

If you experience Pro/ENGINEER or other MCAD system problems related to your graphics configuration, first make sure you have the latest revisions of the following patches corresponding to your type of the graphics card, Solaris version, and OpenGL version:

• Graphics card patch
• Xsun (Sun X-Server) patch
• OpenGL patches (both 32-bit and 64-bit)

For example, if you use Solaris 9, XVR-1200, and OpenGL 1.3, the corresponding patches are 114555 (XVR-1200), 112785 (Xsun), 113886 (OpenGL 1.3 32-bit), and 113887 (OpenGL 1.3 64-bit).

You can obtain these and all other Sun patches from SunSolve. Note that installing or updating a graphics card patch requires a subsequent system reboot with boot -r, although installing or updating the Xsun and OpenGL patches only requires logging out of CDE or GNOME and logging in again.

If you still have system or graphics problems, run the following script and send the results to your support organization. Please run it locally using exactly the same configuration as the user experiencing the problem. If it is more convenient for you to run it remotely, make sure that the DISPLAY environment variable is set to :0.0 and that you are logged in as the same user who has started the window system on that machine (that is the user who logged into the windowing system).

check_config.csh

This script uses the following utilities which you will also need to download (or build if you prefer) to the same location as the check_config script:

ogl_inquire (binary)
ogl_inquire.c (source)

If you redirect the output of check_config.csh to a file, please redirect both standard output and standard error to the same file, like this for example:

csh:
check_config.csh >& `hostname`_config.txt
sh/ksh:
check_config.csh > `hostname`_config.txt 2>&1

• Use the fastest system available
  

  Check http://www.sun.com/desktop/products for the best system currently available.
  
  
  
  

• Make sure the system has sufficient RAM
  

  Pro/ENGINEER can use large amounts of RAM and disk swap space depending on the size of the model. As a rule of thumb, start with 1 GB of RAM and about 512 MB of disk swap space. If your Pro/ENGINEER part or assembly is large you are likely to need more RAM and/or disk swap space.

  Starting with Solaris 8, the best way to check if you need more memory is to use prstat(1) with microstate process accounting turned on:

  /usr/bin/prstat -m

  Watch the DFL (data fault) value for the Pro/E process (called "pro"). It will show the percentage of your process wall clock time spent waiting for data due to memory shortage. Zero there means there is no waiting and no memory shortage.

  You can also use vmstat to monitor your paging activity. Start it in a separate window before starting Pro/ENGINEER:

  /usr/bin/vmstat 3

  Watch the "sr" column in the vmstat output. When the numbers in that column are consistently zero, then there is no paging to disk occurring and your RAM is sufficient. Otherwise, performance will improve with more RAM.

  As one more alternative, you can watch for the disk activity reported for the swap partition (assuming you use a swap partition rather than file). One way to do this is to run the iostat(2) command. Any significant input/output (I/O) in a swap partition is a sure sign of memory shortage. For example, you can use this command:

  /usr/bin/iostat -n 3

  If paging to disk is unavoidable, try to distribute swap areas over multiple disks (spindles). This will allow more concurrency and improve performance.

• Make sure you use a recent version and build of Pro/ENGINEER

  You can check the version of Pro/E by executing it with a single "-v" argument, for example:
  
  % proe1 -v /tmp/temp.out
% cat /tmp/temp.out
Pro/ENGINEER Release 27.0 2006010



• Make sure OpenGL and the graphics hardware are configured correctly

  To check the setup of Sun OpenGL, run this utility:

  /usr/openwin/demo/GL/ogl_install_check

  and make sure "GLX: Context is direct" is returned.

  One thing that can be wrong is your DISPLAY environment variable. The best value for it is ":0.0" (or ":0.1" for the second monitor). If the $DISPLAY value contains your machine name or (especially) your domain name, the system may turn graphics hardware acceleration (DGA) off. Even with X_WINDOWS graphics, "setenv DISPLAY :0.0" will perform better than "setenv DISPLAY hostname:0.0", and especially better than "setenv DISPLAY hostname.domain.com:0.0".

  If you log into the window system using one user ID and then switch to another (using "su"), Pro/E will switch to the X_WINDOWS mode even if you requested OpenGL. Due to a security feature in Solaris, "su"ing to the user other than the one who started the window system disables DGA (Direct Graphics Access) to the framebuffer thus making Pro/E graphics very slow.

  If you wish, you can remove this security feature and thus make graphics fast for all users by doing the following:

  • become root
  • edit the permission in /etc/logindevperm to:
    /dev/console 0666 /dev/fbs/* # frame buffers
    
  • reboot
  • Note that any user will now have read/write access to the contents of your screen.

• Consider removing "ramped color background"

  By default, starting with version 2000i (R21), Pro/E uses a "ramped color background," that is a background where the color varies from dark blue at the bottom of the screen to light blue at top.

  Our performance tests have revealed that rendering this background for each graphics frame can produce a very significant graphics performance hit (for example, 25%).

  To turn off the ramped color background, you can download this file:

  NO_RAMP.scl

  and add the following line to your config.pro:

  SYSTEM_COLORS_FILE /wherever_you_install_it/NO_RAMP.scl

  Alternatively, you can create this file yourself:

  - Start Pro/E
- UTILITIES -> COLORS -> SYSTEM ...brings up system colors menu
- Turn off BLENDED BACKGROUND checkbox at bottom of System Colors popup menu
- FILE -> SAVE in System Colors popup menu
- Save new system colors as NO_RAMP.scl
- Exit Pro/E


• Consider setting OGL_NO_VBLANK

  Using OpenGL, if you set the OGL_NO_VBLANK environment variable before running Pro/E, for example:

  setenv OGL_NO_VBLANK

  your graphics performance may increase significantly. The price is that the image may not look correctly on the screen.

  When you set OGL_NO_VBLANK, you are forcing OpenGL not to wait for the vertical retrace, before the two buffers are swapped.

  This effect can be observed with the OpenGL verification program, /usr/openwin/demo/GL/ogl_install_check.

  With OGL_NO_VBLANK unset (default), ogl_install_check reports a frame rate of 66.59 frames per second (FPS) on an Ultra2/Elite3Dm6 system.

  With OGL_NO_VBLANK set, ogl_install_check reports a frame rate of 411.18 FPS, on the same system.

• For texture mapping with Elite3D, test AFB_IMM_TEXTURE

  In some cases, setting this environment variable before running Pro/ENGINEER

  setenv AFB_IMM_TEXTURE 1

  can seriously improve texture mapping graphics performance with the Elite3D graphics card.

  However, in other cases (particularly when texturing very small polygons), it may actually make it slower. So it is important to test it and see whether it helps in your case.

• Make sure Pro/E is installed locally when running a benchmark

  Benchmarking Pro/E from a NFS mounted filesystem is a benchmark of the network and not necessarily of Pro/E. We realize that in real life using the network is often necessary, but for benchmarks you need to separate Pro/E performance from network performance. Otherwise you won't know what you have measured.

  When running a benchmark with the NFS-mounted Pro/E is unavoidable, try setting the following environment variable

  setenv LD_BIND_NOW 1

  before running the benchmark. It will cause all shared libraries to be loaded at startup time, thus saving the expense of doing it across NFS during a particular operation. Note that this method will not improve the total performance; it's simply shifting the job in time.

• Use the following commands in your config.pro file if possible

  GRAPHICS               OPENGL
  SAVE_TRIANGLES_FLAG    NO
  MENU_HORIZONTAL_HINT   RIGHT
  WINDOWS_SCALE          .90
  THERMO_POSITION_HINT   NO_WINDOW_OVERLAP
  INSTANCE_SEARCH_EXHAUSTIVE NO
  MAX_ANIMATION_TIME     0.0
  

  Options MENU_HORIZONTAL_HINT, WINDOWS_SCALE, THERMO_POSITION_HINT will prevent the menus from overlapping the main graphics window, thus eliminating any chance of unnecessary repainting. Option "WINDOWS_SCALE .90" also decreases the size of the main graphics window a little, thus making graphics rendering faster.

  If INSTANCE_SEARCH_EXHAUSTIVE is set to YES, model loading time may increase dramatically.

  Setting LODS_ENABLED to YES in config.pro or setting the Environment->LOD option will result in a faster spinning of shaded images although surface tessellation will take longer. In R18 and later, you can control the level of LOD by:
  
  Environment->LOD
View->Orientation->Spin->LOD-scale



  PLEASE BE CAREFUL WITH THE LODS_ENABLED option; it has been reported to seriously DEGRADE performance in some cases. Test its impact on performance in your case before using it for benchmarking.

  Option "MAX_ANIMATION_TIME 0.0" will disable Pro/E "animation" feature which should not be used in graphical benchmarks. If this option is not specified, by default Pro/E can make a faster graphics device do more work with the same trail file. It measures the time it takes to paint a frame on a given machine and changes the number of frames painted depending on that time. You can also specify "MIN_ANIMATION_STEPS 0" to disable the animation feature.

• DO NOT use the following commands in your config.pro file if possible

  SAVE_TRIANGLES_FLAG        YES
  SPIN_WITH_PART_ENTITIES    YES
  SPIN_WITH_SILHOUETTS       YES
  INSTANCE_SEARCH_EXHAUSTIVE YES
  SHOW_SHADED_EDGES          YES
  MAX_ANIMATION_TIME         any value other than 0.0
  MIN_ANIMATION_STEPS        any non-zero value
  

On Sun systems Pro/E will print out a traceback any time it crashes. The traceback is produced in the terminal window where Pro/E was started, and also copied to file /var/tmp/traceback.txt.

If this happens, send the entire traceback to the PTC Technical Support organization, along with the Pro/E version/build number you are using and the results of the check_config script described above.

Although the traceback may contain many ???????? strings (since the Pro/E executable is usually "stripped"), PTC Technical Support engineers can convert it to a real traceback at PTC. This traceback will help PTC engineers debug the problem that caused Pro/E to crash.

Note that a traceback alone does not provide enough information to fully debug the problem. Try to supply as much information about the problem as possible: Pro/E version/build number, the Pro/E trail file leading to the crash, any messages produced, and the corresponding Pro/E part/assembly. The best way to help the debugging process is to try to make a reproducible test case out of each crash.

However, even if it is impossible to create a reproducible test case out of each crash, the tracebacks will help PTC engineers with the QA procedures.

If you have access to dbx (Sun command-line debugger), you can still generate the tracebacks from the core files (for Pro/E or any other PTC executable). Starting with Solaris 8, you can also do it with the pstack(1) command.

At the user sites, dbx will also generate "blind" tracebacks (although they won't have the ???????? strings, they will just have the hex address of each PTC routine instead). You can send those to PTC Technical Support as well.

In addition to Pro/E where such a traceback is generated automatically, you can get a traceback on crash of any application running under Solaris. The details of this procedure are described in

Generating and Handling Application Traceback on Crash
http://developers.sun.com/solaris/articles/traceback.html

You can also try to separate the Pro/E crashes that happen in the X-Windows, Sun graphics and other system code from those crashing in Pro/E per se. You can do that by looking at the routines in the traceback following sigacthandler If you see a series of lines containing ???????? (for stripped Pro/E executables which should normally be the case), that means the crash happened in a Pro/E routine. If, on the other hand, it shows something like Xm...,_Xm..., Xt..., _Xt, SetValues..., this is probably in X-Windows/Motif. If you see malloc, realloc, or free close to sigacthandler, it is likely to be a memory overwrite which can happen either in Pro/E or in system libraries.

You can change the size of the font in Pro/E menus by setting the attribute "menuitem_font" in the config.pro file in the working directory. The attribute will accept any X font listed by the "xlsfonts" command.

For example, adding the following line to your config.pro file would in this case change the menu font to a 24 point "sony" font:

menuitem_font \
-sony-fixed-medium-r-normal--24-230-75-75-c-120-jisx0201.1976-0



In Pro/E Wildfire, there are config.pro options to change the font size in a message window:

default_font

menu_font

popuphelp_font

fonts_size

The first three have the syntax

name, style, point-size

for example:

default_font courier,bold,14

The final option allows the user to enlarge or reduce their font size without selecting a font name:

fonts_size small | medium | large

Pro/ENGINEER system colors may be displayed improperly or windows may flash as the cursor is moved due to an exhausted hardware colormap. Closing other graphical applications (especially the color-hungry ones like SoftWindows) may resolve the problem. This includes iconized applications.

One more way to avoid color-flashing is to use FFB2+ (Creator3D Series 3) or AFB (Elite3D) graphics cards instead of the older Creator3D cards. They have three hardware colormaps. Note that IFB (Expert3D) and latest cards have only one hardware colormap, so they may be more susceptible to color-flashing than Elite3D.

You can take advantage of the additional hardware colormaps by specifying "-extovl enable" in the ffbconfig (for Creator3D Series 3) or afbconfig (for Elite3D) command.

Finally, as the last resort, you can use Pro/E configuration option OVERLAYS_ENABLED. If you add the following command to your config.pro file:

OVERLAYS_ENABLED NO

then Pro/ENGINEER will use the same 24-bit visual for its menus and dialog boxes as for the main graphics window. This way, Pro/E will not use any colors from the 8-bit colormap and will not contribute to color flashing in any way. The downside of this method is that Pro/E menus, help screens and dialog boxes overlapping the graphics window(s) will cause extra graphics repaints.

Wildfire 2.0 is officially certified to run on the Solaris 10/Sparc platform. However in order to have full functionality of the embedded browser you must follow these steps and apply recommended patch:

• Point you browser to Point Patch
• Agree to the terms
• Enter 119733-02 in the text box
• Click Find Point Patch
• Install Patch