The following problems still exist in this release and are in the process of being resolved.
Known Issues
If close to or more than 4GB of system memory (RAM) are installed in a 32-bit Solaris system, and if some of this memory is mapped to physical addresses above 4GB, then the OpenGL immediate mode performance of NVIDIA Quadro GPUs in this system may be lower compared to a similar system on which no memory is mapped above 4GB.
Similarly, Quadro OpenGL immediate mode performance may also be lower on 32-bit/64-bit Solaris/5.11 Express systems on which support for large user pages (page sizes of 2MB or 4MB) has been enabled. This normally is the case when more than 1GB of RAM is installed.
For best immediate mode OpenGL performance, it is recommended to
use a 64-bit system and to disable support for large pages. The
latter can be achieved by adding the following line to the
/etc/system configuration file:
set auto_lpg_disable=1
If you are using a laptop please see the "Known Laptop Issues" in Appendix I, Configuring a Laptop.
When FSAA is enabled (the __GL_FSAA_MODE environment variable is set to a value that enables FSAA and a multisample visual is chosen), the rendering may be corrupted when resizing the window.
When a multithreaded OpenGL application exits, it is possible for libGL's DSO finalizer (also known as the destructor, or "_fini") to be called while other threads are executing OpenGL code. The finalizer needs to free resources allocated by libGL. This can cause problems for threads that are still using these resources. Setting the environment variable "__GL_NO_DSO_FINALIZER" to "1" will work around this problem by forcing libGL's finalizer to leave its resources in place. These resources will still be reclaimed by the operating system when the process exits. Note that the finalizer is also executed as part of dlclose(3), so if you have an application that dlopens(3) and dlcloses(3) libGL repeatedly, "__GL_NO_DSO_FINALIZER" will cause libGL to leak resources until the process exits. Using this option can improve stability in some multithreaded applications, including Java3D applications.
XVideo will not work correctly when Composite is enabled unless using X.Org 7.1 or later. See Appendix Q, The X Composite Extension.
This section describes problems that will not be fixed. Usually, the source of the problem is beyond the control of NVIDIA. Following is the list of problems:
Problems that Will Not Be Fixed
This motherboard uses a LinFinity regulator on the 3.3 V rail that is only rated to 5 A -- less than the AGP specification, which requires 6 A. When diagnostics or applications are running, the temperature of the regulator rises, causing the voltage to the NVIDIA chip to drop as low as 2.2 V. Under these circumstances, the regulator cannot supply the current on the 3.3 V rail that the NVIDIA chip requires.
This problem does not occur when the graphics board has a switching regulator or when an external power supply is connected to the 3.3 V rail.
On Athlon motherboards with the VIA KX133 or 694X chip set, such as the ASUS K7V motherboard, NVIDIA drivers default to AGP 2x mode to work around insufficient drive strength on one of the signals.
AGP 1x transfers are used on Athlon motherboards with the Irongate chipset to work around a problem with signal integrity.
On ALi1541 and ALi1647 chipsets, NVIDIA drivers disable AGP to work around timing issues and signal integrity issues. See Chapter 4, Common Problems for more information on ALi chipsets.
Version 1.8 of the NV-CONTROL X Extension introduced target types for setting and querying attributes as well as receiving event notification on targets. Targets are objects like X Screens, GPUs and G-Sync devices. Previously, all attributes were described relative to an X Screen. These new bits of information (target type and target id) were packed in a non-compatible way in the protocol stream such that addressing X Screen 1 or higher would generate an X protocol error when mixing NV-CONTROL client and server versions.
This packing problem has been fixed in the NV-CONTROL 1.10 protocol, making it possible for the older (1.7 and prior) clients to communicate with NV-CONTROL 1.10 servers. Furthermore, the NV-CONTROL 1.10 client library has been updated to accommodate the target protocol packing bug when communicating with a 1.8 or 1.9 NV-CONTROL server. This means that the NV-CONTROL 1.10 client library should be able to communicate with any version of the NV-CONTROL server.
It is recommended that NV-CONTROL client applications relink with version 1.10 or later of the NV-CONTROL client library (libXNVCtrl.a, in the nvidia-settings-1.0.tar.gz tarball). The version of the client library can be determined by checking the NV_CONTROL_MAJOR and NV_CONTROL_MINOR definitions in the accompanying nv_control.h.
The only web released NVIDIA SunOS driver that is affected by this problem (i.e., the only driver to use either version 1.8 or 1.9 of the NV-CONTROL X extension) is 1.0-8756.