From: Simon Schubert The official minimum software requirements for the NVIDIA
-FreeBSD Graphics Driver are as follows: For the most complete and accurate listing of supported GPUs,
+please see the Supported Products List, available from the NVIDIA
+FreeBSD x86 Graphics Driver download page. Please go to http://www.nvidia.com/object/unix.html, follow the
+Archive link under the FreeBSD x86 heading, follow the link for the
+185.18.36 driver, and then go to the Supported Products List. Below are the legacy GPUs that are no longer supported in the
+unified driver. These GPUs will continue to be maintained through
+the special legacy NVIDIA GPU driver releases. The 173.14.xx driver supports the following set of GPUs: The 96.43.xx driver supports the following set of GPUs: The 71.86.xx driver supports the following set of GPUs: Additionally, the kernel source tree must be installed in
-/usr/src/sys (package 'ssys' installed) Note that FreeBSD -STABLE versions older than FreeBSD 5.3 and
-FreeBSD 6.x/7.x -CURRENT development snapshots are not
-supported. The NVIDIA Accelerated FreeBSD Graphics Driver consists of the
-following components. The following driver options are supported by the NVIDIA X
+driver. They may be specified either in the Screen or Device
+sections of the X config file. X Config Options Configure AGP support. Integer argument can be one of: Note that NVIDIA internal AGP support cannot work if AGPGART is
+either statically compiled into your kernel or is built as a module
+and loaded into your kernel. See Chapter 11,
+Configuring AGP for details. Default: 3. Disable drawing of the NVIDIA logo splash screen at X startup.
+Default: the logo is drawn for screens with depth 24. Sets the path to the PNG file to be used as the logo splash
+screen at X startup. If the PNG file specified has a bKGD
+(background color) chunk, then the screen is cleared to the color
+it specifies. Otherwise, the screen is cleared to black. The logo
+file must be owned by root and must not be writable by a non-root
+group. Note that a logo is only displayed for screens with depth
+24. Default: The built-in NVIDIA logo is used. Enable or disable hardware acceleration of the RENDER extension.
+Default: hardware acceleration of the RENDER extension is
+enabled. Disable the RENDER extension. Other than recompiling it, the X
+server does not seem to have another way of disabling this.
+Fortunately, we can control this from the driver so we export this
+option. This is useful in depth 8 where RENDER would normally steal
+most of the default colormap. Default: RENDER is offered when
+possible. Enable or disable the Unified Back Buffer on Quadro-based GPUs
+(Quadro4 NVS excluded); see Chapter 19,
+Configuring Flipping and UBB for a description of UBB.
+This option has no effect on non-Quadro GPU products. Default: UBB
+is on for Quadro GPUs. Disable OpenGL flipping; see Chapter 19,
+Configuring Flipping and UBB for a description. Default:
+OpenGL will swap by flipping when possible. Most Quadro products by default use a 10-bit color look-up table
+(LUT); setting this option to TRUE forces these GPUs to use an
+8-bit (LUT). Default: a 10-bit LUT is used, when available. Enables RGB workstation overlay visuals. This is only supported
+on Quadro GPUs (Quadro NVS GPUs excluded) in depth 24. This option
+causes the server to advertise the SERVER_OVERLAY_VISUALS root
+window property and GLX will report single- and double-buffered,
+Z-buffered 16-bit overlay visuals. The transparency key is pixel
+0x0000 (hex). There is no gamma correction support in the overlay
+plane. This feature requires XFree86 version 4.2.0 or newer, or the
+X.Org X server. When the X screen is either wider than 2046 pixels
+or taller than 2047, the overlay may be emulated with a substantial
+performance penalty. RGB workstation overlays are not supported
+when the Composite extension is enabled. UBB must be enabled when overlays are enabled (this is the
+default behavior). Enables Color Index workstation overlay visuals with identical
+restrictions to Option "Overlay" above. The server will offer
+visuals both with and without a transparency key. These are depth 8
+PseudoColor visuals. Enabling Color Index overlays on X servers
+older than XFree86 4.3 will force the RENDER extension to be
+disabled due to bugs in the RENDER extension in older X servers.
+Color Index workstation overlays are not supported when the
+Composite extension is enabled. Default: off. UBB must be enabled when overlays are enabled (this is the
+default behavior). When color index overlays are enabled, use this option to choose
+which pixel is used for the transparent pixel in visuals featuring
+transparent pixels. This value is clamped between 0 and 255 (Note:
+some applications such as Alias's Maya require this to be zero in
+order to work correctly). Default: 0. When overlays are used, this option sets the default visual to
+an overlay visual thereby putting the root window in the overlay.
+This option is not recommended for RGB overlays. Default: off. Enables the use of a timer within the X server to perform the
+updates to the emulated overlay or CI overlay. This option can be
+used to improve the performance of the emulated or CI overlays by
+reducing the frequency of the updates. The value specified
+indicates the desired number of milliseconds between overlay
+updates. To disable the use of the timer either leave the option
+unset or set it to 0. Default: off. Enables the use of a threshold within the X server to perform
+the updates to the emulated overlay or CI overlay. The emulated or
+CI overlay updates can be deferred but this threshold will limit
+the number of deferred OpenGL updates allowed before the overlay is
+updated. This option can be used to trade off performance and
+animation quality. Default: on. Controls the threshold used in updating the emulated or CI
+overlays. This is used in conjunction with the
+EmulatedOverlaysThreshold option to trade off performance and
+animation quality. Higher values for this option favor performance
+over quality. Setting low values of this option will not cause the
+overlay to be updated more often than the frequence specified by
+the EmulatedOverlaysTimerMs option. Default: 5. Enable rotation support for the XRandR extension. This allows
+use of the XRandR X server extension for configuring the screen
+orientation through rotation. This feature is supported using depth
+24. This requires an X.Org X 6.8.1 or newer X server. This feature
+does not work with hardware overlays; emulated overlays will be
+used instead at a substantial performance penalty. See Chapter 16,
+Using the XRandR Extension for details. Default:
+off. Enable static rotation support. Unlike the RandRRotation option
+above, this option takes effect as soon as the X server is started
+and will work with older versions of X. This feature is supported
+using depth 24. This feature does not work with hardware overlays;
+emulated overlays will be used instead at a substantial performance
+penalty. This option is not compatible with the RandR extension.
+Valid rotations are "normal", "left", "inverted", and "right".
+Default: off. Enables DDC/CI support in the NV-CONTROL X extension. DDC/CI is
+a mechanism for communication between your computer and your
+display device. This can be used to set the values normally
+controlled through your display device's On Screen Display. See the
+DDC/CI NV-CONTROL attributes in Note that support for DDC/CI within the NVIDIA X driver's
+NV-CONTROL extension is deprecated, and will be removed in a future
+release. Other mechanisms for DDC/CI, such as the kernel i2c
+subsystem on Linux, are preferred over NV-CONTROL's DDC/CI
+support. If you would prefer that the NVIDIA X driver's NV-CONTROL X
+extension not remove DDC/CI support, please make your concerns
+known my emailing Enable or disable software rendering of the X cursor. Default:
+off. Enable or disable hardware rendering of the X cursor. Default:
+on. Enable or disable use of a shadow with the hardware accelerated
+cursor; this is a black translucent replica of your cursor shape at
+a given offset from the real cursor. Default: off (no cursor
+shadow). The alpha value to use for the cursor shadow; only applicable if
+CursorShadow is enabled. This value must be in the range [0, 255]
+-- 0 is completely transparent; 255 is completely opaque. Default:
+64. The offset, in pixels, that the shadow image will be shifted to
+the right from the real cursor image; only applicable if
+CursorShadow is enabled. This value must be in the range [0, 32].
+Default: 4. The offset, in pixels, that the shadow image will be shifted
+down from the real cursor image; only applicable if CursorShadow is
+enabled. This value must be in the range [0, 32]. Default: 2. Allows you to override what the NVIDIA kernel module detects is
+connected to your graphics card. This may be useful, for example,
+if you use a KVM (keyboard, video, mouse) switch and you are
+switched away when X is started. In such a situation, the NVIDIA
+kernel module cannot detect which display devices are connected,
+and the NVIDIA X driver assumes you have a single CRT. Valid values for this option are "CRT" (cathode ray tube), "DFP"
+(digital flat panel), or "TV" (television); if using TwinView, this
+option may be a comma-separated list of display devices; e.g.:
+"CRT, CRT" or "CRT, DFP". It is generally recommended to not use this option, but instead
+use the "UseDisplayDevice" option. NOTE: anything attached to a 15 pin VGA connector is regarded by
+the driver as a CRT. "DFP" should only be used to refer to digital
+flat panels connected via a DVI port. Default: string is NULL (the NVIDIA driver will detect the
+connected display devices). The "UseDisplayDevice" X configuration option is a list of one
+or more display devices, which limits the display devices the
+NVIDIA X driver will consider for an X screen. The display device
+names used in the option may be either specific (with a numeric
+suffix; e.g., "DFP-1") or general (without a numeric suffix; e.g.,
+"DFP"). When assigning display devices to X screens, the NVIDIA X driver
+walks through the list of all (not already assigned) display
+devices detected as connected. When the "UseDisplayDevice" X
+configuration option is specified, the X driver will only consider
+connected display devices which are also included in the
+"UseDisplayDevice" list. This can be thought of as a "mask" against
+the connected (and not already assigned) display devices. Note the subtle difference between this option and the
+"ConnectedMonitor" option: the "ConnectedMonitor" option overrides
+which display devices are actually detected, while the
+"UseDisplayDevice" option controls which of the detected display
+devices will be used on this X screen. Of the list of display devices considered for this X screen
+(either all connected display devices, or a subset limited by the
+"UseDisplayDevice" option), the NVIDIA X driver first looks at
+CRTs, then at DFPs, and finally at TVs. For example, if both a CRT
+and a DFP are connected, by default the X driver would assign the
+CRT to this X screen. However, by specifying: the X screen would use the DFP instead. Or, if CRT-0, DFP-0, and
+DFP-1 are connected and TwinView is enabled, the X driver would
+assign CRT-0 and DFP-0 to the X screen. However, by specifying: the X screen would use CRT-0 and DFP-1 instead. Additionally, the special value "none" can be specified for the
+"UseDisplayDevice" option. When this value is given, any
+programming of the display hardware is disabled. The NVIDIA driver
+will not perform any mode validation or mode setting for this X
+screen. This is intended for use in conjunction with CUDA or in
+remote graphics solutions such as VNC or Hewlett Packard's Remote
+Graphics Software (RGS). This functionality is only available on
+Quadro and Tesla GPUs. Note the following restrictions for setting the
+"UseDisplayDevice" to "none": OpenGL SyncToVBlank will have no effect. None of Stereo, Overlay, CIOverlay, or SLI are allowed when
+"UseDisplayDevice" is set to "none". This option controls whether the NVIDIA X driver will use the
+HorizSync and VertRefresh ranges given in a display device's EDID,
+if any. When UseEdidFreqs is set to True, EDID-provided range
+information will override the HorizSync and VertRefresh ranges
+specified in the Monitor section. If a display device does not
+provide an EDID, or the EDID does not specify an hsync or vrefresh
+range, then the X server will default to the HorizSync and
+VertRefresh ranges specified in the Monitor section of your X
+config file. These frequency ranges are used when validating modes
+for your display device. Default: True (EDID frequencies will be used) By default, the NVIDIA X driver makes use of a display device's
+EDID, when available, during construction of its mode pool. The
+EDID is used as a source for possible modes, for valid frequency
+ranges, and for collecting data on the physical dimensions of the
+display device for computing the DPI (see Appendix E,
+Dots Per Inch). However, if you wish to disable the
+driver's use of the EDID, you can set this option to False: Note that, rather than globally disable all uses of the EDID,
+you can individually disable each particular use of the EDID;
+e.g., Default: True (use EDID). Enable use of the X Int10 module to soft-boot all secondary
+cards, rather than POSTing the cards through the NVIDIA kernel
+module. Default: off (POSTing is done through the NVIDIA kernel
+module). Enable or disable TwinView. See Chapter 12,
+Configuring TwinView for details. Default: off (TwinView
+is disabled). Controls the relationship between the two display devices when
+using TwinView. Takes one of the following values: "RightOf"
+"LeftOf" "Above" "Below" "Clone". See Chapter 12,
+Configuring TwinView for details. Default: string is
+NULL. This option is like the HorizSync entry in the Monitor section,
+but is for the second monitor when using TwinView. See Chapter 12,
+Configuring TwinView for details. Default: none. This option is like the VertRefresh entry in the Monitor
+section, but is for the second monitor when using TwinView. See
+Chapter 12,
+Configuring TwinView for details. Default: none. This option describes the combination of modes to use on each
+monitor when using TwinView. See Chapter 12,
+Configuring TwinView for details. Default: string is
+NULL. When in TwinView, the NVIDIA X driver normally provides a
+Xinerama extension that X clients (such as window managers) can use
+to discover the current TwinView configuration, such as where each
+display device is positioned within the X screen. Some window
+mangers get confused by this information, so this option is
+provided to disable this behavior. Default: false (TwinView
+Xinerama information is provided). Due to bugs in some older software, TwinView Xinerama
+information is not provided by default on X.Org 7.1 and older when
+the X server is started with only one display device connected. When the NVIDIA X driver provides TwinViewXineramaInfo (see the
+NoTwinViewXineramaInfo X config option), it by default reports the
+currently enabled display devices in the order "CRT, DFP, TV". The
+TwinViewXineramaInfoOrder X config option can be used to override
+this order. The option string is a comma-separated list of display device
+names. The display device names can either be general (e.g, "CRT",
+which identifies all CRTs), or specific (e.g., "CRT-1", which
+identifies a particular CRT). Not all display devices need to be
+identified in the option string; display devices that are not
+listed will be implicitly appended to the end of the list, in their
+default order. Note that TwinViewXineramaInfoOrder tracks all display devices
+that could possibly be connected to the GPU, not just the ones that
+are currently enabled. When reporting the Xinerama information, the
+NVIDIA X driver walks through the display devices in the order
+specified, only reporting enabled display devices. Examples: In the first example, any enabled DFPs would be reported first
+(any enabled CRTs or TVs would be reported afterwards). In the
+second example, any enabled TVs would be reported first, then any
+enabled DFPs (any enabled CRTs would be reported last). In the last
+example, if DFP-1 were enabled, it would be reported first, then
+DFP-0, then any enabled TVs, and then any enabled CRTs; finally,
+any other enabled DFPs would be reported. Default: "CRT, DFP, TV" This option overrides the values reported by NVIDIA's TwinView
+Xinerama implementation. This disregards the actual display devices
+used by the X screen and any order specified in
+TwinViewXineramaInfoOrder. The option string is interpreted as a comma-separated list of
+regions, specified as '[width]x[height]+[x-offset]+[y-offset]'. The
+regions' sizes and offsets are not validated against the X screen
+size, but are directly reported to any Xinerama client. Examples: See Chapter 15,
+Configuring TV-Out for details on configuring
+TV-out. See Chapter 15,
+Configuring TV-Out for details on configuring
+TV-out. Valid values are in the range 0.0 through 1.0; See Chapter 15,
+Configuring TV-Out for details on configuring
+TV-out. Enable offering of quad-buffered stereo visuals on Quadro.
+Integer indicates the type of stereo equipment being used: Stereo is only available on Quadro cards. Stereo options 1, 2,
+and 3 (also known as "active" stereo) may be used with TwinView if
+all modes within each MetaMode have identical timing values. See
+Chapter 18,
+Programming Modes for suggestions on making sure the
+modes within your MetaModes are identical. The identical ModeLine
+requirement is not necessary for Stereo options 4 through 9
+("passive" stereo). Default: 0 (Stereo is not enabled). UBB must be enabled when stereo is enabled (this is the default
+behavior). Stereo options 1, 2, and 3 ("active" stereo) can be enabled on
+digital display devices (connected via DVI, HDMI, or DisplayPort).
+However, some digital display devices might not behave as desired
+with active stereo: Some digital display devices may not be able to toggle pixel
+colors quickly enough when flipping between eyes on every
+vblank. Some digital display devices may have an optical polarization
+that interferes with stereo goggles. Active stereo requires high refresh rates, because a vertical
+refresh is needed to display each eye. Some digital display devices
+have a low refresh rate, which will result in flickering when used
+for active stereo. Some digital display devices might internally convert from other
+refresh rates to their native refresh rate (e.g., 60Hz), resulting
+in incompatible rates between the stereo glasses and stereo
+displayed on screen. Stereo applies to an entire X screen, so it will apply to all
+display devices on that X screen, whether or not they all support
+the selected Stereo mode. Stereo options 7, 8, and 9 are only supported on G8xGL and
+higher GPUs. Multi-GPU cards (such as the Quadro FX 4500 X2) provide a single
+connector for onboard stereo support (option 3), which is tied to
+the bottommost GPU. In order to synchronize onboard stereo with the
+other GPU, you must use a G-Sync device (see Chapter 25,
+Configuring Frame Lock and Genlock for details). Stereo flipping is the process by which left and right eyes are
+displayed on alternating vertical refreshes. Normally, stereo
+flipping is only performed when a stereo drawable is visible. This
+option forces stereo flipping even when no stereo drawables are
+visible. This is to be used in conjunction with the "Stereo" option. If
+"Stereo" is 0, the "ForceStereoFlipping" option has no effect. If
+otherwise, the "ForceStereoFlipping" option will force the behavior
+indicated by the "Stereo" option, even if no stereo drawables are
+visible. This option is useful in a multiple-screen environment in
+which a stereo application is run on a different screen than the
+stereo master. Possible values: Default: 0 (Stereo flipping is not forced). Note that active
+stereo is not supported on digital flat panels. By default, when using Stereo with Xinerama, all physical X
+screens having a visible stereo drawable will stereo flip. Use this
+option to allow only one physical X screen to stereo flip at a
+time. This is to be used in conjunction with the "Stereo" and
+"Xinerama" options. If "Stereo" is 0 or "Xinerama" is 0, the
+"XineramaStereoFlipping" option has no effect. If you wish to have all X screens stereo flip all the time, see
+the "ForceStereoFlipping" option. Possible values: Default: 1 (Stereo flipping is enabled on all X screens). As part of mode validation, the X driver tests if a given mode
+fits within the hardware's memory bandwidth constraints. This
+option disables this test. Default: false (the memory bandwidth
+test is performed). This option tells the NVIDIA kernel module to completely ignore
+the indicated classes of display devices when checking which
+display devices are connected. You may specify a comma-separated
+list containing any of "CRT", "DFP", and "TV". For example: will cause the NVIDIA driver to not attempt to detect if any
+digital flat panels or TVs are connected. This option is not
+normally necessary; however, some video BIOSes contain incorrect
+information about which display devices may be connected, or which
+i2c port should be used for detection. These errors can cause long
+delays in starting X. If you are experiencing such delays, you may
+be able to avoid this by telling the NVIDIA driver to ignore
+display devices which you know are not connected. NOTE: anything
+attached to a 15 pin VGA connector is regarded by the driver as a
+CRT. "DFP" should only be used to refer to digital flat panels
+connected via a DVI port. Enable or disable the use of separate front and back multisample
+buffers. Enabling this will consume more memory but is necessary
+for correct output when rendering to both the front and back
+buffers of a multisample or FSAA drawable. This option is necessary
+for correct operation of SoftImage XSI. Default: false (a single
+multisample buffer is shared between the front and back
+buffers). The NVIDIA X driver will abort X server initialization if it
+detects that a GPU that requires an external power connector does
+not have an external power connector plugged in. This option can be
+used to bypass this test. Default: false (the power connector test
+is performed). Forces XvMC to use the 3D engine for XvMCPutSurface requests
+rather than the video overlay. Default: false (video overlay is
+used when available). Enables GLX even when the Composite X extension is loaded.
+ENABLE AT YOUR OWN RISK. OpenGL applications will not display
+correctly in many circumstances with this setting enabled. This option is intended for use on X.Org X servers older than
+X11R6.9.0. On X11R6.9.0 or newer X servers, the NVIDIA OpenGL
+implementation interacts properly by default with the Composite X
+extension and this option should not be needed. However, on
+X11R6.9.0 or newer X servers, support for GLX with Composite can be
+disabled by setting this option to False. Default: false (GLX is disabled when Composite is enabled on X
+servers older than X11R6.9.0). Enables the X server's "composite wrapper", which performs
+coordinate translations necessary for the Composite extension. Default: false (the NVIDIA X driver performs its own coordinate
+translation). Adds a 32-bit ARGB visual for each supported OpenGL
+configuration. This allows applications to use OpenGL to render
+with alpha transparency into 32-bit windows and pixmaps. This
+option requires the Composite extension. Default: ARGB GLX visuals
+are enabled on X servers new enough to support them when the
+Composite extension is also enabled. If enabled, no clipping will be performed on rendering done by
+OpenGL in the root window. This option is deprecated. It is needed
+by older versions of OpenGL-based composite managers that draw the
+contents of redirected windows directly into the root window using
+OpenGL. Most OpenGL-based composite managers have been updated to
+support the Composite Overlay Window, a feature introduced in Xorg
+release 7.1. Using the Composite Overlay Window is the preferred
+method for performing OpenGL-based compositing. Use OS-level events to efficiently notify X when a client has
+performed direct rendering to a window that needs to be composited.
+This will significantly improve performance and interactivity when
+using GLX applications with a composite manager running. It will
+also affect applications using GLX when rotation is enabled. This
+option is currently incompatible with SLI and Multi-GPU modes and
+will be disabled if either are used. Enabled by default. Forces the initialization of the X server with the exact timings
+specified in the ModeLine. Default: false (for DVI devices, the X
+server initializes with the closest mode in the EDID list). Enables various unsupported features, such as support for GPU
+clock manipulation in the NV-CONTROL X extension. This option
+accepts a bit mask of features to enable. When "1" (Bit 0) is set in the "Coolbits" option value, the
+nvidia-settings utility will contain a page labeled "Clock
+Frequencies" through which clock settings can be manipulated.
+"Coolbits" is only available on GeForce FX, Quadro FX and newer
+desktop GPUs. On GeForce FX and newer mobile GPUs, limited clock
+manipulation support is available when "1" is set in the "Coolbits"
+option value: clocks can be lowered relative to the default
+settings; overclocking is not supported due to the thermal
+constraints of notebook designs. WARNING: this may cause system damage and void warranties. This
+utility can run your computer system out of the manufacturer's
+design specifications, including, but not limited to: higher system
+voltages, above normal temperatures, excessive frequencies, and
+changes to BIOS that may corrupt the BIOS. Your computer's
+operating system may hang and result in data loss or corrupted
+images. Depending on the manufacturer of your computer system, the
+computer system, hardware and software warranties may be voided,
+and you may not receive any further manufacturer support. NVIDIA
+does not provide customer service support for the Coolbits option.
+It is for these reasons that absolutely no warranty or guarantee is
+either express or implied. Before enabling and using, you should
+determine the suitability of the utility for your intended use, and
+you shall assume all responsibility in connection therewith. When "2" (Bit 1) is set in the "Coolbits" option value, the
+NVIDIA driver will attempt to initialize SLI when using GPUs with
+different amounts of video memory. The default for this option is 0 (unsupported features are
+disabled). This option controls the configuration of Multi-GPU rendering in
+supported configurations. This option controls the configuration of SLI rendering in
+supported configurations. Enable or disable the use of triple buffering. If this option is
+enabled, OpenGL windows that sync to vblank and are double-buffered
+will be given a third buffer. This decreases the time an
+application stalls while waiting for vblank events, but increases
+latency slightly (delay between user input and displayed
+result). This option specifies the Dots Per Inch for the X screen; for
+example: will set the horizontal DPI to 75 and the vertical DPI to 85. By
+default, the X driver will compute the DPI of the X screen from the
+EDID of any connected display devices. See Appendix E, Dots Per
+Inch for details. Default: string is NULL (disabled). By default, the NVIDIA X driver computes the DPI of an X screen
+based on the physical size of the display device, as reported in
+the EDID, and the size in pixels of the first mode to be used on
+the display device. If multiple display devices are used by the X
+screen, then the NVIDIA X screen will choose which display device
+to use. This option can be used to specify which display device to
+use. The string argument can be a display device name, such as: or the argument can be "FALSE" to disable use of EDID-based DPI
+calculations: See Appendix E, Dots Per
+Inch for details. Default: string is NULL (the driver
+computes the DPI from the EDID of a display device and selects the
+display device). By default on X.Org 6.9 or newer X servers, the NVIDIA X driver
+recomputes the size in millimeters of the X screen whenever the
+size in pixels of the X screen is changed using XRandR, such that
+the DPI remains constant. This behavior can be disabled (which means that the size in
+millimeters will not change when the size in pixels of the X screen
+changes) by setting the "ConstantDPI" option to "FALSE"; e.g., ConstantDPI defaults to True. On X servers older than X.Org 6.9, the NVIDIA X driver cannot
+change the size in millimeters of the X screen. Therefore the DPI
+of the X screen will change when XRandR changes the size in pixels
+of the X screen. The driver will behave as if ConstantDPI was
+forced to FALSE. This option forces the X driver to use the EDID specified in a
+file rather than the display's EDID. You may specify a semicolon
+separated list of display names and filename pairs. The display
+name is any of "CRT-0", "CRT-1", "DFP-0", "DFP-1", "TV-0", "TV-1",
+or one of the generic names "CRT", "DFP", "TV", which apply the
+EDID to all devices of the specified type. The file contains a raw
+EDID (e.g., a file generated by nvidia-settings). For example: will assign the EDID from the file /tmp/edid1.bin to the display
+device CRT-0, and the EDID from the file /tmp/edid2.bin to the
+display device DFP-0. Note that a display device name must always
+be specified even if only one EDID is specified. Caution: Specifying an EDID that doesn't exactly match your
+display may damage your hardware, as it allows the driver to
+specify timings beyond the capabilities of your display. Use with
+care. This option provides fine-grained control over each stage of the
+mode validation pipeline, disabling individual mode validation
+checks. This option should only very rarely be used. The option string is a semicolon-separated list of
+comma-separated lists of mode validation arguments. Each list of
+mode validation arguments can optionally be prepended with a
+display device name. Possible arguments: "AllowNon60HzDFPModes": some lower quality TMDS encoders are
+only rated to drive DFPs at 60Hz; the driver will determine when
+only 60Hz DFP modes are allowed. This argument disables this stage
+of the mode validation pipeline. "NoMaxPClkCheck": each mode has a pixel clock; this pixel clock
+is validated against the maximum pixel clock of the hardware (for a
+DFP, this is the maximum pixel clock of the TMDS encoder, for a
+CRT, this is the maximum pixel clock of the DAC). This argument
+disables the maximum pixel clock checking stage of the mode
+validation pipeline. "NoEdidMaxPClkCheck": a display device's EDID can specify the
+maximum pixel clock that the display device supports; a mode's
+pixel clock is validated against this pixel clock maximum. This
+argument disables this stage of the mode validation pipeline. "AllowInterlacedModes": interlaced modes are not supported on
+all NVIDIA GPUs; the driver will discard interlaced modes on GPUs
+where interlaced modes are not supported; this argument disables
+this stage of the mode validation pipeline. "NoMaxSizeCheck": each NVIDIA GPU has a maximum resolution that
+it can drive; this argument disables this stage of the mode
+validation pipeline. "NoHorizSyncCheck": a mode's horizontal sync is validated
+against the range of valid horizontal sync values; this argument
+disables this stage of the mode validation pipeline. "NoVertRefreshCheck": a mode's vertical refresh rate is
+validated against the range of valid vertical refresh rate values;
+this argument disables this stage of the mode validation
+pipeline. "NoWidthAlignmentCheck": the alignment of a mode's visible width
+is validated against the capabilities of the GPU; normally, a
+mode's visible width must be a multiple of 8. This argument
+disables this stage of the mode validation pipeline. "NoDFPNativeResolutionCheck": when validating for a DFP, a
+mode's size is validated against the native resolution of the DFP;
+this argument disables this stage of the mode validation
+pipeline. "NoVirtualSizeCheck": if the X configuration file requests a
+specific virtual screen size, a mode cannot be larger than that
+virtual size; this argument disables this stage of the mode
+validation pipeline. "NoVesaModes": when constructing the mode pool for a display
+device, the X driver uses a built-in list of VESA modes as one of
+the mode sources; this argument disables use of these built-in VESA
+modes. "NoEdidModes": when constructing the mode pool for a display
+device, the X driver uses any modes listed in the display device's
+EDID as one of the mode sources; this argument disables use of
+EDID-specified modes. "NoXServerModes": when constructing the mode pool for a display
+device, the X driver uses the built-in modes provided by the core
+XFree86/Xorg X server as one of the mode sources; this argument
+disables use of these modes. Note that this argument does not
+disable custom ModeLines specified in the X config file; see the
+"NoCustomModes" argument for that. "NoCustomModes": when constructing the mode pool for a display
+device, the X driver uses custom ModeLines specified in the X
+config file (through the "Mode" or "ModeLine" entries in the
+Monitor Section) as one of the mode sources; this argument disables
+use of these modes. "NoPredefinedModes": when constructing the mode pool for a
+display device, the X driver uses additional modes predefined by
+the NVIDIA X driver; this argument disables use of these modes. "NoUserModes": additional modes can be added to the mode pool
+dynamically, using the NV-CONTROL X extension; this argument
+prohibits user-specified modes via the NV-CONTROL X extension. "NoExtendedGpuCapabilitiesCheck": allow mode timings that may
+exceed the GPU's extended capability checks. "ObeyEdidContradictions": an EDID may contradict itself by
+listing a mode as supported, but the mode may exceed an
+EDID-specified valid frequency range (HorizSync, VertRefresh, or
+maximum pixel clock). Normally, the NVIDIA X driver prints a
+warning in this scenario, but does not invalidate an EDID-specified
+mode just because it exceeds an EDID-specified valid frequency
+range. However, the "ObeyEdidContradictions" argument instructs the
+NVIDIA X driver to invalidate these modes. "NoTotalSizeCheck": allow modes in which the individual visible
+or sync pulse timings exceed the total raster size. "DoubleScanPriority": on GPUs older than G80, doublescan modes
+are sorted before non-doublescan modes of the same resolution for
+purposes of mode pool sorting; but on G80 and later GPUs,
+doublescan modes are sorted after non-doublescan modes of the same
+resolution. This token inverts that priority (i.e., doublescan
+modes will be sorted after on pre-G80 GPUs, and sorted before on
+G80 and later GPUs). "NoDualLinkDVICheck": for mode timings used on dual link DVI
+DFPs, the driver must perform additional checks to ensure that the
+correct pixels are sent on the correct link. For some of these
+checks, the driver will invalidate the mode timings; for other
+checks, the driver will implicitly modify the mode timings to meet
+the GPU's dual link DVI requirements. This token disables this dual
+link DVI checking. Examples: disable the maximum pixel clock check when validating modes on
+all display devices. do not use EDID modes and do not perform the maximum pixel clock
+check on CRT-0, and do not use VESA modes on DFP-0. This option causes the X driver to print verbose details about
+mode validation to the X log file. Note that this option is applied
+globally: setting this option to TRUE will enable verbose mode
+validation logging for all NVIDIA X screens in the X server. Enables the use of system events in some cases when the X driver
+is waiting for the hardware. The X driver can briefly spin through
+a tight loop when waiting for the hardware. With this option the X
+driver instead sets an event handler and waits for the hardware
+through the poll()
+system call. Default: the use of the events is disabled. This option requests particular properties for all or a subset
+of the connected flat panels. The option string is a semicolon-separated list of
+comma-separated property=value pairs. Each list of property=value
+pairs can optionally be prepended with a flat panel name. Recognized properties: "Scaling": controls the flat panel scaling mode; possible values
+are: 'Default' (the driver will use whichever scaling state is
+current), 'Native' (the driver will use the flat panel's scaler, if
+possible), 'Scaled' (the driver will use the NVIDIA GPU's scaler,
+if possible), 'Centered' (the driver will center the image, if
+possible), and 'aspect-scaled' (the X driver will scale with the
+NVIDIA GPU's scaler, but keep the aspect ratio correct). "Dithering": controls the flat panel dithering mode; possible
+values are: 'Default' (the driver will decide when to dither),
+'Enabled' (the driver will always dither, if possible), and
+'Disabled' (the driver will never dither). Examples: set the flat panel scaling mode to centered on all flat
+panels. set DFP-0's scaling mode to centered, set DFP-1's scaling mode
+to scaled and its dithering mode to enabled. When the NVIDIA X driver initializes, it probes all GPUs in the
+system, even if no X screens are configured on them. This is done
+so that the X driver can report information about all the system's
+GPUs through the NV-CONTROL X extension. This option can be set to
+FALSE to disable this behavior, such that only GPUs with X screens
+configured on them will be probed. Default: all GPUs in the system
+are probed. Enable or disable support for dynamically configuring TwinView
+on this X screen. When DynamicTwinView is enabled (the default),
+the refresh rate of a mode (reported through XF86VidMode or XRandR)
+does not correctly report the refresh rate, but instead is a unique
+number such that each MetaMode has a different value. This is to
+guarantee that MetaModes can be uniquely identified by XRandR. When DynamicTwinView is disabled, the refresh rate reported
+through XRandR will be accurate, but NV-CONTROL clients such as
+nvidia-settings will not be able to dynamically manipulate the X
+screen's MetaModes. TwinView can still be configured from the X
+config file when DynamicTwinView is disabled. Default: DynamicTwinView is enabled. When the X server starts, a mode pool is created per display
+device, containing all the mode timings that the NVIDIA X driver
+determined to be valid for the display device. However, the only
+MetaModes that are made available to the X server are the ones
+explicitly requested in the X configuration file. It is convenient for fullscreen applications to be able to
+change between the modes in the mode pool, even if a given target
+mode was not explicitly requested in the X configuration file. To facilitate this, the NVIDIA X driver will, if only one
+display device is in use when the X server starts, implicitly add
+MetaModes for all modes in the display device's mode pool. This
+makes all the modes in the mode pool available to full screen
+applications that use the XF86VidMode or XRandR X extensions. To prevent this behavior, and only add MetaModes that are
+explicitly requested in the X configuration file, set this option
+to FALSE. Default: IncludeImplicitMetaModes is enabled. Some graphics cards have more video memory than can be mapped at
+once by the CPU (generally only 256 MB of video memory can be
+CPU-mapped). On graphics cards based on G80 and higher with such a
+memory configuration, this option allows the driver to place more
+pixmaps in video memory which will improve hardware rendering
+performance but will slow down software rendering. On some systems,
+up to 768 megabytes of virtual address space will be reserved in
+the X server for indirect pixmap access. This virtual memory does
+not consume any physical resources. Default: on (indirect pixmaps will be used, when available). Normally, VBlank interrupts are generated on every vertical
+refresh of every display device connected to the GPU(s) installed
+in a given system. This experimental option enables on-demand
+VBlank control, allowing the driver to enable VBlank interrupt
+generation only when it is required. This can help conserve
+power. Default: off (on-demand VBlank control is disabled). This option controls how much video memory is reserved for
+pixmap allocations. When the option is specified, NOTE: This option is deprecated in favor of the
+PixmapCacheRoundSizeKB nvidia-settings attribute and will be
+removed in a future driver release. Example: Default: off (no memory is reserved specifically for
+pixmaps). This option controls whether applications can use the MIT-SHM X
+extension to create pixmaps whose contents are shared between the X
+server and the client. These pixmaps prevent the NVIDIA driver from
+performing a number of optimizations and degrade performance in
+many circumstances. Disabling this option disables only shared memory pixmaps.
+Applications can still use the MIT-SHM extension to transfer data
+to the X server through shared memory using XShmPutImage. Default: off (shared memory pixmaps are not allowed). This option controls whether the NVIDIA X Driver initializes
+newly created redirected windows using the contents of their parent
+window if the X server doesn't do it. Leaving redirected windows
+uninitialized may cause new windows to flash with black or random
+colors when some compositing managers are running. This option will have no effect on X servers that already
+initialize redirected window contents. In most distributions, the X
+server is patched to skip that initialization. In this case, it is
+recommended to leave this option on for a better user
+experience. Default: on (redirected windows are initialized). By default, the NVIDIA GLX implementation will not expose GLX
+protocol for GL commands if the protocol is not considered
+complete. Protocol could be considered incomplete for a number of
+reasons. The implementation could still be under development and
+contain known bugs, or the protocol specification itself could be
+under development or going through review. If users would like to
+test the server-side portion of such protocol when using indirect
+rendering, they can enable this option. If any X screen enables
+this option, it will enable protocol on all screens in the
+server. When an NVIDIA GLX client is used, the related environment
+variable __GL_ALLOW_UNOFFICIAL_PROTOCOL
+will need to be set as well to enable support in the client. When this option is enabled, all displays in the current
+MetaMode will pan as the pointer is moved. If disabled, only the
+displays whose panning domain contains the pointer (at its new
+location) are panned. Default: enabled (all displays are panned when the pointer is
+moved). The NVIDIA resource manager recognizes several low-level
-configuration parameters that can be set using the sysctl driver
-interface before the X
-server is started. Normally you should not need to modify any of
-these parameters, but it is sometimes necessary or desirable to do
-so. To view the current settings of these parameters, you need to
-issue this sysctl command ( To change any of the parameters, you need to pass the complete
-name of the OID followed by '=' and the new value, e.g.: It is possible to automate setting these parameters by adding
-them to the The following parameters are recognized by Resource Manager Parameters We normally detect memory type on TNT cards by scanning the
-embedded BIOS. Unfortunately, we've seen some cases where a TNT
-card has been flashed with the wrong BIOS. For example, an SDRAM
-based TNT has been flashed with an SGRAM BIOS, and therefore claims
-to be an SGRAM TNT. We've therefore provided an override here. Make
-sure to set the value toe the type of memory used on your card. Note that we can only do so much here. There are border cases
-where even this fails. For example, if 2 TNT cards are in the same
-system, one SGRAM, one SDRAM. This option is disabled by default, see below for information on
-how to enable it. We've had problems with some Via chipsets in 4x mode, we need
-force them back down to 2x mode. If you'd like to experiment with
-retaining 4x mode, you may try setting this value to 1 If that
-hangs the system, you're stuck with 2x mode; there's nothing we can
-do about it. Some ALi chipsets (ALi1541, ALi1647) are known to cause severe
-system stability problems with AGP enabled. To avoid lockups, we
-disable AGP on systems with these chipsets by default. It appears
-that updating the system BIOS and using recent versions of the
-kernel AGP Gart driver can make such systems much more stable. If
-you own a system with one of the aforementioned chipsets and had it
-working reasonably well previously, or if you want to experiment
-with BIOS and AGPGART revisions, you can re-enable AGP support by
-setting this option to 1. This options controls which AGP GART driver is used when no
-explicit request is made to change the default (X server). Note that the NVIDIA internal AGP GART driver will not be used
-if AGPGART was either statically linked into your kernel or built
-as a kernel module and loaded before the NVIDIA kernel module. Normally, the driver will compare speed modes of the chipset and
-the card, picking the highest common rate. This key forces a
-maximum limit, to limit the driver to lower speeds. The driver will
-not attempt a speed beyond what the chipset and card claim they are
-capable of. Make sure you really know what you're doing before you enable
-this override. By default, AGP drivers will enable the fastest AGP
-rate your card and motherboard chipset are capable of. Then, in
-some cases, our driver will force this rate down to work around
-bugs in both our chipsets, and motherboard chipsets. Using this
-variable will override our bug fixes. This may be desirable in some
-cases, but not most. This is completely
-unsupported! This option expects a bitmask (7 = 1|2|3|4, 3=1|2, etc.) This option is disabled by default, see below for information on
-how to enable it. For stability reasons, the driver will not use Side Band
-Addressing even if both the host chipset and the AGP card support
-it. You may override this behavior with the following registry key.
-This is completely
-unsupported! Similar to Side Band Addressing, Fast Writes are disabled by
-default. If you wish to enable them on systems that support them,
-you can do so with this registry key. Note that this may render
-your system unstable with many AGP chipsets. This is completely unsupported! This release supports GLX 1.4. Additionally, the following GLX extensions are supported on
+appropriate GPUs: GLX_EXT_visual_info GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_ARB_get_proc_address GLX_SGI_video_sync GLX_SGI_swap_control GLX_ARB_multisample GLX_NV_float_buffer GLX_ARB_fbconfig_float GLX_NV_swap_group GLX_NV_video_out GLX_EXT_texture_from_pixmap For a description of these extensions, see the OpenGL extension
+registry at http://www.opengl.org/registry/ Some of the above extensions exist as part of core GLX 1.4
+functionality, however, they are also exported as extensions for
+backwards compatibility. This documentation describes the capabilities of the NVIDA VDPAU
-implementation. Hardware performance may vary significantly between
-cards. No guarantees are made, nor implied, that any particular
-combination of system configuration, GPU configuration, VDPAU
-feature set, VDPAU API usage, application, video stream, etc., will
-be able to decode streams at any particular frame rate. This documentation describes the capabilities of the NVIDIA
+VDPAU implementation. Hardware performance may vary significantly
+between cards. No guarantees are made, nor implied, that any
+particular combination of system configuration, GPU configuration,
+VDPAU feature set, VDPAU API usage, application, video stream,
+etc., will be able to decode streams at any particular frame
+rate.NVIDIA GeForce GPUs
+
-
Software Element
-Min Requirement
+NVIDIA GPU product
+Device PCI ID
-
Kernel
-FreeBSD 5-STABLE (5.3 or later)
+GeForce 6800 Ultra
+0x0040
-
+XFree86/X.Org
-4.2/6.7.0
+GeForce 6800
+0x0041
+
+
+GeForce 6800 LE
+0x0042
+
+
+GeForce 6800 XE
+0x0043
+
+
+GeForce 6800 XT
+0x0044
+
+
+GeForce 6800 GT
+0x0045
+
+
+GeForce 6800 GT
+0x0046
+
+
+GeForce 6800 GS
+0x0047
+
+
+GeForce 6800 XT
+0x0048
+
+
+GeForce 7800 GTX
+0x0090
+
+
+GeForce 7800 GTX
+0x0091
+
+
+GeForce 7800 GT
+0x0092
+
+
+GeForce 7800 GS
+0x0093
+
+
+GeForce 7800 SLI
+0x0095
+
+
+GeForce Go 7800
+0x0098
+
+
+GeForce Go 7800 GTX
+0x0099
+
+
+GeForce 6800 GS
+0x00C0
+
+
+GeForce 6800
+0x00C1
+
+
+GeForce 6800 LE
+0x00C2
+
+
+GeForce 6800 XT
+0x00C3
+
+
+GeForce Go 6800
+0x00C8
+
+
+GeForce Go 6800 Ultra
+0x00C9
+
+
+GeForce 6600 GT
+0x00F1
+
+
+GeForce 6600
+0x00F2
+
+
+GeForce 6200
+0x00F3
+
+
+GeForce 6600 LE
+0x00F4
+
+
+GeForce 7800 GS
+0x00F5
+
+
+GeForce 6800 GS
+0x00F6
+
+
+GeForce 6800 Ultra
+0x00F9
+
+
+GeForce 6600 GT
+0x0140
+
+
+GeForce 6600
+0x0141
+
+
+GeForce 6600 LE
+0x0142
+
+
+GeForce 6600 VE
+0x0143
+
+
+GeForce Go 6600
+0x0144
+
+
+GeForce 6610 XL
+0x0145
+
+
+GeForce Go 6600 TE/6200 TE
+0x0146
+
+
+GeForce 6700 XL
+0x0147
+
+
+GeForce Go 6600
+0x0148
+
+
+GeForce Go 6600 GT
+0x0149
+
+
+GeForce 6200
+0x014F
+
+
+GeForce 6500
+0x0160
+
+
+GeForce 6200 TurboCache(TM)
+0x0161
+
+
+GeForce 6200SE TurboCache(TM)
+0x0162
+
+
+GeForce 6200 LE
+0x0163
+
+
+GeForce Go 6200
+0x0164
+
+
+GeForce Go 6400
+0x0166
+
+
+GeForce Go 6200
+0x0167
+
+
+GeForce Go 6400
+0x0168
+
+
+GeForce 6250
+0x0169
+
+
+GeForce 7100 GS
+0x016A
+
+
+GeForce 8800 GTX
+0x0191
+
+
+GeForce 8800 GTS
+0x0193
+
+
+GeForce 8800 Ultra
+0x0194
+
+
+Tesla C870
+0x0197
+
+
+GeForce 7350 LE
+0x01D0
+
+
+GeForce 7300 LE
+0x01D1
+
+
+GeForce 7300 SE/7200 GS
+0x01D3
+
+
+GeForce Go 7200
+0x01D6
+
+
+GeForce Go 7300
+0x01D7
+
+
+GeForce Go 7400
+0x01D8
+
+
+GeForce 7500 LE
+0x01DD
+
+
+GeForce 7300 GS
+0x01DF
+
+
+GeForce 6200
+0x0221
+
+
+GeForce 6200 A-LE
+0x0222
+
+
+GeForce 6150
+0x0240
+
+
+GeForce 6150 LE
+0x0241
+
+
+GeForce 6100
+0x0242
+
+
+GeForce Go 6150
+0x0244
+
+
+GeForce Go 6100
+0x0247
+
+
+GeForce 7900 GTX
+0x0290
+
+
+GeForce 7900 GT/GTO
+0x0291
+
+
+GeForce 7900 GS
+0x0292
+
+
+GeForce 7950 GX2
+0x0293
+
+
+GeForce 7950 GX2
+0x0294
+
+
+GeForce 7950 GT
+0x0295
+
+
+GeForce Go 7950 GTX
+0x0297
+
+
+GeForce Go 7900 GS
+0x0298
+
+
+GeForce 7600 GT
+0x02E0
+
+
+GeForce 7600 GS
+0x02E1
+
+
+GeForce 7300 GT
+0x02E2
+
+
+GeForce 7900 GS
+0x02E3
+
+
+GeForce 7950 GT
+0x02E4
+
+
+GeForce 7650 GS
+0x0390
+
+
+GeForce 7600 GT
+0x0391
+
+
+GeForce 7600 GS
+0x0392
+
+
+GeForce 7300 GT
+0x0393
+
+
+GeForce 7600 LE
+0x0394
+
+
+GeForce 7300 GT
+0x0395
+
+
+GeForce Go 7700
+0x0397
+
+
+GeForce Go 7600
+0x0398
+
+
+GeForce Go 7600 GT
+0x0399
+
+
+GeForce 6150SE nForce 430
+0x03D0
+
+
+GeForce 6100 nForce 405
+0x03D1
+
+
+GeForce 6100 nForce 400
+0x03D2
+
+
+GeForce 6100 nForce 420
+0x03D5
+
+
+GeForce 8600 GTS
+0x0400
+
+
+GeForce 8600 GT
+0x0401
+
+
+GeForce 8600 GT
+0x0402
+
+
+GeForce 8600 GS
+0x0403
+
+
+GeForce 8400 GS
+0x0404
+
+
+GeForce 9500M GS
+0x0405
+
+
+GeForce 8600M GT
+0x0407
+
+
+GeForce 9650M GS
+0x0408
+
+
+GeForce 8700M GT
+0x0409
+
+
+GeForce 8400 SE
+0x0420
+
+
+GeForce 8500 GT
+0x0421
+
+
+GeForce 8400 GS
+0x0422
+
+
+GeForce 8300 GS
+0x0423
+
+
+GeForce 8400 GS
+0x0424
+
+
+GeForce 8600M GS
+0x0425
+
+
+GeForce 8400M GT
+0x0426
+
+
+GeForce 8400M GS
+0x0427
+
+
+GeForce 8400M G
+0x0428
+
+
+GeForce 9400 GT
+0x042C
+
+
+GeForce 9300M G
+0x042E
+
+
+GeForce 7150M / nForce 630M
+0x0531
+
+
+GeForce 7000M / nForce 610M
+0x0533
+
+
+GeForce 7050 PV / nForce 630a
+0x053A
+
+
+GeForce 7050 PV / nForce 630a
+0x053B
+
+
+GeForce 7025 / nForce 630a
+0x053E
+
+
+GeForce GTX 295
+0x05E0
+
+
+GeForce GTX 280
+0x05E1
+
+
+GeForce GTX 260
+0x05E2
+
+
+GeForce GTX 285
+0x05E3
+
+
+GeForce GTX 275
+0x05E6
+
+
+GeForce GTX 295
+0x05EB
+
+
+GeForce 8800 GTS 512
+0x0600
+
+
+GeForce 9800 GT
+0x0601
+
+
+GeForce 8800 GT
+0x0602
+
+
+GeForce 9800 GX2
+0x0604
+
+
+GeForce 9800 GT
+0x0605
+
+
+GeForce 8800 GS
+0x0606
+
+
+GeForce 9800M GTX
+0x0608
+
+
+GeForce 8800M GTS
+0x0609
+
+
+GeForce GTX 280M
+0x060A
+
+
+GeForce 9800M GT
+0x060B
+
+
+GeForce 8800M GTX
+0x060C
+
+
+GeForce 8800 GS
+0x060D
+
+
+GeForce 9600 GSO
+0x0610
+
+
+GeForce 8800 GT
+0x0611
+
+
+GeForce 9800 GTX/9800 GTX+
+0x0612
+
+
+GeForce 9800 GTX+
+0x0613
+
+
+GeForce 9800 GT
+0x0614
+
+
+GeForce GTS 250
+0x0615
+
+
+GeForce 9800M GTX
+0x0617
+
+
+GeForce GTX 260M
+0x0618
+
+
+GeForce 9600 GT
+0x0622
+
+
+GeForce 9600 GS
+0x0623
+
+
+GeForce 9600 GSO 512
+0x0625
+
+
+GeForce GT 130
+0x0626
+
+
+GeForce GT 140
+0x0627
+
+
+GeForce 9800M GTS
+0x0628
+
+
+GeForce 9700M GTS
+0x062A
+
+
+GeForce 9800M GS
+0x062B
+
+
+GeForce 9800M GTS
+0x062C
+
+
+GeForce 9500 GT
+0x0640
+
+
+GeForce 9400 GT
+0x0641
+
+
+GeForce 9500 GT
+0x0643
+
+
+GeForce 9500 GS
+0x0644
+
+
+GeForce GT 120
+0x0646
+
+
+GeForce 9600M GT
+0x0647
+
+
+GeForce 9600M GS
+0x0648
+
+
+GeForce 9600M GT
+0x0649
+
+
+GeForce 9700M GT
+0x064A
+
+
+GeForce 9500M G
+0x064B
+
+
+GeForce 9650M GT
+0x064C
+
+
+GeForce GT 130M
+0x0652
+
+
+GeForce 9650 S
+0x0656
+
+
+GeForce 9300 GE
+0x06E0
+
+
+GeForce 9300 GS
+0x06E1
+
+
+GeForce 8400 GS
+0x06E4
+
+
+GeForce 9300M GS
+0x06E5
+
+
+GeForce G100
+0x06E6
+
+
+GeForce 9200M GS
+0x06E8
+
+
+GeForce 9300M GS
+0x06E9
+
+
+GeForce G 103M
+0x06EF
+
+
+GeForce 7150 / nForce 630i
+0x07E0
+
+
+GeForce 7100 / nForce 630i
+0x07E1
+
+
+GeForce 7050 / nForce 610i
+0x07E3
+
+
+GeForce 9100M G
+0x0844
+
+
+GeForce 8200M G
+0x0845
+
+
+GeForce 9100
+0x0847
+
+
+GeForce 8300
+0x0848
+
+
+GeForce 8200
+0x0849
+
+
+nForce 730a
+0x084A
+
+
+GeForce 9200
+0x084B
+
+
+nForce 980a/780a SLI
+0x084C
+
+
+nForce 750a SLI
+0x084D
+
+
+GeForce 8100 / nForce 720a
+0x084F
+
+
+GeForce 9400M G
+0x0862
+
+
+GeForce 9400M
+0x0863
+
+
+GeForce 9300 / nForce 730i
+0x086C
+
+
+GeForce GT 230M
+0x0A2A
+
+
+GeForce GT 240M
+0x0A34
+
+
+GeForce G210M
+0x0A74
+
+
+GeForce GTS 260M
+0x0CA8
+
+
+
+GeForce GTS 250M
+0x0CA9
+NVIDIA Quadro GPUs
+
+
+
+
+
+
+NVIDIA GPU product
+Device PCI ID
+
+
+Quadro FX 4000
+0x004E
+
+
+Quadro FX 4500
+0x009D
+
+
+Quadro FX Go1400
+0x00CC
+
+
+Quadro FX 3450/4000 SDI
+0x00CD
+
+
+Quadro FX 1400
+0x00CE
+
+
+Quadro FX 3400/Quadro FX 4000
+0x00F8
+
+
+Quadro NVS 440
+0x014A
+
+
+Quadro FX 540M
+0x014C
+
+
+Quadro FX 550
+0x014D
+
+
+Quadro FX 540
+0x014E
+
+
+Quadro NVS 285
+0x0165
+
+
+Quadro FX 5600
+0x019D
+
+
+Quadro FX 4600
+0x019E
+
+
+Quadro NVS 110M
+0x01DA
+
+
+Quadro NVS 120M
+0x01DB
+
+
+Quadro FX 350M
+0x01DC
+
+
+Quadro FX 350
+0x01DE
+
+
+Quadro NVS 210S / GeForce 6150LE
+0x0245
+
+
+Quadro NVS 510M
+0x0299
+
+
+Quadro FX 2500M
+0x029A
+
+
+Quadro FX 1500M
+0x029B
+
+
+Quadro FX 5500
+0x029C
+
+
+Quadro FX 3500
+0x029D
+
+
+Quadro FX 1500
+0x029E
+
+
+Quadro FX 4500 X2
+0x029F
+
+
+Quadro FX 560
+0x039E
+
+
+Quadro FX 370
+0x040A
+
+
+Quadro NVS 320M
+0x040B
+
+
+Quadro FX 570M
+0x040C
+
+
+Quadro FX 1600M
+0x040D
+
+
+Quadro FX 570
+0x040E
+
+
+Quadro FX 1700
+0x040F
+
+
+Quadro NVS 140M
+0x0429
+
+
+Quadro NVS 130M
+0x042A
+
+
+Quadro NVS 135M
+0x042B
+
+
+Quadro FX 360M
+0x042D
+
+
+Quadro NVS 290
+0x042F
+
+
+Quadro CX
+0x05F9
+
+
+Quadro FX 5800
+0x05FD
+
+
+Quadro FX 4800
+0x05FE
+
+
+Quadro FX 3800
+0x05FF
+
+
+Quadro FX 3700
+0x061A
+
+
+Quadro FX 3600M
+0x061C
+
+
+Quadro FX 3700M
+0x061E
+
+
+Quadro FX 1800
+0x0638
+
+
+Quadro FX 2700M
+0x063A
+
+
+Quadro FX 380
+0x0658
+
+
+Quadro FX 580
+0x0659
+
+
+Quadro FX 770M
+0x065C
+
+
+Quadro NVS 150M
+0x06EA
+
+
+Quadro NVS 160M
+0x06EB
+
+
+Quadro NVS 420
+0x06F8
+
+
+Quadro FX 370 LP
+0x06F9
+
+
+Quadro NVS 450
+0x06FA
+
+
+Quadro NVS 295
+0x06FD
+
+
+
+Quadro FX 470
+0x087A
+
+
+
+
+
+
+NVIDIA GPU product
+Device PCI ID
+
+
+GeForce PCX 5750
+0x00FA
+
+
+GeForce PCX 5900
+0x00FB
+
+
+Quadro FX 330/GeForce PCX 5300
+0x00FC
+
+
+Quadro FX 330/Quadro NVS 280 PCI-E
+0x00FD
+
+
+Quadro FX 1300
+0x00FE
+
+
+GeForce FX 5800 Ultra
+0x0301
+
+
+GeForce FX 5800
+0x0302
+
+
+Quadro FX 2000
+0x0308
+
+
+Quadro FX 1000
+0x0309
+
+
+GeForce FX 5600 Ultra
+0x0311
+
+
+GeForce FX 5600
+0x0312
+
+
+GeForce FX 5600XT
+0x0314
+
+
+GeForce FX Go5600
+0x031A
+
+
+GeForce FX Go5650
+0x031B
+
+
+Quadro FX Go700
+0x031C
+
+
+GeForce FX 5200
+0x0320
+
+
+GeForce FX 5200 Ultra
+0x0321
+
+
+GeForce FX 5200
+0x0322
+
+
+GeForce FX 5200LE
+0x0323
+
+
+GeForce FX Go5200
+0x0324
+
+
+GeForce FX Go5250
+0x0325
+
+
+GeForce FX 5500
+0x0326
+
+
+GeForce FX 5100
+0x0327
+
+
+GeForce FX Go5200 32M/64M
+0x0328
+
+
+Quadro NVS 55/280 PCI
+0x032A
+
+
+Quadro FX 500/FX 600
+0x032B
+
+
+GeForce FX Go53xx
+0x032C
+
+
+GeForce FX Go5100
+0x032D
+
+
+GeForce FX 5900 Ultra
+0x0330
+
+
+GeForce FX 5900
+0x0331
+
+
+GeForce FX 5900XT
+0x0332
+
+
+GeForce FX 5950 Ultra
+0x0333
+
+
+GeForce FX 5900ZT
+0x0334
+
+
+Quadro FX 3000
+0x0338
+
+
+Quadro FX 700
+0x033F
+
+
+GeForce FX 5700 Ultra
+0x0341
+
+
+GeForce FX 5700
+0x0342
+
+
+GeForce FX 5700LE
+0x0343
+
+
+GeForce FX 5700VE
+0x0344
+
+
+GeForce FX Go5700
+0x0347
+
+
+GeForce FX Go5700
+0x0348
+
+
+Quadro FX Go1000
+0x034C
+
+
+
+Quadro FX 1100
+0x034E
+
+
+
+
+
+
+NVIDIA GPU product
+Device PCI ID
+
+
+GeForce2 MX/MX 400
+0x0110
+
+
+GeForce2 MX 100/200
+0x0111
+
+
+GeForce2 Go
+0x0112
+
+
+Quadro2 MXR/EX/Go
+0x0113
+
+
+GeForce4 MX 460
+0x0170
+
+
+GeForce4 MX 440
+0x0171
+
+
+GeForce4 MX 420
+0x0172
+
+
+GeForce4 MX 440-SE
+0x0173
+
+
+GeForce4 440 Go
+0x0174
+
+
+GeForce4 420 Go
+0x0175
+
+
+GeForce4 420 Go 32M
+0x0176
+
+
+GeForce4 460 Go
+0x0177
+
+
+Quadro4 550 XGL
+0x0178
+
+
+GeForce4 440 Go 64M
+0x0179
+
+
+Quadro NVS 400
+0x017A
+
+
+Quadro4 500 GoGL
+0x017C
+
+
+GeForce4 410 Go 16M
+0x017D
+
+
+GeForce4 MX 440 with AGP8X
+0x0181
+
+
+GeForce4 MX 440SE with AGP8X
+0x0182
+
+
+GeForce4 MX 420 with AGP8X
+0x0183
+
+
+GeForce4 MX 4000
+0x0185
+
+
+Quadro4 580 XGL
+0x0188
+
+
+Quadro NVS 280 SD
+0x018A
+
+
+Quadro4 380 XGL
+0x018B
+
+
+Quadro NVS 50 PCI
+0x018C
+
+
+GeForce2 Integrated GPU
+0x01A0
+
+
+GeForce4 MX Integrated GPU
+0x01F0
+
+
+GeForce3
+0x0200
+
+
+GeForce3 Ti 200
+0x0201
+
+
+GeForce3 Ti 500
+0x0202
+
+
+Quadro DCC
+0x0203
+
+
+GeForce4 Ti 4600
+0x0250
+
+
+GeForce4 Ti 4400
+0x0251
+
+
+GeForce4 Ti 4200
+0x0253
+
+
+Quadro4 900 XGL
+0x0258
+
+
+Quadro4 750 XGL
+0x0259
+
+
+Quadro4 700 XGL
+0x025B
+
+
+GeForce4 Ti 4800
+0x0280
+
+
+GeForce4 Ti 4200 with AGP8X
+0x0281
+
+
+GeForce4 Ti 4800 SE
+0x0282
+
+
+GeForce4 4200 Go
+0x0286
+
+
+Quadro4 980 XGL
+0x0288
+
+
+Quadro4 780 XGL
+0x0289
+
+
+
+Quadro4 700 GoGL
+0x028C
+
+
+
+
+
+NVIDIA GPU product
+Device PCI ID
+
+
+RIVA TNT
+0x0020
+
+
+RIVA TNT2/TNT2 Pro
+0x0028
+
+
+RIVA TNT2 Ultra
+0x0029
+
+
+Vanta/Vanta LT
+0x002C
+
+
+RIVA TNT2 Model 64/Model 64 Pro
+0x002D
+
+
+Aladdin TNT2
+0x00A0
+
+
+GeForce 256
+0x0100
+
+
+GeForce DDR
+0x0101
+
+
+Quadro
+0x0103
+
+
+GeForce2 GTS/GeForce2 Pro
+0x0150
+
+
+GeForce2 Ti
+0x0151
+
+
+GeForce2 Ultra
+0x0152
+
+
Quadro2 Pro
+0x0153
+
+Option "NvAGP" "integer"
+
-
Installed File
-Location
+Value
+Behavior
-
nvidia.ko
-/boot/modules
+0
+disable AGP
-
libGL.so
-/usr/lib/xorg
+1
+use NVIDIA internal AGP support, if possible
-
libGL.so.1
-/usr/lib/xorg
+2
+use AGPGART, if possible
-
-libnvidia-tls.so
-/usr/lib/xorg
-
-
-libnvidia-tls.so.1
-/usr/lib/xorg
-
-
+
+libnvidia-cfg.so
-/usr/lib/xorg
+3
+use any AGP support (try AGPGART, then NVIDIA AGP)
Option "NoLogo"
+"boolean"
Option "LogoPath"
+"string"
Option "RenderAccel"
+"boolean"
Option "NoRenderExtension"
+"boolean"
Option "UBB" "boolean"
Option "NoFlip"
+"boolean"
Option "Dac8Bit"
+"boolean"
Option "Overlay"
+"boolean"
Option "CIOverlay"
+"boolean"
Option "TransparentIndex"
+"integer"
Option "OverlayDefaultVisual"
+"boolean"
Option "EmulatedOverlaysTimerMs"
+"integer"
Option "EmulatedOverlaysThreshold"
+"boolean"
Option
+"EmulatedOverlaysThresholdValue" "integer"
Option "RandRRotation"
+"boolean"
Option "Rotate"
+"string"
Option "AllowDDCCI"
+"boolean"
NVCtrl.h
and functions in NVCtrlLib.h
in the nvidia-settings source code. Default: off
+(DDC/CI is disabled).<linux-bugs@nvidia.com>
.Option "SWCursor"
+"boolean"
Option "HWCursor"
+"boolean"
Option "CursorShadow"
+"boolean"
Option "CursorShadowAlpha"
+"integer"
Option "CursorShadowXOffset"
+"integer"
Option "CursorShadowYOffset"
+"integer"
Option "ConnectedMonitor"
+"string"
Option "UseDisplayDevice"
+"string"
+ Option "UseDisplayDevice" "DFP"
+
+
+ Option "UseDisplayDevice" "CRT-0, DFP-1"
+
+
+
+Option "UseEdidFreqs"
+"boolean"
Option "UseEDID"
+"boolean"
+ Option "UseEDID" "FALSE"
+
+
+ Option "UseEDIDFreqs" "FALSE"
+ Option "UseEDIDDpi" "FALSE"
+ Option "ModeValidation" "NoEdidModes"
+
+Option "UseInt10Module"
+"boolean"
Option "TwinView"
+"boolean"
Option "TwinViewOrientation"
+"string"
Option "SecondMonitorHorizSync"
+"range(s)"
Option "SecondMonitorVertRefresh"
+"range(s)"
Option "MetaModes"
+"string"
Option "NoTwinViewXineramaInfo"
+"boolean"
Option "TwinViewXineramaInfoOrder"
+"string"
+ "DFP"
+ "TV, DFP"
+ "DFP-1, DFP-0, TV, CRT"
+
+Option "TwinViewXineramaInfoOverride"
+"string"
+ "1600x1200+0+0, 1600x1200+1600+0"
+ "1024x768+0+0, 1024x768+1024+0, 1024x768+0+768, 1024x768+1024+768"
+
+
+Option "TVStandard"
+"string"
Option "TVOutFormat"
+"string"
Option "TVOverScan" "Decimal
+value in the range 0.0 to 1.0"
Option "Stereo"
+"integer"
+
+
-
+
+
libnvidia-cfg.so.1
-/usr/lib/xorg
+Value
+Equipment
-
libGLcore.so
-/usr/lib/xorg
+1
+DDC glasses. The sync signal is sent to the glasses via the DDC
+signal to the monitor. These usually involve a passthrough cable
+between the monitor and the graphics card. This mode is not
+available on G8xGL and higher GPUs.
-
libGLcore.so.1
-/usr/lib/xorg
+2
+"Blueline" glasses. These usually involve a passthrough cable
+between the monitor and graphics card. The glasses know which eye
+to display based on the length of a blue line visible at the bottom
+of the screen. When in this mode, the root window dimensions are
+one pixel shorter in the Y dimension than requested. This mode does
+not work with virtual root window sizes larger than the visible
+root window size (desktop panning). This mode is not available on
+G8xGL and higher GPUs.
-
nvidia_drv.so
-/usr/lib/xorg/modules/drivers
+3
+Onboard stereo support. This is usually only found on
+professional cards. The glasses connect via a DIN connector on the
+back of the graphics card.
-
libnvidia-wfb.so (optional)
-/usr/lib/xorg/modules
+4
+TwinView clone mode stereo (also known as "passive" stereo). On
+graphics cards that support TwinView, the left eye is displayed on
+the first display, and the right eye is displayed on the second
+display. This is normally used in conjunction with special
+projectors to produce 2 polarized images which are then viewed with
+polarized glasses. To use this stereo mode, you must also configure
+TwinView in clone mode with the same resolution, panning offset,
+and panning domains on each display.
-
libwfb.so
-/usr/lib/xorg/modules/drivers
+5
+Vertical interlaced stereo mode, for use with SeeReal Stereo
+Digital Flat Panels.
-
libglx.so
-/usr/lib/xorg/modules/extensions
+6
+Color interleaved stereo mode, for use with Sharp3D Stereo
+Digital Flat Panels.
-
libglx.so.1
-/usr/lib/xorg/modules/extensions
+7
+Horizontal interlaced stereo mode, for use with Arisawa,
+Hyundai, Zalman, Pavione, and Miracube Digital Flat Panels.
-
libvdpau.so
-/usr/lib/xorg
+8
+Checkerboard pattern stereo mode, for use with 3D DLP Display
+Devices.
-
+
+libvdpau.so.1
-/usr/lib/xorg
+9
+Inverse checkerboard pattern stereo mode, for use with 3D DLP
+Display Devices.
+
+Option "ForceStereoFlipping"
+"boolean"
+
+
-
+
+
libvdpau_trace.so
-/usr/lib/xorg
+Value
+Behavior
-
libvdpau_trace.so.1
-/usr/lib/xorg
+0
+Stereo flipping is not forced. The default behavior as
+indicated by the "Stereo" option is used.
-
+
+libvdpau_nvidia.so
-/usr/lib/xorg
+1
+Stereo flipping is forced. Stereo is running even if no stereo
+drawables are visible. The stereo mode depends on the value of the
+"Stereo" option.
Option "XineramaStereoFlipping"
+"boolean"
+
+
-
+
+
libvdpau_nvidia.so.1
-/usr/lib/xorg
+Value
+Behavior
-
nvidia-xconfig
-/usr/bin
+0
+Stereo flipping is enabled on one X screen at a time. Stereo is
+enabled on the first X screen having the stereo drawable.
-
+
+nvidia-xconfig.1
-/usr/man/man1
+1
+Stereo flipping in enabled on all X screens.
Option "NoBandWidthTest"
+"boolean"
Option "IgnoreDisplayDevices"
+"string"
+Option "IgnoreDisplayDevices" "DFP, TV"
+
+Option "MultisampleCompatibility"
+"boolean"
Option "NoPowerConnectorCheck"
+"boolean"
Option "XvmcUsesTextures"
+"boolean"
Option "AllowGLXWithComposite"
+"boolean"
Option "UseCompositeWrapper"
+"boolean"
Option "AddARGBGLXVisuals"
+"boolean"
Option "DisableGLXRootClipping"
+"boolean"
Option "DamageEvents"
+"boolean"
Option "ExactModeTimingsDVI"
+"boolean"
Option "Coolbits"
+"integer"
Option "MultiGPU"
+"string"
+
+
-
+
+
nvidia-settings
-/usr/bin
+Value
+Behavior
-
nvidia-settings.1
-/usr/man/man1
+0, no, off, false, Single
+Use only a single GPU when rendering
-
nvidia0
-/dev
+1, yes, on, true, Auto
+Enable Multi-GPU and allow the driver to automatically select
+the appropriate rendering mode.
-
nvidia1
-/dev
+AFR
+Enable Multi-GPU and use the Alternate Frame Rendering
+mode.
-
nvidia2
-/dev
+SFR
+Enable Multi-GPU and use the Split Frame Rendering mode.
-
+
+nvidia3
-/dev
+AA
+Enable Multi-GPU and use antialiasing. Use this in conjunction
+with full scene antialiasing to improve visual quality.
Option "SLI" "string"
+
-
+
+
nvidiactl
-/dev
+Value
+Behavior
-
libGL.so.180.29
-/compat/linux/usr/lib
+0, no, off, false, Single
+Use only a single GPU when rendering
-
libnvidia-tls.so.180.29
-/compat/linux/usr/lib
+1, yes, on, true, Auto
+Enable SLI and allow the driver to automatically select the
+appropriate rendering mode.
-
libGLcore.so.180.29
-/compat/linux/usr/lib
+AFR
+Enable SLI and use the Alternate Frame Rendering mode.
-
libvdpau.so.180.29
-/compat/linux/usr/lib
+SFR
+Enable SLI and use the Split Frame Rendering mode.
-
libvdpau_trace.so.180.29
-/compat/linux/usr/lib
+AA
+Enable SLI and use SLI Antialiasing. Use this in conjunction
+with full scene antialiasing to improve visual quality.
-
libvdpau_nvidia.so.180.29
-/compat/linux/usr/lib
+AFRofAA
+Enable SLI and use SLI Alternate Frame Rendering of
+Antialiasing mode. Use this in conjunction with full scene
+antialiasing to improve visual quality. This option is only valid
+for SLI configurations with 4 GPUs.
Option "TripleBuffer"
+"boolean"
Option "DPI" "string"
+ Option "DPI" "75 x 85"
+
+Option "UseEdidDpi"
+"string"
+ Option "UseEdidDpi" "DFP-0"
+
+
+ Option "UseEdidDpi" "FALSE"
+
+Option "ConstantDPI"
+"boolean"
+ Option "ConstantDPI" "FALSE"
+
+Option "CustomEDID"
+"string"
+ Option "CustomEDID" "CRT-0:/tmp/edid1.bin; DFP-0:/tmp/edid2.bin"
+
+Option "ModeValidation"
+"string"
+ "<dpy-0>: <tok>, <tok>; <dpy-1>: <tok>, <tok>, <tok>; ..."
+
+
+
+
+
+ Option "ModeValidation" "NoMaxPClkCheck"
+
+
+ Option "ModeValidation" "CRT-0: NoEdidModes, NoMaxPClkCheck; DFP-0: NoVesaModes"
+
+Option "ModeDebug"
+"boolean"
Option "UseEvents"
+"boolean"
Option "FlatPanelProperties"
+"string"
+ "<DFP-0>: <property=value>, <property=value>; <DFP-1>: <property=value>; ..."
+
+
+
+
+
+ Option "FlatPanelProperties" "Scaling = Centered"
+
+
+ Option "FlatPanelProperties" "DFP-0: Scaling = Centered; DFP-1: Scaling = Scaled, Dithering = Enabled"
+
+Option "ProbeAllGpus"
+"boolean"
Option "DynamicTwinView"
+"boolean"
Option "IncludeImplicitMetaModes"
+"boolean"
Option "AllowIndirectPixmaps"
+"boolean"
Option "OnDemandVBlankInterrupts"
+"boolean"
Option "PixmapCacheSize"
+"size"
size
specifies the number of bytes to use
+for the pixmap cache. Reserving this memory improves performance
+when pixmaps are created and destroyed rapidly, but prevents this
+memory from being used by OpenGL. When this cache is disabled or
+space in the cache is exhausted, the driver will still allocate
+pixmaps in video memory but pixmap creation and deletion
+performance will not be improved.Option "PixmapCacheSize"
+"1048576"
will allocate one megabyte for the pixmap
+cache.Option "AllowSHMPixmaps"
+"boolean"
Option
+"InitializeWindowBackingPixmaps" "boolean"
Option "AllowUnofficialGLXProtocol"
+"boolean"
Option "PanAllDisplays"
+"boolean"
nvidia.ko
-needs to be loaded):
- % sysctl -a hw.nvidia.registry
-
-
- % sysctl hw.nvidia.registry.EnableVia4x=1
-
-/etc/sysctl.conf
file.
-See man 5
-sysctl.conf
for details.nvidia.ko
:
-
+VideoMemoryTypeOverride
-
-
-
-
-
-Value
-Meaning
-
-
-1
-SDRAM
-
-
-
-2
-SGRAM
-EnableVia4x
-
-
-
-
-
-Value
-Meaning
-
-
-0
-disable AGP 4x on Via chipsets (default)
-
-
-
-1
-enable AGP 4x on Via chipsets
-EnableALiAGP
-
-
-
-
-
-Value
-Meaning
-
-
-0
-disable AGP on Ali1541 and ALi1647 (default)
-
-
-
-1
-enable AGP on Ali1541 and ALi1647
-NvAGP
-
-
-
-
-
-Value
-Meaning
-
-
-0
-disable AGP support
-
-
-1
-use the NVIDIA builtin driver (if possible)
-
-
-2
-use the kernel's AGPGART driver (if possible)
-
-
-
-3
-use any available driver (try 2, then 1)
-ReqAGPRate
EnableAGPSBA
-
-
-
-
-
-Value
-Meaning
-
-
-0
-disable Side Band Addressing (default on x86, see below)
-
-
-
-1
-enable Side Band Addressing (if supported)
-EnableAGPFW
-
-
-
-
-
-Value
-Meaning
-
-
-0
-disable Fast Writes (default)
-
-
-
-1
-enable Fast Writes
-
+
For this reason, NVIDIA recommends the following number of video surfaces be allocated:
(num_ref + 3) for progressive content, and no deinterlacing.
+(num_ref + 3) for progressive content, and no +de-interlacing.
(num_ref + 5) for interlaced content using advanced -deinterlacing.
+de-interlacing.For applications that perform significant amounts of rendering -between bitmaps and output surfaces, a similar argument may apply -to the number of output surfaces allocated.
-Finally, consider the display path via the presentation queue. -This portion of the pipeline requires at least 2 output surfaces; -one that is being actively displayed by the presentation queue, and -one being rendered to for subsequent display. As before, using this +
Next, consider the display path via the presentation queue. This +portion of the pipeline requires at least 2 output surfaces; one +that is being actively displayed by the presentation queue, and one +being rendered to for subsequent display. As before, using this minimum number of surfaces may not be optimal. For some video streams, the hardware may only achieve real-time decoding on -average, not for each individual frame. Similarly, system level -issues such as scheduler algorithms and system load may prevent the -CPU portion of the driver from operating for short periods of time. -Both of these potential issues may be solved by allocating more -output surfaces, and queuing more than one outstanding output -surface into the presentation queue.
+average, not for each individual frame. Using compositing APIs to +render OSD, GUIs, etc., may introduce extra jitter and latency into +the pipeline. Similarly, system level issues such as scheduler +algorithms and system load may prevent the CPU portion of the +driver from operating for short periods of time. All of these +potential issues may be solved by allocating more output surfaces, +and queuing more than one outstanding output surface into the +presentation queue. +The reason for using more than the minimum number of video +surfaces is to ensure that the decoding and post-processing +pipeline is not stalled, and hence is kept busy for the maximum +amount of time possible. In contrast, the reason for using more +than the minimum number of output surfaces is to hide jitter and +latency in various GPU and CPU operations.
The choice of exactly how many surfaces to allocate is a resource usage v.s. performance trade-off; Allocating more than the minimum number of surfaces will increase performance, but use @@ -127,11 +133,11 @@ performance.
Prev | +"appendix-g-section-02.html">PrevUp | +"appendix-g.html">UpNext | +"appendix-g-section-04.html">Next|
Performance diff --git a/doc/html/appendix-k-section-04.html b/doc/html/appendix-g-section-04.html similarity index 74% rename from doc/html/appendix-k-section-04.html rename to doc/html/appendix-g-section-04.html index 272f347..2b83073 100644 --- a/doc/html/appendix-k-section-04.html +++ b/doc/html/appendix-g-section-04.html @@ -9,11 +9,11 @@ - - + - @@ -24,11 +24,11 @@ | |||
Prev | -Appendix K. VDPAU +"appendix-g-section-03.html">Prev + | Appendix G. VDPAU Support | Next | +"appendix-g-section-05.html">Next
---|
Prev | +"appendix-g-section-03.html">PrevUp | +"appendix-g.html">UpNext | +"appendix-g-section-05.html">Next|
Getting the Best diff --git a/doc/html/appendix-k-section-05.html b/doc/html/appendix-g-section-05.html similarity index 81% rename from doc/html/appendix-k-section-05.html rename to doc/html/appendix-g-section-05.html index 15b11c4..8e057f2 100644 --- a/doc/html/appendix-k-section-05.html +++ b/doc/html/appendix-g-section-05.html @@ -9,12 +9,12 @@ - - + - + | |||
Prev | -Appendix K. VDPAU +"appendix-g-section-04.html">Prev + | Appendix G. VDPAU Support | Next | +"appendix-h.html">Next
---|
Prev | +"appendix-g-section-04.html">PrevUp | +"appendix-g.html">UpNext | +"appendix-h.html">Next
Additional @@ -92,7 +92,7 @@ Notes | Home | - Appendix L. Tips for New FreeBSD Users | + Appendix H. Tips for New FreeBSD Users
A "display device" refers to some piece of hardware capable of -displaying an image. There are three categories of display devices: -analog displays (i.e., CRTs), digital displays (i.e., digital flat -panels (DFPs)), and televisions. Note that analog flat panels are -considered the same as analog CRTs by the NVIDIA FreeBSD -driver.
-A "display device name" is a string description that uniquely -identifies a display device; it follows the format -"<type>-<number>", for example: "CRT-0", "CRT-1", -"DFP-0", or "TV-0". Note that the number indicates how the display -device connector is wired on the graphics card, and has nothing to -do with how many of that kind of display device are present. This -means, for example, that you may have a "CRT-1", even if you do not -have a "CRT-0". To determine which display devices are currently -connected, you may check your X log file for a line similar to the -following:
-- (II) NVIDIA(0): Connected display device(s): CRT-0, DFP-0 --
Display device names can be used in the MetaMode, HorizSync, and -VertRefresh X config options to indicate which display device a -setting should be applied to. For example:
-- Option "MetaModes" "CRT-0: 1600x1200, DFP-0: 1024x768" - Option "HorizSync" "CRT-0: 50-110; DFP-0: 40-70" - Option "VertRefresh" "CRT-0: 60-120; DFP-0: 60" --
Specifying the display device name in these options is not -required; if display device names are not specified, then the -driver attempts to infer which display device a setting applies to. -In the case of MetaModes, for example, the first mode listed is -applied to the "first" display device, and the second mode listed -is applied to the "second" display device. Unfortunately, it is -often unclear which display device is the "first" or "second". That -is why specifying the display device name is preferable.
-When specifying display device names, you may also omit the -number part of the name, though this is only useful if you only -have one of that type of display device. For example, if you have -one CRT and one DFP connected, you may reference them in the -MetaMode string as follows:
-- Option "MetaModes" "CRT: 1600x1200, DFP: 1024x768" -+
Table of Contents
+ +This release includes support for the Video Decode and +Presentation API for Unix-like systems (VDPAU) on most GeForce 8 +series and newer add-in cards, as well as motherboard chipsets with +integrated graphics that have PureVideo support based on these +GPUs.
+VDPAU is specified as a generic API - the choice of which +features to support, and performance levels of those features, is +left up to individual implementations. The details of NVIDIA's +implementation are provided below.
+The maximum supported resolution is 4096x4096.
+The following surface formats and get-/put-bits combinations are +supported:
+VDP_CHROMA_TYPE_420 (Supported get-/put-bits formats are +VDP_YCBCR_FORMAT_NV12, VDP_YCBCR_FORMAT_YV12)
+VDP_CHROMA_TYPE_422 (Supported get-/put-bits formats are +VDP_YCBCR_FORMAT_UYVY, VDP_YCBCR_FORMAT_YUYV)
+The maximum supported resolution is 8192x8192.
+The following surface formats are supported:
+VDP_RGBA_FORMAT_B8G8R8A8
+VDP_RGBA_FORMAT_R8G8B8A8
+VDP_RGBA_FORMAT_B10G10R10A2
+VDP_RGBA_FORMAT_R10G10B10A2
+VDP_RGBA_FORMAT_A8
+Note that VdpBitmapSurfaceCreate's frequently_accessed parameter +directly controls whether the bitmap data will be placed into video +RAM (VDP_TRUE) or system memory (VDP_FALSE). Note that if the +bitmap data cannot be placed into video RAM when requested due to +resource constraints, the implementation will automatically fall +back to placing the data into system RAM.
+The maximum supported resolution is 8192x8192.
+The following surface formats are supported:
+VDP_RGBA_FORMAT_B8G8R8A8
+VDP_RGBA_FORMAT_R10G10B10A2
+For all surface formats, the following get-/put-bits indexed +formats are supported:
+VDP_INDEXED_FORMAT_A4I4
+VDP_INDEXED_FORMAT_I4A4
+VDP_INDEXED_FORMAT_A8I8
+VDP_INDEXED_FORMAT_I8A8
+For all surface formats, the following get-/put-bits YCbCr +formats are supported:
+VDP_YCBCR_FORMAT_Y8U8V8A8
+VDP_YCBCR_FORMAT_V8U8Y8A8
+In all cases, VdpDecoder objects solely support 8-bit 4:2:0 +streams, and only support writing to VDP_CHROMA_TYPE_420 +surfaces.
+The exact set of supported VdpDecoderProfile values depends on +the hardware model in use. Hardware-specific support is listed +below. When reading these lists, please note that VC1_SIMPLE and +VC1_MAIN may be referred to as WMV, WMV3, or WMV9 in other +contexts. Partial acceleration means that VLD (bitstream) decoding +is performed on the CPU, with the GPU performing IDCT and motion +compensation. Complete acceleration means that the GPU performs all +of VLD, IDCT, and motion compensation.
+These chips support the following VdpDecoderProfile values:
+VDP_DECODER_PROFILE_MPEG1, VDP_DECODER_PROFILE_MPEG2_SIMPLE, +VDP_DECODER_PROFILE_MPEG2_MAIN:
+Partial acceleration.
+Minimum width or height: 3 macroblocks (48 pixels).
+Maximum width or height: 128 macroblocks (2048 pixels).
+Maximum macroblocks: 8192
+VDP_DECODER_PROFILE_H264_MAIN, +VDP_DECODER_PROFILE_H264_HIGH:
+Complete acceleration.
+Minimum width or height: 3 macroblocks (48 pixels).
+Maximum width or height: 128 macroblocks (2048 pixels).
+Maximum macroblocks: 8192
+VDP_DECODER_PROFILE_VC1_SIMPLE, VDP_DECODER_PROFILE_VC1_MAIN, +VDP_DECODER_PROFILE_VC1_ADVANCED:
+Partial acceleration.
+Minimum width or height: 3 macroblocks (48 pixels).
+Maximum width or height: 128 macroblocks (2048 pixels).
+Maximum macroblocks: 8190
+These chips support the following VdpDecoderProfile values:
+VDP_DECODER_PROFILE_MPEG1, VDP_DECODER_PROFILE_MPEG2_SIMPLE, +VDP_DECODER_PROFILE_MPEG2_MAIN:
+Complete acceleration.
+Minimum width or height: 3 macroblocks (48 pixels).
+Maximum width or height: 128 macroblocks (2048 pixels).
+Maximum macroblocks: 8192
+VDP_DECODER_PROFILE_H264_MAIN, +VDP_DECODER_PROFILE_H264_HIGH:
+Complete acceleration.
+Minimum width or height: 3 macroblocks (48 pixels).
+Maximum width: 127 macroblocks (2032 pixels).
+Maximum height: 128 macroblocks (2048 pixels).
+Maximum macroblocks: 8190
+Unsupported widths: 49, 54, 59, 64, 113, 118, 123 macroblocks +(784, 864, 944, 1024, 1808, 1888 pixels).
+VDP_DECODER_PROFILE_VC1_SIMPLE, VDP_DECODER_PROFILE_VC1_MAIN, +VDP_DECODER_PROFILE_VC1_ADVANCED:
+Complete acceleration.
+Minimum width or height: 3 macroblocks (48 pixels).
+Maximum width or height: 128 macroblocks (2048 pixels).
+Maximum macroblocks: 8190
+The maximum supported resolution is 4096x4096.
+The video mixer supports all video and output surface +resolutions and formats that the implementation supports.
+The video mixer supports at most 4 auxiliary layers.
+The following features are supported:
+VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL
+VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL_SPATIAL
+VDP_VIDEO_MIXER_FEATURE_INVERSE_TELECINE
+VDP_VIDEO_MIXER_FEATURE_NOISE_REDUCTION
+VDP_VIDEO_MIXER_FEATURE_SHARPNESS
+VDP_VIDEO_MIXER_FEATURE_LUMA_KEY
+In order for either VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL +or VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL_SPATIAL to operate +correctly, the application must supply at least 2 past and 1 future +fields to each VdpMixerRender call. If those fields are not +provided, the VdpMixer will fall back to bob de-interlacing.
+Both regular de-interlacing and half-rate de-interlacing are +supported. Both have the same requirements in terms of the number +of past/future fields required. Both modes should produce +equivalent results.
+In order for VDP_VIDEO_MIXER_FEATURE_INVERSE_TELECINE to have +any effect, one of VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL or +VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL_SPATIAL must be +requested and enabled. Inverse telecine has the same requirement on +the minimum number of past/future fields that must be provided. +Inverse telecine will not operate when "half-rate" de-interlacing +is used.
+Whilst is is possible to apply de-interlacing algorithms to +progressive streams using the techniques outlined in the VDPAU +documentation, NVIDIA does not recommend doing so. One is likely to +introduce more artifacts due to the inverse telecine process than +are removed by detection of bad edits etc.
+The resolution of VdpTime is approximately 10 nanoseconds. At +some arbitrary point during system startup, the initial value of +this clock is synchronized to the system's real-time clock, as +represented by nanoseconds since since Jan 1, 1970. However, no +attempt is made to keep the two time-bases synchronized after this +point. Divergence can and will occur.
+NVIDIA's VdpPresentationQueue supports two mechanisms for +displaying surfaces; overlay and blit-based. The overlay path will +be used wherever possible, with the blit path acting as a more +general fallback. At present, the selection of overlay v.s. blit +path is made at the time of presentation queue creation.
+The following conditions or system configurations will prevent +usage of the overlay path:
+Overlay hardware already in use, e.g. by another VDPAU, GL, or +X11 application, or by SDI output.
+SLI or Multi-GPU enabled on the given X screen.
+Desktop rotation enabled on the given screen.
+X composite extension enabled on the given screen. Note that +simply having the extension enabled is enough to prevent overlay +usage; running an actual compositing manager is not required.
+The environment variable VDPAU_NVIDIA_NO_OVERLAY is set to a +string representation of a non-zero integer.
+The driver determines that the performance requirements of +overlay usage cannot be met by the current hardware +configuration.
+Both the overlay and blit path sync to VBLANK.
+When TwinView is enabled, the blit path can only sync to one of +the display devices; this may cause tearing corruption on the +display device to which VDPAU is not syncing. You can use the +environment variable VDPAU_NVIDIA_SYNC_DISPLAY_DEVICE to specify +the display device to which VDPAU should sync. You should set this +environment variable to the name of a display device; for example +"CRT-1". Look for the line "Connected display device(s):" in your X +log file for a list of the display devices present and their names. +You may also find it useful to review Chapter 12, +Configuring TwinView "Configuring Twinview" and the +section on Ensuring Identical Mode Timings in Chapter 18, +Programming Modes.
+This release supports GLX 1.4.
-Additionally, the following GLX extensions are supported on -appropriate GPUs:
-GLX_EXT_visual_info
-GLX_EXT_visual_rating
-GLX_SGIX_fbconfig
-GLX_SGIX_pbuffer
-GLX_ARB_get_proc_address
-GLX_SGI_video_sync
-GLX_SGI_swap_control
-GLX_ARB_multisample
-GLX_NV_float_buffer
-GLX_ARB_fbconfig_float
-GLX_NV_swap_group
-GLX_NV_video_out
-GLX_EXT_texture_from_pixmap
-For a description of these extensions, see the OpenGL extension -registry at http://www.opengl.org/registry/
-Some of the above extensions exist as part of core GLX 1.4 -functionality, however, they are also exported as extensions for -backwards compatibility.
+This installation guide assumes that the user has at least a +basic understanding of FreeBSD techniques and terminology. In this +section we provide tips that the new user may find helpful. While +the these tips are meant to clarify and assist users in installing +and configuring the NVIDIA FreeBSD Driver, it is by no means a +tutorial on the use or administration of the FreeBSD operating +system. Unlike many desktop operating systems, it is relatively +easy to cause irreparable damage to your FreeBSD system. If you are +unfamiliar with the use of FreeBSD, we strongly recommend that you +seek a tutorial through your distributor before proceeding.
+While newer releases of FreeBSD bring new desktop interfaces to
+the user, much of the work in FreeBSD takes place at the command
+prompt. If you are familiar with the Windows operating system, the
+FreeBSD command prompt is analogous to the Windows command prompt,
+although the syntax and use varies somewhat. All of the commands in
+this section are performed at the command prompt. Some systems are
+configured to boot into console mode, in which case the user is
+presented with a prompt at login. Other systems are configured to
+start the X window system, in which case the user must open a
+terminal or console window in order to get a command prompt. This
+can usually be done by searching the desktop menus for a terminal
+or console program. While it is customizable, the basic prompt
+usually consists of a short string of information, one of the
+characters #
, $
, or %
, and a cursor
+(possibly flashing) that indicates where the user's input will be
+displayed.
FreeBSD has a hierarchical directory structure. From anywhere in +the directory structure, the ls command will list the contents of that +directory. The file +command will print the type of files in a directory. For +example,
++ % file filename ++
will print the type of the file filename
. Changing directories is done with the
+cd command.
+ % cd dirname ++
will change the current directory to dirname
. From anywhere in the directory
+structure, the command pwd will print the name of the current
+directory. There are two special directories, .
and ..
, which
+refer to the current directory and the next directory up the
+hierarchy, respectively. For any commands that require a file name
+or directory name as an argument, you may specify the absolute or
+the relative paths to those elements. An absolute path begins with
+the "/" character, referring to the top or root of the directory
+structure. A relative path begins with a directory in the current
+working directory. The relative path may begin with .
or ..
. Elements
+of a path are separated with the "/" character. As an example, if
+the current directory is /home/jesse
+and the user wants to change to the /usr/local
directory, he can use either of the
+following commands to do so:
+ % cd /usr/local ++
or
++ % cd ../../usr/local ++ +
All files and directories have permissions and ownership
+associated with them. This is useful for preventing
+non-administrative users from accidentally (or maliciously)
+corrupting the system. The permissions and ownership for a file or
+directory can be determined by passing the -l
option to the ls command. For example:
+% ls -l +drwxr-xr-x 2 jesse users 4096 Feb 8 09:32 bin +drwxrwxrwx 10 jesse users 4096 Feb 10 12:04 pub +-rw-r--r-- 1 jesse users 45 Feb 4 03:55 testfile +-rwx------ 1 jesse users 93 Feb 5 06:20 myprogram +-rw-rw-rw- 1 jesse users 112 Feb 5 06:20 README +% ++
The first character column in the first output field states the +file type, where 'd' is a directory and '-' is a regular file. The +next nine columns specify the permissions (see paragraph below) of +the element. The second field indicates the number of files +associated with the element, the third field indicates the owner, +the fourth field indicates the group that the file is associated +with, the fifth field indicates the size of the element in bytes, +the sixth, seventh and eighth fields indicate the time at which the +file was last modified and the ninth field is the name of the +element.
+As stated, the last nine columns in the first field indicate the
+permissions of the element. These columns are grouped into threes,
+the first grouping indicating the permissions for the owner of the
+element (jesse
in this case), the
+second grouping indicating the permissions for the group associated
+with the element, and the third grouping indicating the permissions
+associated with the rest of the world. The r
, w
, and
+x
indicate read, write and execute
+permissions, respectively, for each of these associations. For
+example, user jesse
has read and
+write permissions for testfile
, users
+in the group users
have read
+permission only, and the rest of the world also has read
+permissions only. However, for the file myprogram
, user jesse
has read, write and execute permissions
+(suggesting that myprogram
is a
+program that can be executed), while the group users
and the rest of the world have no
+permissions (suggesting that the owner doesn't want anyone else to
+run his program). The permissions, ownership and group associated
+with an element can be changed with the commands
+chmod,
+chown and
+chgrp, respectively.
+If a user with the appropriate permissions wanted to change the
+user/group ownership of README
from
+jesse/users to joe/admin, he would do the following:
+ # chown joe README + # chgrp admin README ++
The syntax for chmod is slightly more complicated and has +several variations. The most concise way of setting the permissions +for a single element uses a triplet of numbers, one for each of +user, group and world. The value for each number in the triplet +corresponds to a combination of read, write and execute +permissions. Execute only is represented as 1, write only is +represented as 2, and read only is represented as 4. Combinations +of these permissions are represented as sums of the individual +permissions. Read and execute is represented as 5, where as read, +write and execute is represented as 7. No permissions is +represented as 0. Thus, to give the owner read, write and execute +permissions, the group read and execute permissions and the world +no permissions, a user would do as follows:
++ % chmod 750 myprogram ++ +
The shell provides an interface between the user and the
+operating system. It is the job of the shell to interpret the input
+that the user gives at the command prompt and call upon the system
+to do something in response. There are several different shells
+available, each with somewhat different syntax and capabilities.
+The two most common flavors of shells used on FreeBSD stem from the
+Bourne shell (sh) and
+the C-shell (csh)
+Different users have preferences and biases towards one shell or
+the other, and some certainly make it easier (or at least more
+intuitive) to do some things than others. You can determine your
+current shell by printing the value of the SHELL
environment variable from the command prompt
+with
+ % echo $SHELL ++
You can start a new shell simply by entering the name of the +shell from the command prompt:
++ % csh ++
or
++ % sh ++
and you can run a program from within a specific shell by +preceding the name of the executable with the name of the shell in +which it will be run:
++ % sh myprogram ++
The user's default shell at login is determined by whoever set +up his account. While there are many syntactic differences between +shells, perhaps the one that is encountered most frequently is the +way in which environment variables are set.
+Every session has associated with it environment variables,
+which consist of name/value pairs and control the way in which the
+shell and programs run from the shell behave. An example of an
+environment variable is the PATH
+variable, which tells the shell which directories to search when
+trying to locate an executable file that the user has entered at
+the command line. If you are certain that a command exists, but the
+shell complains that it cannot be found when you try to execute it,
+there is likely a problem with the PATH
+variable. Environment variables are set differently depending on
+the shell being used. For the Bourne shell (sh), it is done as:
+ % export MYVARIABLE="avalue" ++
for the C-shell, it is done as:
++ % setenv MYVARIABLE "avalue" ++
In both cases the quotation marks are only necessary if the +value contains spaces. The echo command can be used to examine the +value of an environment variable:
++ % echo $MYVARIABLE ++
Commands to set environment variables can also include
+references to other environment variables (prepended with the "$"
+character), including themselves. In order to add the path
+/usr/local/bin
to the beginning of
+the search path, and the current directory .
to the end of the search path, a user would
+enter
+ % export PATH=/usr/local/bin:$PATH:. ++
in the Bourne shell, and
++ % setenv PATH /usr/local/bin:${PATH}:. ++
in C-shell. Note the curly braces are required to protect the +variable name in C-shell.
+There are several text editors available for the FreeBSD
+operating system. Some of these editors require the X window
+system, while others are designed to operate in a console or
+terminal. It is generally a good thing to be competent with a
+terminal-based text editor, as there are times when the files
+necessary for X to run are the ones that must be edited. Three
+popular editors are vi, pico and emacs, each of which can be started from
+the command line, optionally supplying the name of a file to be
+edited. vi is
+arguably the most ubiquitous as well as the least intuitive of the
+three. pico is
+relatively straightforward for a new user, though not as often
+installed on systems. If you don't have pico, you may have a similar editor
+called nano.
+emacs is highly
+extensible and fairly widely available, but can be somewhat
+unwieldy in a non-X environment. The newer versions each come with
+online help, and offline help can be found in the manual and info
+pages for each (see the section on FreeBSD Manual and Info pages).
+Many programs use the EDITOR
environment
+variable to determine which text editor to start when editing is
+required.
Upon installation, almost all distributions set up the default
+administrative user with the username root
. There are many things on the system that
+only root
(or a similarly
+privileged user) can do, one of which is installing the NVIDIA
+FreeBSD Driver. We must emphasize that
+assuming the identity of root
is
+inherently risky and as root
it is
+relatively easy to corrupt your system or otherwise render it
+unusable. There are three ways to become root
. You may log in as root
as you would any other user, you may use
+the switch user command (su) at the command prompt, or, on some
+systems, use the sudo
+utility, which allows users to run programs as root
while keeping a log of their actions. This
+last method is useful in case a user inadvertently causes damage to
+the system and cannot remember what he has done (or prefers not to
+admit what he has done). It is generally a good practice to remain
+root
only as long as is necessary
+to accomplish the task requiring root
privileges (another useful feature of the
+sudo utility).
System manual or info pages are usually installed during
+installation. These pages are typically up-to-date and generally
+contain a comprehensive listing of the use of programs and
+utilities on the system. Also, many programs include the
+--help
option, which usually prints a
+list of common options for that program. To view the manual page
+for a command, enter
+ % man commandname ++
at the command prompt, where commandname
refers to the command in which you are
+interested. Similarly, entering
+ % info commandname ++
will bring up the info page for the command. Depending on the
+application, one or the other may be more up-to-date. The interface
+for the info system is interactive and navigable. If you are unable
+to locate the man page for the command you are interested in, you
+may need to add additional elements to your MANPATH
environment variable. See the section on
+environment variables.
DPI (Dots Per Inch), also known as PPI (Pixels Per Inch), is a -property of an X screen that describes the physical size of pixels. -Some X applications, such as xterm, can use the DPI of an X screen -to determine how large (in pixels) to draw an object in order for -that object to be displayed at the desired physical size on the -display device.
-The DPI of an X screen is computed by dividing the size of the X -screen in pixels by the size of the X screen in inches:
-- DPI = SizeInPixels / SizeInInches --
Since the X screen stores its physical size in millimeters -rather than inches (1 inch = 25.4 millimeters):
-- DPI = (SizeInPixels * 25.4) / SizeInMillimeters --
The NVIDIA X driver reports the size of the X screen in pixels -and in millimeters. On X.Org 6.9 or newer, when the XRandR -extension resizes the X screen in pixels, the NVIDIA X driver -computes a new size in millimeters for the X screen, to maintain a -constant DPI (see the "Physical Size" column of the `xrandr -q` -output as an example). This is done because a changing DPI can -cause interaction problems for some applications. To disable this -behavior, and instead keep the same millimeter size for the X -screen (and therefore have a changing DPI), set the ConstantDPI -option to FALSE (see Appendix F, X -Config Options for details).
-You can query the DPI of your X screen by running:
-- % xdpyinfo | grep -B1 dot --
which should generate output like this:
-- dimensions: 1280x1024 pixels (382x302 millimeters) - resolution: 85x86 dots per inch -- -
The NVIDIA X driver performs several steps during X screen -initialization to determine the DPI of each X screen:
-If the display device provides an EDID, and the EDID contains -information about the physical size of the display device, that is -used to compute the DPI, along with the size in pixels of the first -mode to be used on the display device. If multiple display devices -are used by this X screen, then the NVIDIA X screen will choose -which display device to use. You can override this with the -"UseEdidDpi" X configuration option: you can specify a particular -display device to use; e.g.:
-- Option "UseEdidDpi" "DFP-1" --
or disable EDID-computed DPI by setting this option to -false:
-- Option "UseEdidDpi" "FALSE" --
EDID-based DPI computation is enabled by default when an EDID is -available.
-If the "-dpi" commandline option to the X server is specified, -that is used to set the DPI (see `X -h` for details). This will -override the "UseEdidDpi" option.
-If the "DPI" X configuration option is specified (see Appendix F, X -Config Options for details), that will be used to set the -DPI. This will override the "UseEdidDpi" option.
-If none of the above are available, then the "DisplaySize" X -config file Monitor section information will be used to determine -the DPI, if provided; see the xorg.conf or XF86Config man pages for -details.
-If none of the above are available, the DPI defaults to -75x75.
-You can find how the NVIDIA X driver determined the DPI by -looking in your X log file. There will be a line that looks -something like the following:
-- (--) NVIDIA(0): DPI set to (101, 101); computed from "UseEdidDpi" X config option -- -
Note that the physical size of the X screen, as reported through -`xdpyinfo` is computed based on the DPI and the size of the X -screen in pixels.
-The DPI of an X screen can be confusing when TwinView is -enabled: with TwinView, multiple display devices (possibly with -different DPIs) display portions of the same X screen, yet DPI can -only be advertised from the X server to the X application with X -screen granularity. Solutions for this include:
-Use separate X screens, rather than TwinView; see Chapter 12, -Configuring Multiple X Screens on One Card for -details.
-Experiment with different DPI settings to find a DPI that is -suitable for both display devices.
-This release includes support for the XVideo Motion Compensation -(XvMC) version 1.0 API on GeForce 6 series and GeForce 7 series -add-in cards, as well as motherboard chipsets with integrated -graphics that have PureVideo support based on these GPUs. There is -a static library, "libXvMCNVIDIA.a", and a dynamic one, -"libXvMCNVIDIA_dynamic.so", which is suitable for dlopening. XvMC's -"IDCT" and "motion-compensation" levels of acceleration, AI44 and -IA44 subpictures, and 4:2:0 Surfaces up to 2032x2032 are -supported.
-libXvMCNVIDIA observes the XVMC_DEBUG environment variable and -will provide some debug output to stderr when set to an appropriate -integer value. '0' disables debug output. '1' enables debug output -for failure conditions. '2' or higher enables output of warning -messages.
-Table of Contents
- -This release includes support for the Video Decode and -Presentation API for Unix-like systems (VDPAU) on most GeForce 8 -series and newer add-in cards, as well as motherboard chipsets with -integrated graphics that have PureVideo support based on these -GPUs.
-VDPAU is specified as a generic API - the choice of which -features to support, and performance levels of those features, is -left up to individual implementations. The details of NVIDIA's -implementation are provided below.
-The maximum supported resolution is 4096x4096.
-The following surface formats and get-/put-bits combinations are -supported:
-VDP_CHROMA_TYPE_420 (Supported get-/put-bits formats are -VDP_YCBCR_FORMAT_NV12, VDP_YCBCR_FORMAT_YV12)
-VDP_CHROMA_TYPE_422 (Supported get-/put-bits formats are -VDP_YCBCR_FORMAT_UYVY, VDP_YCBCR_FORMAT_YUYV)
-The maximum supported resolution is 8192x8192.
-The following surface formats are supported:
-VDP_RGBA_FORMAT_B8G8R8A8
-VDP_RGBA_FORMAT_R8G8B8A8
-VDP_RGBA_FORMAT_B10G10R10A2
-VDP_RGBA_FORMAT_R10G10B10A2
-VDP_RGBA_FORMAT_A8
-Note that VdpBitmapSurfaceCreate's frequently_accessed parameter -directly controls whether the bitmap data will be placed into video -RAM (VDP_TRUE) or system memory (VDP_FALSE). Note that if the -bitmap data cannot be placed into video RAM when requested due to -resource constraints, the implementation will automatically fall -back to placing the data into system RAM.
-The maximum supported resolution is 8192x8192.
-The following surface formats are supported:
-VDP_RGBA_FORMAT_B8G8R8A8
-VDP_RGBA_FORMAT_R10G10B10A2
-For all surface formats, the following get-/put-bits indexed -formats are supported:
-VDP_INDEXED_FORMAT_A4I4
-VDP_INDEXED_FORMAT_I4A4
-VDP_INDEXED_FORMAT_A8I8
-VDP_INDEXED_FORMAT_I8A8
-For all surface formats, the following get-/put-bits YCbCr -formats are supported:
-VDP_YCBCR_FORMAT_Y8U8V8A8
-VDP_YCBCR_FORMAT_V8U8Y8A8
-In all cases, VdpDecoder objects solely support 8-bit 4:2:0 -streams, and only support writing to VDP_CHROMA_TYPE_420 -surfaces.
-The exact set of supported VdpDecoderProfile values depends on -the hardware model in use.
-These chips support the following VdpDecoderProfile values:
-VDP_DECODER_PROFILE_MPEG1, VDP_DECODER_PROFILE_MPEG2_SIMPLE, -VDP_DECODER_PROFILE_MPEG2_MAIN:
-Partial acceleration.
-Minimum width or height: 3 macroblocks (48 pixels).
-Maximum width or height: 128 macroblocks (2048 pixels).
-Maximum macroblocks: 8192
-VDP_DECODER_PROFILE_H264_MAIN, -VDP_DECODER_PROFILE_H264_HIGH:
-Complete acceleration.
-Minimum width or height: 3 macroblocks (48 pixels).
-Maximum width or height: 128 macroblocks (2048 pixels).
-Maximum macroblocks: 8192
-These chips support the following VdpDecoderProfile values:
-VDP_DECODER_PROFILE_MPEG1, VDP_DECODER_PROFILE_MPEG2_SIMPLE, -VDP_DECODER_PROFILE_MPEG2_MAIN:
-Complete acceleration.
-Minimum width or height: 3 macroblocks (48 pixels).
-Maximum width or height: 128 macroblocks (2048 pixels).
-Maximum macroblocks: 8192
-VDP_DECODER_PROFILE_H264_MAIN, -VDP_DECODER_PROFILE_H264_HIGH:
-Complete acceleration.
-Minimum width or height: 3 macroblocks (48 pixels).
-Maximum width: 127 macroblocks (2032 pixels).
-Maximum height: 128 macroblocks (2048 pixels).
-Maximum macroblocks: 8190
-Unsupported widths: 49, 54, 59, 64, 113, 118, 123 macroblocks -(784, 864, 944, 1024, 1808, 1888 pixels).
-VDP_DECODER_PROFILE_VC1_SIMPLE, VDP_DECODER_PROFILE_VC1_MAIN, -VDP_DECODER_PROFILE_VC1_ADVANCED:
-Complete acceleration.
-Minimum width or height: 3 macroblocks (48 pixels).
-Maximum width or height: 128 macroblocks (2048 pixels).
-Maximum macroblocks: 8190
-The maximum supported resolution is 4096x4096.
-The video mixer supports all video and output surface -resolutions and formats that the implementation supports.
-The video mixer supports at most 4 auxiliary layers.
-The following features are supported:
-VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL
-VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL_SPATIAL
-VDP_VIDEO_MIXER_FEATURE_INVERSE_TELECINE
-VDP_VIDEO_MIXER_FEATURE_NOISE_REDUCTION
-VDP_VIDEO_MIXER_FEATURE_SHARPNESS
-VDP_VIDEO_MIXER_FEATURE_LUMA_KEY
-In order for either VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL -or VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL_SPATIAL to operate -correctly, the application must supply at least 2 past and 1 future -fields to each VdpMixerRender call. If those fields are not -provided, the VdpMixer will fall back to bob deinterlacing.
-In order for VDP_VIDEO_MIXER_FEATURE_INVERSE_TELECINE to have -any effect, one of VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL or -VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL_SPATIAL must be -requested and enabled. Inverse telecine has the same requirement on -the minimum number of past/future fields that must be provided.
-The resolution of VdpTime is approximately 10ns. At some -arbitrary point during system startup, the initial value of this -clock is synchronized to the system's real-time clock, as -represented by ns since since Jan 1, 1970. However, no attempt is -made to keep the two time-bases synchronized after this point. -Divergence can and will occur.
-NVIDIA's VdpPresentationQueue supports two mechanisms for -displaying surfaces; overlay and blit-based. The overlay path will -be used wherever possible, with the blit path acting as a more -general fallback. At present, the selection of overlay v.s. blit -path is made at the time of presentation queue creation.
-The following conditions or system configurations will prevent -usage of the overlay path:
-Overlay hardware already in use, e.g. by another VDPAU, GL, or -X11 application, or by SDI output.
-SLI or Multi-GPU enabled on the given X screen.
-Desktop rotation enabled on the given screen.
-X composite extension enabled on the given screen. Note that -simply having the extension enabled is enough to prevent overlay -usage; running an actual compositing manager is not required.
-The environment variable VDPAU_NVIDIA_NO_OVERLAY is set to a -string representation of a non-zero integer.
-At present, the overlay path always syncs to vblank, whereas the -blit path never syncs to vblank.
-This installation guide assumes that the user has at least a -basic understanding of FreeBSD techniques and terminology. In this -section we provide tips that the new user may find helpful. While -the these tips are meant to clarify and assist users in installing -and configuring the NVIDIA FreeBSD Driver, it is by no means a -tutorial on the use or administration of the FreeBSD operating -system. Unlike many desktop operating systems, it is relatively -easy to cause irreparable damage to your FreeBSD system. If you are -unfamiliar with the use of FreeBSD, we strongly recommend that you -seek a tutorial through your distributor before proceeding.
-While newer releases of FreeBSD bring new desktop interfaces to
-the user, much of the work in FreeBSD takes place at the command
-prompt. If you are familiar with the Windows operating system, the
-FreeBSD command prompt is analogous to the Windows command prompt,
-although the syntax and use varies somewhat. All of the commands in
-this section are performed at the command prompt. Some systems are
-configured to boot into console mode, in which case the user is
-presented with a prompt at login. Other systems are configured to
-start the X window system, in which case the user must open a
-terminal or console window in order to get a command prompt. This
-can usually be done by searching the desktop menus for a terminal
-or console program. While it is customizable, the basic prompt
-usually consists of a short string of information, one of the
-characters #
, $
, or %
, and a cursor
-(possibly flashing) that indicates where the user's input will be
-displayed.
FreeBSD has a hierarchical directory structure. From anywhere in -the directory structure, the ls command will list the contents of that -directory. The file -command will print the type of files in a directory. For -example,
-- % file filename --
will print the type of the file filename
. Changing directories is done with the
-cd command.
- % cd dirname --
will change the current directory to dirname
. From anywhere in the directory
-structure, the command pwd will print the name of the current
-directory. There are two special directories, .
and ..
, which
-refer to the current directory and the next directory up the
-hierarchy, respectively. For any commands that require a file name
-or directory name as an argument, you may specify the absolute or
-the relative paths to those elements. An absolute path begins with
-the "/" character, referring to the top or root of the directory
-structure. A relative path begins with a directory in the current
-working directory. The relative path may begin with .
or ..
. Elements
-of a path are separated with the "/" character. As an example, if
-the current directory is /home/jesse
-and the user wants to change to the /usr/local
directory, he can use either of the
-following commands to do so:
- % cd /usr/local --
or
-- % cd ../../usr/local -- -
All files and directories have permissions and ownership
-associated with them. This is useful for preventing
-non-administrative users from accidentally (or maliciously)
-corrupting the system. The permissions and ownership for a file or
-directory can be determined by passing the -l
option to the ls command. For example:
-% ls -l -drwxr-xr-x 2 jesse users 4096 Feb 8 09:32 bin -drwxrwxrwx 10 jesse users 4096 Feb 10 12:04 pub --rw-r--r-- 1 jesse users 45 Feb 4 03:55 testfile --rwx------ 1 jesse users 93 Feb 5 06:20 myprogram --rw-rw-rw- 1 jesse users 112 Feb 5 06:20 README -% --
The first character column in the first output field states the -file type, where 'd' is a directory and '-' is a regular file. The -next nine columns specify the permissions (see paragraph below) of -the element. The second field indicates the number of files -associated with the element, the third field indicates the owner, -the fourth field indicates the group that the file is associated -with, the fifth field indicates the size of the element in bytes, -the sixth, seventh and eighth fields indicate the time at which the -file was last modified and the ninth field is the name of the -element.
-As stated, the last nine columns in the first field indicate the
-permissions of the element. These columns are grouped into threes,
-the first grouping indicating the permissions for the owner of the
-element (jesse
in this case), the
-second grouping indicating the permissions for the group associated
-with the element, and the third grouping indicating the permissions
-associated with the rest of the world. The r
, w
, and
-x
indicate read, write and execute
-permissions, respectively, for each of these associations. For
-example, user jesse
has read and
-write permissions for testfile
, users
-in the group users
have read
-permission only, and the rest of the world also has read
-permissions only. However, for the file myprogram
, user jesse
has read, write and execute permissions
-(suggesting that myprogram
is a
-program that can be executed), while the group users
and the rest of the world have no
-permissions (suggesting that the owner doesn't want anyone else to
-run his program). The permissions, ownership and group associated
-with an element can be changed with the commands
-chmod,
-chown and
-chgrp, respectively.
-If a user with the appropriate permissions wanted to change the
-user/group ownership of README
from
-jesse/users to joe/admin, he would do the following:
- # chown joe README - # chgrp admin README --
The syntax for chmod is slightly more complicated and has -several variations. The most concise way of setting the permissions -for a single element uses a triplet of numbers, one for each of -user, group and world. The value for each number in the triplet -corresponds to a combination of read, write and execute -permissions. Execute only is represented as 1, write only is -represented as 2, and read only is represented as 4. Combinations -of these permissions are represented as sums of the individual -permissions. Read and execute is represented as 5, where as read, -write and execute is represented as 7. No permissions is -represented as 0. Thus, to give the owner read, write and execute -permissions, the group read and execute permissions and the world -no permissions, a user would do as follows:
-- % chmod 750 myprogram -- -
The shell provides an interface between the user and the
-operating system. It is the job of the shell to interpret the input
-that the user gives at the command prompt and call upon the system
-to do something in response. There are several different shells
-available, each with somewhat different syntax and capabilities.
-The two most common flavors of shells used on FreeBSD stem from the
-Bourne shell (sh) and
-the C-shell (csh)
-Different users have preferences and biases towards one shell or
-the other, and some certainly make it easier (or at least more
-intuitive) to do some things than others. You can determine your
-current shell by printing the value of the SHELL
environment variable from the command prompt
-with
- % echo $SHELL --
You can start a new shell simply by entering the name of the -shell from the command prompt:
-- % csh --
or
-- % sh --
and you can run a program from within a specific shell by -preceding the name of the executable with the name of the shell in -which it will be run:
-- % sh myprogram --
The user's default shell at login is determined by whoever set -up his account. While there are many syntactic differences between -shells, perhaps the one that is encountered most frequently is the -way in which environment variables are set.
-Every session has associated with it environment variables,
-which consist of name/value pairs and control the way in which the
-shell and programs run from the shell behave. An example of an
-environment variable is the PATH
-variable, which tells the shell which directories to search when
-trying to locate an executable file that the user has entered at
-the command line. If you are certain that a command exists, but the
-shell complains that it cannot be found when you try to execute it,
-there is likely a problem with the PATH
-variable. Environment variables are set differently depending on
-the shell being used. For the Bourne shell (sh), it is done as:
- % export MYVARIABLE="avalue" --
for the C-shell, it is done as:
-- % setenv MYVARIABLE "avalue" --
In both cases the quotation marks are only necessary if the -value contains spaces. The echo command can be used to examine the -value of an environment variable:
-- % echo $MYVARIABLE --
Commands to set environment variables can also include
-references to other environment variables (prepended with the "$"
-character), including themselves. In order to add the path
-/usr/local/bin
to the beginning of
-the search path, and the current directory .
to the end of the search path, a user would
-enter
- % export PATH=/usr/local/bin:$PATH:. --
in the Bourne shell, and
-- % setenv PATH /usr/local/bin:${PATH}:. --
in C-shell. Note the curly braces are required to protect the -variable name in C-shell.
-There are several text editors available for the FreeBSD
-operating system. Some of these editors require the X window
-system, while others are designed to operate in a console or
-terminal. It is generally a good thing to be competent with a
-terminal-based text editor, as there are times when the files
-necessary for X to run are the ones that must be edited. Three
-popular editors are vi, pico and emacs, each of which can be started from
-the command line, optionally supplying the name of a file to be
-edited. vi is
-arguably the most ubiquitous as well as the least intuitive of the
-three. pico is
-relatively straightforward for a new user, though not as often
-installed on systems. If you don't have pico, you may have a similar editor
-called nano.
-emacs is highly
-extensible and fairly widely available, but can be somewhat
-unwieldy in a non-X environment. The newer versions each come with
-online help, and offline help can be found in the manual and info
-pages for each (see the section on FreeBSD Manual and Info pages).
-Many programs use the EDITOR
environment
-variable to determine which text editor to start when editing is
-required.
Upon installation, almost all distributions set up the default
-administrative user with the username root
. There are many things on the system that
-only root
(or a similarly
-privileged user) can do, one of which is installing the NVIDIA
-FreeBSD Driver. We must emphasize that
-assuming the identity of root
is
-inherently risky and as root
it is
-relatively easy to corrupt your system or otherwise render it
-unusable. There are three ways to become root
. You may log in as root
as you would any other user, you may use
-the switch user command (su) at the command prompt, or, on some
-systems, use the sudo
-utility, which allows users to run programs as root
while keeping a log of their actions. This
-last method is useful in case a user inadvertently causes damage to
-the system and cannot remember what he has done (or prefers not to
-admit what he has done). It is generally a good practice to remain
-root
only as long as is necessary
-to accomplish the task requiring root
privileges (another useful feature of the
-sudo utility).
System manual or info pages are usually installed during
-installation. These pages are typically up-to-date and generally
-contain a comprehensive listing of the use of programs and
-utilities on the system. Also, many programs include the
---help
option, which usually prints a
-list of common options for that program. To view the manual page
-for a command, enter
- % man commandname --
at the command prompt, where commandname
refers to the command in which you are
-interested. Similarly, entering
- % info commandname --
will bring up the info page for the command. Depending on the
-application, one or the other may be more up-to-date. The interface
-for the info system is interactive and navigable. If you are unable
-to locate the man page for the command you are interested in, you
-may need to add additional elements to your MANPATH
environment variable. See the section on
-environment variables.
These drivers provide optimized hardware acceleration for OpenGL and X applications and support nearly all recent NVIDIA GPU -products (see Appendix E, +products (see Appendix A, Supported NVIDIA GPU Products for a complete list of supported GPUs). TwinView, TV-Out and flat panel displays are also supported.
This document provides instructions for the installation and use of the NVIDIA Accelerated FreeBSD Graphics Driver. Chapter 2, -Installing the NVIDIA Driver, Chapter 3, +Installing the NVIDIA Driver, Chapter 3, +"Chapter 5. Using Linux Compatibility Support">Chapter 5, Using Linux Compatibility Support and Chapter 4, +"chapter-06.html" title= +"Chapter 6. Configuring X for the NVIDIA Driver">Chapter 6, Configuring X for the NVIDIA Driver walk the user through the process of downloading, installing and configuring the -driver. Chapter 5, +driver. Chapter 7, Frequently Asked Questions addresses frequently asked questions about the installation process, and Chapter 6, Common +"chapter-08.html" title= +"Chapter 8. Common Problems">Chapter 8, Common Problems provides solutions to common problems. The remaining chapters include details on different features of the NVIDIA FreeBSD Driver. Frequently asked questions about specific @@ -80,16 +80,16 @@ tasks are included in the relevant chapters.
It is assumed that the user and reader of this document has at least a basic understanding of FreeBSD techniques and terminology. -However, new FreeBSD users can refer to Appendix L, +"Appendix H. Tips for New FreeBSD Users">Appendix H, Tips for New FreeBSD Users for details on parts of the installation process.
In case additional information is required, -Chapter 24, NVIDIA Contact Info and Additional +"chapter-28.html" title= +"Chapter 28. NVIDIA Contact Info and Additional Resources"> +Chapter 28, NVIDIA Contact Info and Additional Resources provides contact information for NVIDIA FreeBSD driver resources, as well as a brief listing of external resources.
@@ -103,7 +103,7 @@ resources.This installation procedure will likely be simplified further in -the future, but for the moment you will need to download the NVIDIA -FreeBSD Graphics Driver archives from the NVIDIA website, extract -them to a temporary location of your choice, and run the following -from the root of the extracted directory hierarchy:
-- % make install --
This will compile the NVIDIA FreeBSD kernel module, install it,
-and kldload it. It will also remove any conflicting OpenGL
-libraries, and install the NVIDIA OpenGL libraries. The
-/dev/nvidia
device files will be
-created (unless the system is using devfs), and your /boot/loader.conf
file will be updated to
-automatically load the NVIDIA kernel module on boot, as well as the
-Linux ABI compatibility module should you not have it compiled into
-your kernel.
The official minimum software requirements for the NVIDIA +FreeBSD Graphics Driver are as follows:
+Software Element | +Min Requirement | +
---|---|
Kernel | +FreeBSD 5-STABLE (5.3 or later) | +
XFree86/X.Org | +4.2/6.7.0 | +
Additionally, the kernel source tree must be installed in +/usr/src/sys (package 'ssys' installed)
+Note that FreeBSD -STABLE versions older than FreeBSD 5.3 and +FreeBSD 6.x/7.x -CURRENT development snapshots are not +supported.
diff --git a/doc/html/chapter-03.html b/doc/html/chapter-03.html index 4f9966c..0bc1994 100644 --- a/doc/html/chapter-03.html +++ b/doc/html/chapter-03.html @@ -5,28 +5,27 @@ "HTML Tidy for FreeBSD (vers 1 September 2005), see www.w3.org"> -