NVemulate allows you to emulate the functionality of newer NVIDIA GPUs (sometimes very slowly) in software. In addition, you can use it to control behavior of the driver's OpenGL Shading Language (GLSL) implementation.
New in this version of NVemulate:
By default, the NVIDIA OpenGL driver will expose all features supported by the NVIDIA GPU installed in your system. To have the driver emulate features of GPUs newer than the one installed in your system, select the newer GPU generation from the "Feature Set Emulation" menu. When using emulated features, the OpenGL driver may end up processing drawing commands partially or fully on the CPU, with no GPU acceleration.
By default, the OpenGL Shading Language (GLSL) compiler in the NVIDIA OpenGL driver will generate code targeting the NVIDIA GPU installed in your system. To have the compiler generate code targeting a different GPU family, select the entry for that family from the "GLSL Compiler Device Support" menu. To target a GPU family newer than the GPU installed in your system, you will need to enable feature set emulation as described above.
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.
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.
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 example, assembly for shaders targeting the G80 family will use 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.
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.
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 can also 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 to turn those warnings into errors. Additionally, portability warnings will always be treated as errors for any shader containing a "#version" directive. Version directives are already required to use any features added to the shading language in version 1.20 or higher.
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.
If you do not see changes from the NVemulate control panel taking effect, make sure of the following:
When you install a new NVIDIA graphics driver, the settings updated by NVemulate may be reset to their defaults, so you it may be necessary to re-run NVemulate after such an update.