NVemulate

NVemulate allows you to emulate the functionality of various GPUs (very slowly) in software.  In addition, you can use it to control GLSL Support.  For more information, please read our GLSL release notes.

New in this version of NVemulate:

• Support for GeForce 8 Series
• Include support enable for EXT_gpu_shader4, EXT_geometry_shader4, and EXT_bindable_uniform

[Download] NVemulate (.exe) Built: Jan 05 2007
[Download] Release Notes for NVIDIA OpenGL Shading Language Support (.pdf). Oct 27 2006

The following NVemulate-related sections have been excerpted from the GLSL release notes. 

Controlling GLSL Support with NVemulate

GLSL support is enabled by default in Release 95 drivers, but you can enable/disable the enhanced GLSL support as well as manipulate software emulation of GPU feature sets and control the dumping of GLSL source and assembly text for debugging, The NVemulate control panel looks like this:
 

To enable the enhanced GLSL functionality, select the “G80(GeForce 8800 GTS, Quadro FX)” option from the GLSL compiler device support drop box and press the “Apply” button.  No changes to NVemulate settings take effect until the “Apply” button is pressed.  Pressing the “Restore” button reverts the display settings to the driver’s current applied state.

With the G80 functionality enabled, the driver will export an additional set of extension strings exposing the enhanced capabilities. The extensions string will now include GL_EXT_gpu_shader4, GL_EXT_geometry_shader4, and GL_EXT_bindable_uniform. Additionally, the GLSL parts of the GL_NV_transform_feedback extension are now also enabled. Furthermore, all GLSL shaders not using these capabilities will now be compiled to the more capable G80 target. This enables better dynamic flow control and array indexing, among other benefits.

As noted earlier, some graphics cards are not capable of GLSL or enhanced GLSL in hardware, so this may require enabling a higher hardware emulation level. (A minimum of NV30 for GLSL and a minimum of G80 for the enhancements)

NVemulate Troubleshooting

If you do not see the enhanced extensions advertised, make sure of the following:

• You are using a Release 95 driver, preferably version 97.02 or later.
• Check this by going to the NVIDIA Control Panel, selecting "Help", then "System Information". In the "Details" panel, the "ForceWare version" should be 97.02 or better.
• You can also check this by making sure the version string returned by glGetString(GL_VERSION) is 2.1.0 or better.
• You are using a Quadro or GeForce card
• You are using a Quadro or GeForce graphics card (preferably an FX card).

If you installed a new NVIDIA graphics driver, the GLSL-related settings are reset to their defaults (GLSL support disabled) so you must enable GLSL again with NVemulate.

NVemulate Options to Aid Debugging

Other check boxes in the NVemulate control panel are designed to aid debugging of GLSL programs as well as help developers report GLSL issues so they can be readily addressed in future drivers.

Writing Program Object Assembly

When the “Write Program Object Assembly” box is checked, the driver outputs fasm_%d_%d.txt and vasm_%d_%d.txt files into the application's working directory when fragment and vertex shaders respectively are linked where the first %d represents the application’s handle number for the linked program object, and the second %d is a unique integer representing this link instance. These files are in a form similar to what the standalone Cg compiler (cgc.exe) outputs. The assembly text conforms to one of the vertex or fragment program extensions depending on the shader type and hardware capabilities. For G80 targeted shaders, the output will be in the NV_gpu_program4 family of languages.

Before you submit a GLSL bug report to NVIDIA, double check that the assembly generated for your successfully linked program object matches what you expect. Sometimes you may find bugs in your own shader source code by seeing how the driver’s Cg compiler technology translated your shader into assembly form. If the assembly seems correct or it clearly does not correspond to your high-level shader source, please include the assembly output with your bug report.

Writing Program Object Source

When the “Write Program Object Source” box is checked, the driver outputs fsrc_%d_%d_%d.txt and vsrc_%d_%d_%d.txt files into the application's working directory when fragment and vertex shaders respectively are linked where the first %d represents the application’s handle number for the linked program object, the second %d is the shader object handle, and the third %d is a unique integer representing this link instance. These files contain the concatenation of all your shader object source text. This is the actual GLSL source text that is compiled and linked.

These files are generated whether or not the program object links successfully.

Check that your source code text has been properly transferred to the driver.  If you still suspect an OpenGL driver bug, please send the source and assembly files.

Writing Info Log

When the “Write Info Log” box is checked, the driver outputs ilog_%d.txt files when a program object is linked where the %d represents the handle number for application’s program object being linked. The info log for a program object contains both vertex and fragment shader related errors so a single ilog_%d_%d.txt file is generated per program object and link instance.

If this file is empty (zero length), that typically means no errors were generated and the program object linked successfully.

Check your source code and fix any errors reported in the info log that reflect errors or warnings in your shader source code. If you still cannot resolve the messages in the info log, please send the info log, source, and assembly files.

Forcing Software Rasterization

Driver bugs in GLSL programs may be due to the compiler translating your shader incorrectly into a GPU executable form or the problem may be a more basic driver bug. One way to get a “second opinion” about the behavior of your application is to force software rasterization. In this mode, all OpenGL rendering is done with the CPU rather than the GPU. This is extremely slow, particularly when per-fragment programmability is involved. However, if the results of hardware rendering and the software rasterizer do not match, that is an important clue as to the nature of a possible driver bug.

Additionally, if the hardware rendering and the software rasterizer results match, you may want to review once more whether the problem lies with your shader source before reporting a bug.

Strict Shader Portability Warnings

In the past, NVIDIA has provided extensions to GLSL to make the language more compatible with other high-level shading languages. While this can be convenient, it also can cause portability problems. To aid developers in writing portable code, NVIDIA now flags the usage of these capabilities with warnings by default. This behavior can be strengthened by checking the “Generate Shader Portability Errors” checkbox in NVemulate. Additionally, with version 1.20, the GLSL spec has adopted many of these language extensions. As a result, NVIDIA has further tightened the syntax checking on the compiler if “#version 120” or “#version 110” are specified in the shader, such that the use of language extensions not included in version 1.20 will be flagged as an error.

Older Archives
[Download] NVemulate (.exe) Built: Feb 17 2005
[Download] Release Notes for NVIDIA OpenGL Shading Language Support (.pdf) [203 KB] August 30 2004