First Push
This commit is contained in:
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,163 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 41. Addressing Capabilities</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="gbm.html" title=
|
||||
"Chapter 40. GBM and GBM-based Wayland Compositors">
|
||||
<link rel="next" href="nvidia-peermem.html" title=
|
||||
"Chapter 42. GPUDirect RDMA Peer Memory Client">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 41. Addressing
|
||||
Capabilities</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"gbm.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"nvidia-peermem.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="addressingcapabilities" id=
|
||||
"addressingcapabilities"></a>Chapter 41. Addressing
|
||||
Capabilities</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>Many PCIe devices have limitations in what memory addresses they
|
||||
can access for DMA purposes (based on the number of lines dedicated
|
||||
to memory addressing). This can cause problems if the host system
|
||||
has memory mapped to addresses beyond what the PCIe device can
|
||||
support. If a PCIe device is allocated memory at an address beyond
|
||||
what the device can support, the address may be truncated and the
|
||||
device will access the incorrect memory location.</p>
|
||||
<p>Note that since certain system resources, such as ACPI tables
|
||||
and PCI I/O regions, are mapped to address ranges below the 4 GB
|
||||
boundary, the RAM installed in x86/x86-64 systems cannot
|
||||
necessarily be mapped contiguously. Similarly, system firmware is
|
||||
free to map the available RAM at its or its users' discretion. As a
|
||||
result, it is common for systems to have RAM mapped outside of the
|
||||
address range [0, RAM_SIZE], where RAM_SIZE is the amount of RAM
|
||||
installed in the system.</p>
|
||||
<p>For example, it is common for a system with 512 GB of RAM
|
||||
installed to have physical addresses up to ~513 GB. In this
|
||||
scenario, a GPU with an addressing capability of 512 GB would force
|
||||
the driver to fall back to the 4 GB DMA zone for this GPU.</p>
|
||||
<p>The NVIDIA Linux driver attempts to identify the scenario where
|
||||
the host system has more memory than a given GPU can address. If
|
||||
this scenario is detected, the NVIDIA driver will drop back to
|
||||
allocations from the 4 GB DMA zone to avoid address truncation.
|
||||
This means that the driver will use the __GFP_DMA32 flag and limit
|
||||
itself to memory addresses below the 4 GB boundary. This is done on
|
||||
a per-GPU basis, so limiting one GPU will not limit other GPUs in
|
||||
the system.</p>
|
||||
<p>The addressing capabilities of an NVIDIA GPU can be queried at
|
||||
runtime via the procfs interface:</p>
|
||||
<pre class="screen">
|
||||
% cat /proc/driver/nvidia/gpus/domain:bus:device.function/information
|
||||
...
|
||||
DMA Size: 40 bits
|
||||
DMA Mask: 0xffffffffff
|
||||
...
|
||||
</pre>
|
||||
<p>The memory mapping of RAM on a given system can be seen in the
|
||||
BIOS-e820 table printed out by the kernel and available via
|
||||
`dmesg`. Note that the 'usable' ranges are actual RAM:</p>
|
||||
<pre class="screen">
|
||||
[ 0.000000] BIOS-provided physical RAM map:
|
||||
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
|
||||
[ 0.000000] BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
|
||||
[ 0.000000] BIOS-e820: 0000000000100000 - 000000003fe5a800 (usable)
|
||||
[ 0.000000] BIOS-e820: 000000003fe5a800 - 0000000040000000 (reserved)
|
||||
</pre>
|
||||
<h3>Solutions</h3>
|
||||
<p>There are multiple potential ways to solve a discrepancy between
|
||||
your system configuration and a GPU's addressing capabilities.</p>
|
||||
<div class="orderedlist">
|
||||
<ol type="1">
|
||||
<li>
|
||||
<p>Select a GPU with addressing capabilities that match your target
|
||||
configuration.</p>
|
||||
<p>The best way to achieve optimal system and GPU performance is to
|
||||
make sure that the capabilities of the two are in alignment. This
|
||||
is especially important with multiple GPUs in the system, as the
|
||||
GPUs may have different addressing capabilities. In this multiple
|
||||
GPU scenario, other solutions could needlessly impact the GPU that
|
||||
has larger addressing capabilities.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Configure the system's IOMMU to the GPU's addressing
|
||||
capabilities.</p>
|
||||
<p>This is a solution targeted at developers and system builders.
|
||||
The use of IOMMU may be an option, depending on system
|
||||
configuration and IOMMU capabilities. Please contact NVIDIA to
|
||||
discuss solutions for specific configurations.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Limit the amount of memory seen by the Operating System to match
|
||||
your GPU's addressing capabilities with kernel configuration.</p>
|
||||
<p>This is best used in the scenario where RAM is mapped to
|
||||
addresses that slightly exceeds a GPU's capabilities and other
|
||||
solutions are either not achievable or more intrusive. A good
|
||||
example is the 512 GB RAM scenario outlined above with a GPU
|
||||
capable of addressing 512 GB. The kernel parameter can be used to
|
||||
ignore the RAM mapped above 512 GB.</p>
|
||||
<p>This can be achieved in Linux by use of the "mem" kernel
|
||||
parameter. See the kernel-parameters.txt documentation for more
|
||||
details on this parameter.</p>
|
||||
<p>This solution does affect the entire system and will limit how
|
||||
much memory the OS and other devices can use. In scenarios where
|
||||
there is a large discrepancy between the system configuration and
|
||||
GPU capabilities, this is not a desirable solution.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Remove RAM from the system to align with the GPU's addressing
|
||||
capabilities.</p>
|
||||
<p>This is the most heavy-handed, but may ultimately be the most
|
||||
reliable solution.</p>
|
||||
</li>
|
||||
</ol>
|
||||
</div>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"gbm.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"nvidia-peermem.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">Chapter 40. GBM
|
||||
and GBM-based Wayland Compositors </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 42. GPUDirect RDMA Peer Memory Client</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,167 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 45. NVIDIA Contact Info and Additional
|
||||
Resources</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="kernel_open.html" title=
|
||||
"Chapter 44. Open Linux Kernel Modules">
|
||||
<link rel="next" href="acknowledgements.html" title=
|
||||
"Chapter 46. Acknowledgements">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 45. NVIDIA Contact
|
||||
Info and Additional Resources</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"kernel_open.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"acknowledgements.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="addtlresources" id=
|
||||
"addtlresources"></a>Chapter 45. NVIDIA Contact Info and
|
||||
Additional Resources</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<h3>General Support</h3>
|
||||
<p>There is an NVIDIA Linux Driver web forum. You can access it by
|
||||
going to <a href="http://forums.developer.nvidia.com" target=
|
||||
"_top">http://forums.developer.nvidia.com</a> and following the
|
||||
"Linux" link in the “<span class="quote">GPU Unix
|
||||
Graphics</span>” section. This is the preferable tool for
|
||||
seeking help; users can post questions, answer other users'
|
||||
questions, and search the archives of previous postings.</p>
|
||||
<p>If all else fails, you can contact NVIDIA for support at:
|
||||
<code class="email"><<a href=
|
||||
"mailto:linux-bugs@nvidia.com">linux-bugs@nvidia.com</a>></code>.
|
||||
But please, only send email to this address after you have explored
|
||||
the <a href="faq.html">Frequently Asked Questions</a> and <a href=
|
||||
"commonproblems.html">Common Problems</a> chapters of this
|
||||
document, and asked for help on the forums.developer.nvidia.com web
|
||||
forum. When emailing <code class="email"><<a href=
|
||||
"mailto:linux-bugs@nvidia.com">linux-bugs@nvidia.com</a>></code>,
|
||||
please include the <code class=
|
||||
"filename">nvidia-bug-report.log.gz</code> file generated by the
|
||||
<span><strong class="command">nvidia-bug-report.sh</strong></span>
|
||||
script (which is installed as part of driver installation), along
|
||||
with a detailed description of your problem.</p>
|
||||
<h3>Security Issues</h3>
|
||||
<p>To report a potential security vulnerability in any NVIDIA
|
||||
product, please use either:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>this web form: <a href=
|
||||
"https://www.nvidia.com/object/submit-security-vulnerability.html"
|
||||
target="_top">Security Vulnerability Submission Form</a>, or</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>send email to: psirt@nvidia.com</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
<p>If reporting a potential vulnerability via email, please encrypt
|
||||
it using NVIDIA's public PGP key (see <a href=
|
||||
"https://www.nvidia.com/en-us/security/pgp-key/" target="_top">PGP
|
||||
Key page</a>) and include the following information:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>Product/Driver name and version/branch that contains the
|
||||
vulnerability</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Type of vulnerability (code execution, denial of service, buffer
|
||||
overflow, etc.)</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Instructions to reproduce the vulnerability</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Proof-of-concept or exploit code</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Potential impact of the vulnerability, including how an attacker
|
||||
could exploit the vulnerability</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
<h3>Additional Resources</h3>
|
||||
<div class="variablelist">
|
||||
<dl>
|
||||
<dt><span class="term">Linux OpenGL ABI</span></dt>
|
||||
<dd>
|
||||
<p><a href="http://www.opengl.org/registry/ABI/" target=
|
||||
"_top">http://www.opengl.org/registry/ABI/</a></p>
|
||||
</dd>
|
||||
<dt><span class="term">The X.Org Project</span></dt>
|
||||
<dd>
|
||||
<p><a href="https://www.x.org/" target=
|
||||
"_top">https://www.x.org/</a></p>
|
||||
</dd>
|
||||
<dt><span class="term">XFree86 Video Timings HOWTO</span></dt>
|
||||
<dd>
|
||||
<p><a href=
|
||||
"http://www.tldp.org/HOWTO/XFree86-Video-Timings-HOWTO/index.html"
|
||||
target=
|
||||
"_top">http://www.tldp.org/HOWTO/XFree86-Video-Timings-HOWTO/index.html</a></p>
|
||||
</dd>
|
||||
<dt><span class="term">The X.Org Foundation</span></dt>
|
||||
<dd>
|
||||
<p><a href="http://www.x.org/" target=
|
||||
"_top">http://www.x.org/</a></p>
|
||||
</dd>
|
||||
<dt><span class="term">OpenGL</span></dt>
|
||||
<dd>
|
||||
<p><a href="http://www.opengl.org/" target=
|
||||
"_top">http://www.opengl.org/</a></p>
|
||||
</dd>
|
||||
</dl>
|
||||
</div>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"kernel_open.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"acknowledgements.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 44. Open Linux Kernel Modules </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 46. Acknowledgements</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,144 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Part II. Appendices</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="prev" href="acknowledgements.html" title=
|
||||
"Chapter 46. Acknowledgements">
|
||||
<link rel="next" href="supportedchips.html" title=
|
||||
"Appendix A. Supported NVIDIA GPU Products">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Part II. Appendices</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"acknowledgements.html">Prev</a> </td>
|
||||
<th width="60%" align="center"> </th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"supportedchips.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="part" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h1 class="title"><a name="appendices" id=
|
||||
"appendices"></a>Appendices</h1>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="toc">
|
||||
<p><b>Table of Contents</b></p>
|
||||
<dl>
|
||||
<dt><span class="appendix"><a href="supportedchips.html">A.
|
||||
Supported NVIDIA GPU Products</a></span></dt>
|
||||
<dt><span class="appendix"><a href="xconfigoptions.html">B. X
|
||||
Config Options</a></span></dt>
|
||||
<dt><span class="appendix"><a href="displaydevicenames.html">C.
|
||||
Display Device Names</a></span></dt>
|
||||
<dt><span class="appendix"><a href="glxsupport.html">D. GLX
|
||||
Support</a></span></dt>
|
||||
<dt><span class="appendix"><a href="dpi.html">E. Dots Per
|
||||
Inch</a></span></dt>
|
||||
<dt><span class="appendix"><a href="i2c.html">F. i2c Bus
|
||||
Support</a></span></dt>
|
||||
<dt><span class="appendix"><a href="vdpausupport.html">G. VDPAU
|
||||
Support</a></span></dt>
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="section"><a href=
|
||||
"vdpausupport.html#vdpau-implementation-limits">Implementation
|
||||
Limits</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"vdpausupport.html#PerformanceLeve85af3">Performance
|
||||
Levels</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"vdpausupport.html#GettingTheBestP226a6">Getting the Best
|
||||
Performance from the API</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"vdpausupport.html#AdditionalNotescc912">Additional
|
||||
Notes</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"vdpausupport.html#DebuggingAndTra6efd2">Debugging and
|
||||
Tracing</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"vdpausupport.html#Multithreading13bf9">Multi-threading</a></span></dt>
|
||||
</dl>
|
||||
</dd>
|
||||
<dt><span class="appendix"><a href="audiosupport.html">H. Audio
|
||||
Support</a></span></dt>
|
||||
<dt><span class="appendix"><a href="newusertips.html">I. Tips for
|
||||
New Linux Users</a></span></dt>
|
||||
<dt><span class="appendix"><a href="profiles.html">J. Application
|
||||
Profiles</a></span></dt>
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="section"><a href=
|
||||
"profiles.html#Introductionec914">Introduction</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"profiles.html#EnablingApplicaba0fc">Enabling Application Profiles
|
||||
in the OpenGL Driver</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"profiles.html#ApplicationProf9ccbe">Application Profile Search
|
||||
Path</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"profiles.html#ConfigurationFi1ec50">Configuration File
|
||||
Syntax</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"profiles.html#ExtendedBackusn4e5af">Extended Backus-Naur Form
|
||||
(EBNF) grammar</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"profiles.html#RulePrecedence6f323">Rule Precedence</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"profiles.html#ConfigurationFie7ae2">Configuration File
|
||||
Example</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"profiles.html#SupportedFeatura8d39">Supported
|
||||
Features</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"profiles.html#ListOfSupportedd38df">List of supported application
|
||||
profile settings</a></span></dt>
|
||||
</dl>
|
||||
</dd>
|
||||
<dt><span class="appendix"><a href="gpunames.html">K. GPU
|
||||
Names</a></span></dt>
|
||||
<dt><span class="appendix"><a href="wayland-issues.html">L. Wayland
|
||||
Known Issues</a></span></dt>
|
||||
</dl>
|
||||
</div>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"acknowledgements.html">Prev</a> </td>
|
||||
<td width="20%" align="center"> </td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"supportedchips.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 46. Acknowledgements </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Appendix A. Supported NVIDIA GPU Products</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,75 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Appendix H. Audio Support</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="appendices.html" title=
|
||||
"Part II. Appendices">
|
||||
<link rel="prev" href="vdpausupport.html" title=
|
||||
"Appendix G. VDPAU Support">
|
||||
<link rel="next" href="newusertips.html" title=
|
||||
"Appendix I. Tips for New Linux Users">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Appendix H. Audio
|
||||
Support</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"vdpausupport.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part II. Appendices</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"newusertips.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="appendix" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="audiosupport" id=
|
||||
"audiosupport"></a>Appendix H. Audio Support</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>Many NVIDIA GPUs support embedding an audio stream in HDMI and
|
||||
DisplayPort signals. In most cases, the GPU contains a standard
|
||||
HD-Audio controller, for which there is a standard ALSA driver. For
|
||||
more details on how to configure and use the ALSA driver with
|
||||
NVIDIA hardware, please see <a href=
|
||||
"https://download.nvidia.com/XFree86/gpu-hdmi-audio-document/"
|
||||
target=
|
||||
"_top">https://download.nvidia.com/XFree86/gpu-hdmi-audio-document/</a>.</p>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"vdpausupport.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"appendices.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"newusertips.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Appendix G. VDPAU Support </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Appendix I. Tips for New Linux Users</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,158 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 16. Configuring a Notebook</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="xrandrextension.html" title=
|
||||
"Chapter 15. Support for the X Resize and Rotate Extension">
|
||||
<link rel="next" href="optimus.html" title=
|
||||
"Chapter 17. Using the NVIDIA Driver with Optimus Laptops">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 16. Configuring a
|
||||
Notebook</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"xrandrextension.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"optimus.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="configlaptop" id=
|
||||
"configlaptop"></a>Chapter 16. Configuring a
|
||||
Notebook</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<h3>Installation and configuration</h3>
|
||||
<p>Installation and configuration of the NVIDIA Linux Driver Set on
|
||||
a notebook is the same as for any desktop environment, with a few
|
||||
additions, as described below.</p>
|
||||
<h3>Power Management</h3>
|
||||
<p>All notebook NVIDIA GPUs support power management, both S3 (also
|
||||
known as "Standby" or "Suspend to RAM") and S4 (also known as
|
||||
"Hibernate", "Suspend to Disk" or "SWSUSP"). Power management is
|
||||
system-specific and is dependent upon all the components in the
|
||||
system; some systems may be more problematic than other
|
||||
systems.</p>
|
||||
<p>Most recent notebook NVIDIA GPUs also support PowerMizer, which
|
||||
monitors application work load to adjust system parameters to
|
||||
deliver the optimal balance of performance and battery life.
|
||||
However, PowerMizer is only enabled by default on some notebooks.
|
||||
Please see the known issues below for more details.</p>
|
||||
<h3>Hotkey Switching of Display Devices</h3>
|
||||
<p>Most laptops generate keyboard events when the display change
|
||||
hotkey is pressed. On some laptops, these are simply normal
|
||||
keyboard keys. On others, they generate ACPI events that may be
|
||||
translated into keyboard events by other system components.</p>
|
||||
<p>The NVIDIA driver does not handle ACPI display change hotkeys
|
||||
itself. Instead, it is expected for desktop environments to listen
|
||||
for these key-press events and respond by reconfiguring the display
|
||||
devices as necessary.</p>
|
||||
<h3>Docking Events</h3>
|
||||
<p>All notebook NVIDIA GPUs support docking, however support may be
|
||||
limited by the OS or system. There are three types of notebook
|
||||
docking (hot, warm, and cold), which refer to the state of the
|
||||
system when the docking event occurs. hot refers to a powered on
|
||||
system with a live desktop, warm refers to a system that has
|
||||
entered a suspended power management state, and cold refers to a
|
||||
system that has been powered off. Only warm and cold docking are
|
||||
supported by the NVIDIA driver.</p>
|
||||
<h3>Known Notebook Issues</h3>
|
||||
<p>There are a few known issues associated with notebooks:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>In many cases, suspending and/or resuming will fail. As
|
||||
mentioned above, this functionality is very system-specific. There
|
||||
are still many cases that are problematic. Here are some tips that
|
||||
may help:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="circle">
|
||||
<li>
|
||||
<p>In some cases, hibernation can have bad interactions with the
|
||||
PCI Express bus clocks, which can lead to system hangs when
|
||||
entering hibernation. This issue is still being investigated, but a
|
||||
known workaround is to leave an OpenGL application running when
|
||||
hibernating.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>On notebooks with relatively little system memory, repetitive
|
||||
hibernation attempts may fail due to insufficient free memory. This
|
||||
problem can be avoided by running `echo 0 >
|
||||
/sys/power/image_size`, which reduces the image size to be stored
|
||||
during hibernation.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Some distributions use a tool called vbetool to save and restore
|
||||
VGA adapter state. This tool is incompatible with NVIDIA GPUs'
|
||||
Video BIOSes and is likely to lead to problems restoring the GPU
|
||||
and its state. Disabling calls to this tool in your distribution's
|
||||
init scripts may improve power management reliability.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
</li>
|
||||
<li>
|
||||
<p>On some notebooks, PowerMizer is not enabled by default. This
|
||||
issue is being investigated, and there is no known workaround.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>When available, the NVIDIA driver installs a backlight handler
|
||||
that allows access to the driver's backlight controller through
|
||||
/sys/class/backlight/nvidia_0. This option can be disabled by
|
||||
passing the</p>
|
||||
<pre class="screen">
|
||||
NVreg_EnableBacklightHandler=0
|
||||
</pre>
|
||||
<p>parameter to the nvidia kernel module.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"xrandrextension.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"optimus.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 15. Support for the X Resize and Rotate
|
||||
Extension </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 17. Using the NVIDIA Driver with Optimus
|
||||
Laptops</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,142 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 14. Configuring Multiple X Screens on One
|
||||
Card</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="xineramaglx.html" title=
|
||||
"Chapter 13. Configuring GLX in Xinerama">
|
||||
<link rel="next" href="xrandrextension.html" title=
|
||||
"Chapter 15. Support for the X Resize and Rotate Extension">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 14. Configuring
|
||||
Multiple X Screens on One Card</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"xineramaglx.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"xrandrextension.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="configmultxscreens" id=
|
||||
"configmultxscreens"></a>Chapter 14. Configuring Multiple
|
||||
X Screens on One Card</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>GPUs that support TwinView (<a href="configtwinview.html" title=
|
||||
"Chapter 12. Configuring Multiple Display Devices on One X Screen">Chapter 12,
|
||||
<i>Configuring Multiple Display Devices on One X Screen</i></a>)
|
||||
can also be configured to treat each connected display device as a
|
||||
separate X screen.</p>
|
||||
<p>While there are several disadvantages to this approach as
|
||||
compared to TwinView (e.g.: windows cannot be dragged between X
|
||||
screens, hardware accelerated OpenGL cannot span the two X
|
||||
screens), it does offer one advantage over TwinView: If each
|
||||
display device is a separate X screen, then properties that may
|
||||
vary between X screens may vary between displays (e.g.: depth, root
|
||||
window size, etc).</p>
|
||||
<p>To configure two separate X screens to share one graphics card,
|
||||
here is what you will need to do:</p>
|
||||
<p>First, create two separate Device sections, each listing the
|
||||
BusID of the graphics card to be shared and listing the driver as
|
||||
"nvidia", and assign each a separate screen:</p>
|
||||
<pre class="screen">
|
||||
Section "Device"
|
||||
Identifier "nvidia0"
|
||||
Driver "nvidia"
|
||||
# Edit the BusID with the location of your graphics card
|
||||
BusID "PCI:2:0:0"
|
||||
Screen 0
|
||||
EndSection
|
||||
|
||||
Section "Device"
|
||||
Identifier "nvidia1"
|
||||
Driver "nvidia"
|
||||
# Edit the BusID with the location of your graphics card
|
||||
BusId "PCI:2:0:0"
|
||||
Screen 1
|
||||
EndSection
|
||||
</pre>
|
||||
<p>Then, create two Screen sections, each using one of the Device
|
||||
sections:</p>
|
||||
<pre class="screen">
|
||||
Section "Screen"
|
||||
Identifier "Screen0"
|
||||
Device "nvidia0"
|
||||
Monitor "Monitor0"
|
||||
DefaultDepth 24
|
||||
Subsection "Display"
|
||||
Depth 24
|
||||
Modes "1600x1200" "1024x768" "800x600" "640x480"
|
||||
EndSubsection
|
||||
EndSection
|
||||
|
||||
Section "Screen"
|
||||
Identifier "Screen1"
|
||||
Device "nvidia1"
|
||||
Monitor "Monitor1"
|
||||
DefaultDepth 24
|
||||
Subsection "Display"
|
||||
Depth 24
|
||||
Modes "1600x1200" "1024x768" "800x600" "640x480"
|
||||
EndSubsection
|
||||
EndSection
|
||||
</pre>
|
||||
<p>(Note: You'll also need to create a second Monitor section)
|
||||
Finally, update the ServerLayout section to use and position both
|
||||
Screen sections:</p>
|
||||
<pre class="screen">
|
||||
Section "ServerLayout"
|
||||
...
|
||||
Screen 0 "Screen0"
|
||||
Screen 1 "Screen1" leftOf "Screen0"
|
||||
...
|
||||
EndSection
|
||||
</pre>
|
||||
<p>For further details, refer to the xorg.conf man page.</p>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"xineramaglx.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"xrandrextension.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 13. Configuring GLX in Xinerama </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 15. Support for the X Resize and Rotate
|
||||
Extension</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,773 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 12. Configuring Multiple Display Devices
|
||||
on One X Screen</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="openglenvvariables.html" title=
|
||||
"Chapter 11. Specifying OpenGL Environment Variable Settings">
|
||||
<link rel="next" href="xineramaglx.html" title=
|
||||
"Chapter 13. Configuring GLX in Xinerama">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 12. Configuring
|
||||
Multiple Display Devices on One X Screen</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"openglenvvariables.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"xineramaglx.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="configtwinview" id=
|
||||
"configtwinview"></a>Chapter 12. Configuring Multiple
|
||||
Display Devices on One X Screen</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>Multiple display devices (digital flat panels, CRTs, and TVs)
|
||||
can display the contents of a single X screen in any arbitrary
|
||||
configuration. Configuring multiple display devices on a single X
|
||||
screen has several distinct advantages over other techniques (such
|
||||
as Xinerama):</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>A single X screen is used. The NVIDIA driver conceals all
|
||||
information about multiple display devices from the X server; as
|
||||
far as X is concerned, there is only one screen.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Both display devices share one frame buffer. Thus, all the
|
||||
functionality present on a single display (e.g., accelerated
|
||||
OpenGL) is available with multiple display devices.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>No additional overhead is needed to emulate having a single
|
||||
desktop.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p>If you are interested in using each display device as a separate
|
||||
X screen, see <a href="configmultxscreens.html" title=
|
||||
"Chapter 14. Configuring Multiple X Screens on One Card">Chapter 14,
|
||||
<i>Configuring Multiple X Screens on One Card</i></a>.</p>
|
||||
<h3>Relevant X Configuration Options</h3>
|
||||
<p>When the NVIDIA X driver starts, by default it will enable as
|
||||
many display devices as are connected and as the GPU supports
|
||||
driving simultaneously. Most NVIDIA GPUs support driving up to four
|
||||
display devices simultaneously.</p>
|
||||
<p>If multiple X screens are configured on the GPU, the NVIDIA X
|
||||
driver will attempt to reserve display devices and GPU resources
|
||||
for those other X screens (honoring the "UseDisplayDevice" and
|
||||
"MetaModes" X configuration options of each X screen) and then
|
||||
allocate all remaining resources to the first X screen configured
|
||||
on the GPU.</p>
|
||||
<p>There are several X configuration options that influence how
|
||||
multiple display devices are used by an X screen:</p>
|
||||
<pre class="screen">
|
||||
Option "MetaModes" "<list of MetaModes>"
|
||||
|
||||
Option "HorizSync" "<hsync range(s)>"
|
||||
Option "VertRefresh" "<vrefresh range(s)>"
|
||||
|
||||
Option "MetaModeOrientation" "<relationship of head 1 to head 0>"
|
||||
Option "ConnectedMonitor" "<list of connected display devices>"
|
||||
</pre>
|
||||
<p>See detailed descriptions of each option below.</p>
|
||||
<h3>Detailed Description of Options</h3>
|
||||
<div class="variablelist">
|
||||
<dl>
|
||||
<dt><span class="term">HorizSync,</span> <span class=
|
||||
"term">VertRefresh</span></dt>
|
||||
<dd>
|
||||
<p>With these options, you can specify a semicolon-separated list
|
||||
of frequency ranges, each optionally prepended with a display
|
||||
device name. In addition, if SLI Mosaic mode is enabled, a GPU
|
||||
specifier can be used. For example:</p>
|
||||
<pre class="screen">
|
||||
Option "HorizSync" "CRT-0: 50-110; DFP-0: 40-70"
|
||||
Option "VertRefresh" "CRT-0: 60-120; GPU-0.DFP-0: 60"
|
||||
</pre>
|
||||
<p>See <a href="displaydevicenames.html" title=
|
||||
"Appendix C. Display Device Names">Appendix C,
|
||||
<i>Display Device Names</i></a> on Display Device Names for more
|
||||
information.</p>
|
||||
<p>These options are normally not needed: by default, the NVIDIA X
|
||||
driver retrieves the valid frequency ranges from the display
|
||||
device's EDID (see the <a href=
|
||||
"xconfigoptions.html#UseEdidFreqs">UseEdidFreqs</a> option). The
|
||||
"HorizSync" and "VertRefresh" options override any frequency ranges
|
||||
retrieved from the EDID.</p>
|
||||
</dd>
|
||||
<dt><a name="metamodes" id="metamodes"></a><span class=
|
||||
"term">MetaModes</span></dt>
|
||||
<dd>
|
||||
<p>MetaModes are "containers" that store information about what
|
||||
mode should be used on each display device.</p>
|
||||
<p>Multiple MetaModes list the combinations of modes and the
|
||||
sequence in which they should be used. In MetaMode syntax, modes
|
||||
within a MetaMode are comma separated, and multiple MetaModes are
|
||||
separated by semicolons. For example:</p>
|
||||
<pre class="screen">
|
||||
"<mode name 0>, <mode name 1>; <mode name 2>, <mode name 3>"
|
||||
</pre>
|
||||
<p>Where <mode name 0> is the name of the mode to be used on
|
||||
display device 0 concurrently with <mode name 1> used on
|
||||
display device 1. A mode switch will then cause <mode name 2>
|
||||
to be used on display device 0 and <mode name 3> to be used
|
||||
on display device 1. Here is an example MetaMode:</p>
|
||||
<pre class="screen">
|
||||
Option "MetaModes" "1280x1024,1280x1024; 1024x768,1024x768"
|
||||
</pre>
|
||||
<p>If you want a display device to not be active for a certain
|
||||
MetaMode, you can use the mode name "NULL", or simply omit the mode
|
||||
name entirely:</p>
|
||||
<pre class="screen">
|
||||
"1600x1200, NULL; NULL, 1024x768"
|
||||
</pre>
|
||||
<p>or</p>
|
||||
<pre class="screen">
|
||||
"1600x1200; , 1024x768"
|
||||
</pre>
|
||||
<p>Optionally, mode names can be followed by offset information to
|
||||
control the positioning of the display devices within the virtual
|
||||
screen space; e.g.,</p>
|
||||
<pre class="screen">
|
||||
"1600x1200 +0+0, 1024x768 +1600+0; ..."
|
||||
</pre>
|
||||
<p>Offset descriptions follow the conventions used in the X
|
||||
"-geometry" command line option; i.e., both positive and negative
|
||||
offsets are valid, though negative offsets are only allowed when a
|
||||
virtual screen size is explicitly given in the X config file.</p>
|
||||
<p>When no offsets are given for a MetaMode, the offsets will be
|
||||
computed following the value of the MetaModeOrientation option (see
|
||||
below). Note that if offsets are given for any one of the modes in
|
||||
a single MetaMode, then offsets will be expected for all modes
|
||||
within that single MetaMode; in such a case offsets will be assumed
|
||||
to be +0+0 when not given.</p>
|
||||
<p>When not explicitly given, the virtual screen size will be
|
||||
computed as the bounding box of all MetaMode bounding boxes.
|
||||
MetaModes with a bounding box larger than an explicitly given
|
||||
virtual screen size will be discarded.</p>
|
||||
<p>A MetaMode string can be further modified with a "Panning
|
||||
Domain" specification; e.g.,</p>
|
||||
<pre class="screen">
|
||||
"1024x768 @1600x1200, 800x600 @1600x1200"
|
||||
</pre>
|
||||
<p>A panning domain is the area in which a display device's
|
||||
viewport will be panned to follow the mouse. Panning actually
|
||||
happens on two levels with MetaModes: first, an individual display
|
||||
device's viewport will be panned within its panning domain, as long
|
||||
as the viewport is contained by the bounding box of the MetaMode.
|
||||
Once the mouse leaves the bounding box of the MetaMode, the entire
|
||||
MetaMode (i.e., all display devices) will be panned to follow the
|
||||
mouse within the virtual screen, unless the "PanAllDisplays" X
|
||||
configuration option is disabled. Note that individual display
|
||||
devices' panning domains default to being clamped to the position
|
||||
of the display devices' viewports, thus the default behavior is
|
||||
just that viewports remain "locked" together and only perform the
|
||||
second type of panning.</p>
|
||||
<p>The most beneficial use of panning domains is probably to
|
||||
eliminate dead areas -- regions of the virtual screen that are
|
||||
inaccessible due to display devices with different resolutions. For
|
||||
example:</p>
|
||||
<pre class="screen">
|
||||
"1600x1200, 1024x768"
|
||||
</pre>
|
||||
<p>produces an inaccessible region below the 1024x768 display.
|
||||
Specifying a panning domain for the second display device:</p>
|
||||
<pre class="screen">
|
||||
"1600x1200, 1024x768 @1024x1200"
|
||||
</pre>
|
||||
<p>provides access to that dead area by allowing you to pan the
|
||||
1024x768 viewport up and down in the 1024x1200 panning domain.</p>
|
||||
<p>Offsets can be used in conjunction with panning domains to
|
||||
position the panning domains in the virtual screen space (note that
|
||||
the offset describes the panning domain, and only affects the
|
||||
viewport in that the viewport must be contained within the panning
|
||||
domain). For example, the following describes two modes, each with
|
||||
a panning domain width of 1900 pixels, and the second display is
|
||||
positioned below the first:</p>
|
||||
<pre class="screen">
|
||||
"1600x1200 @1900x1200 +0+0, 1024x768 @1900x768 +0+1200"
|
||||
</pre>
|
||||
<p>Because it is often unclear which mode within a MetaMode will be
|
||||
used on each display device, mode descriptions within a MetaMode
|
||||
can be prepended with a display device name. For example:</p>
|
||||
<pre class="screen">
|
||||
"CRT-0: 1600x1200, DFP-0: 1024x768"
|
||||
</pre>
|
||||
<p>If no MetaMode string is specified, then the X driver uses the
|
||||
modes listed in the relevant "Display" subsection, attempting to
|
||||
place matching modes on each display device.</p>
|
||||
<p>Each mode of the MetaMode may also have extra attributes
|
||||
associated with it, specified as a comma-separated list of
|
||||
token=value pairs inside curly brackets. The value for each token
|
||||
can optionally be enclosed in parentheses, to prevent commas within
|
||||
the value from being interpreted as token=value pair separators.
|
||||
Currently, the only token that requires a parentheses-enclosed
|
||||
value is "Transform".</p>
|
||||
<p>The possible tokens within the curly bracket list are:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>"Stereo": possible values are "PassiveLeft" or "PassiveRight".
|
||||
When used in conjunction with stereo mode "4", this allows each
|
||||
display to be configured independently to show any stereo eye. For
|
||||
example:</p>
|
||||
<pre class="screen">
|
||||
"CRT-0: 1600x1200 +0+0 { Stereo = PassiveLeft }, CRT-1: 1600x1200 +1600+0 { Stereo=PassiveRight }"
|
||||
</pre>
|
||||
<p>If the X screen is not configured for stereo mode "4", these
|
||||
options are ignored. See the <a href=
|
||||
"xconfigoptions.html#Stereo">Stereo</a> X configuration option for
|
||||
more details about stereo configurations.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"Rotation": this rotates the content of an individual display
|
||||
device. Possible values are "0" (with synonyms "no", "off" and
|
||||
"normal"), "90" (with synonyms "left" and "CCW"), "180" (with
|
||||
synonyms "invert" and "inverted") and "270" (with synonyms "right"
|
||||
and "CW"). For example:</p>
|
||||
<pre class="screen">
|
||||
"DFP-0: nvidia-auto-select { Rotation=left }, DFP-1: nvidia-auto-select { Rotation=right }"
|
||||
</pre>
|
||||
<p>Independent rotation configurability of each display device is
|
||||
also possible through RandR. See <a href="xrandrextension.html"
|
||||
title=
|
||||
"Chapter 15. Support for the X Resize and Rotate Extension">
|
||||
Chapter 15, <i>Support for the X Resize and Rotate
|
||||
Extension</i></a> for details.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"Reflection": this reflects the content of an individual display
|
||||
device about either the X axis, the Y axis, or both the X and Y
|
||||
axes. Possible values are "X", "Y" and "XY". For example:</p>
|
||||
<pre class="screen">
|
||||
"DFP-0: nvidia-auto-select { Reflection=X }, DFP-1: nvidia-auto-select"
|
||||
</pre>
|
||||
<p>Independent reflection configurability of each display device is
|
||||
also possible through RandR. See <a href="xrandrextension.html"
|
||||
title=
|
||||
"Chapter 15. Support for the X Resize and Rotate Extension">
|
||||
Chapter 15, <i>Support for the X Resize and Rotate
|
||||
Extension</i></a> for details.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"Transform": this is a 3x3 matrix of floating point values that
|
||||
defines a transformation from the ViewPortOut for a display device
|
||||
to a region within the X screen. This is equivalent to the
|
||||
transformation matrix specified through the RandR 1.3
|
||||
RRSetCrtcTransform request. As in RandR, the transform is applied
|
||||
before any specified rotation and reflection values to compute the
|
||||
complete transform.</p>
|
||||
<p>The 3x3 matrix is represented in the MetaMode syntax as a
|
||||
comma-separated list of nine floating point values, stored in
|
||||
row-major order. This is the same as the value passed to the
|
||||
xrandr(1) '--transform' command line option.</p>
|
||||
<p>Note that the transform value must be enclosed in parentheses,
|
||||
so that the commas separating the nine floating point values are
|
||||
interpreted correctly.</p>
|
||||
<p>For example:</p>
|
||||
<pre class="screen">
|
||||
"DFP-0: nvidia-auto-select { Transform=(43.864288330078125, 21.333328247070312, -16384, 0, 43.864288330078125, 0, 0, 0.0321197509765625, 19.190628051757812) }"
|
||||
</pre>
|
||||
<p></p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"PixelShiftMode": This allows a display to be configured in
|
||||
pixel shift mode, in which a display overlays multiple downscaled
|
||||
images to simulate a higher effective resolution. This is used in
|
||||
certain JVC e-shift projectors. All pixel shift modes require an
|
||||
NVIDIA RTX/Quadro GPU. Possible values are "4kTopLeft",
|
||||
"4kBottomRight", and "8k".</p>
|
||||
<p>In 4K pixel shift mode, two cloned displays are configured in
|
||||
pixel shift mode, and either display is configured to display
|
||||
either the top left or bottom right pixels of every pixel quad.
|
||||
Note that the mode timings used by each display are one quarter of
|
||||
the resolution read from the X screen and one quarter of the
|
||||
effective resolution displayed (e.g., "1920x1080" rather than
|
||||
"3840x2160").</p>
|
||||
<p>For example, here is the configuration of a 4K pixel shift mode,
|
||||
with an effective desktop resolution of 3840x2160:</p>
|
||||
<pre class="screen">
|
||||
"DFP-0: 1920x1080 +0+0 { PixelShiftMode = 4kTopLeft, ViewPortIn = 3840x2160 }, DFP-1: 1920x1080 +0+0 { PixelShiftMode = 4kBottomRight, ViewPortIn = 3840x2160 }"
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>In 8K pixel shift mode, the image is downscaled from the
|
||||
ViewPortIn resolution to the mode timing resolution, to produce two
|
||||
different images: one for the top left pixel of every pixel quad
|
||||
and one for the bottom right of every pixel quad. The display
|
||||
alternates between the two images each vblank. This requires an
|
||||
NVIDIA RTX/Quadro graphics card with a 3-pin DIN stereo
|
||||
connector.</p>
|
||||
<p>For example, here is the configuration for an 8K pixel shift
|
||||
mode, with an effective desktop resolution and refresh rate of
|
||||
8192x4800 @30Hz, split across 4 1024x2400@60Hz displays. Note that
|
||||
the panning offsets of each display are in X screen (ViewPortIn)
|
||||
coordinates:</p>
|
||||
<pre class="screen">
|
||||
"DFP-0: 1024x2400 +0+0 { PixelShiftMode=8k, ViewPortIn = 2048x4800 }, DFP-1: 1024x2400 +2048+0 { PixelShiftMode=8k, ViewPortIn = 2048x4800 }, DFP-2: 1024x2400 +4096+0 { PixelShiftMode=8k, ViewPortIn = 2048x4800 }, DFP-4: 1024x2400 +6144+0 { PixelShiftMode=8k, ViewPortIn = 2048x4800 }"
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>In both examples above, the ViewPortIn is provided here for
|
||||
illustrative purposes only. When PixelShiftMode is used, the
|
||||
ViewPortIn and ViewPortOut are always inferred from the mode
|
||||
timings: the ViewPortOut will match the mode timing resolution,
|
||||
which is half the intended resolution. The ViewPortIn will be twice
|
||||
the ViewPortOut, in order to achieve the pixel shift effect.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"ViewPortOut": this specifies the region within the mode sent to
|
||||
the display device that will display pixels from the X screen. The
|
||||
region of the mode outside the ViewPortOut will contain black. The
|
||||
format is "WIDTH x HEIGHT +X +Y".</p>
|
||||
<p>This is useful, for example, for configuring overscan
|
||||
compensation. E.g., if the mode sent to the display device is
|
||||
1920x1080, to configure a 10 pixel border on all four sides:</p>
|
||||
<pre class="screen">
|
||||
"DFP-0: 1920x1080 { ViewPortOut=1900x1060+10+10 }"
|
||||
</pre>
|
||||
<p>Or, to only display an image in the lower right quarter of the
|
||||
1920x1080 mode:</p>
|
||||
<pre class="screen">
|
||||
"DFP-0: 1920x1080 { ViewPortOut=960x540+960+540 }"
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>When not specified, the ViewPortOut defaults to the size of the
|
||||
mode.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"ViewPortIn": this defines the size of the region of the X
|
||||
screen which will be displayed within the ViewPortOut. The format
|
||||
is "WIDTH x HEIGHT".</p>
|
||||
<p>ViewPortIn is useful for configuring scaling between the X
|
||||
screen and the display device. For example, to display an 800x600
|
||||
region from the X screen on a 1920x1200 mode:</p>
|
||||
<pre class="screen">
|
||||
"DFP-0: 1920x1200 { ViewPortIn=800x600 }"
|
||||
</pre>
|
||||
<p>Or, to display a 2560x1600 region from the X screen on a
|
||||
1920x1200 mode:</p>
|
||||
<pre class="screen">
|
||||
"DFP-0: 1920x1200 { ViewPortIn=2560x1600 }"
|
||||
</pre>
|
||||
<p>Or, in conjunction with ViewPortOut, to scale an 800x600 region
|
||||
of the X screen within a 1920x1200 mode while preserving the aspect
|
||||
ratio:</p>
|
||||
<pre class="screen">
|
||||
"DFP-0: 1920x1200 { ViewPortIn=800x600, ViewPortOut=1600x1200+160+0 }"
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>Scaling from ViewPortIn to ViewPortOut is also expressible
|
||||
through the "Transform" attribute. In fact, ViewPortIn is just a
|
||||
shortcut for populating the transformation matrix. If both
|
||||
ViewPortIn and Transform are specified in the MetaMode for a
|
||||
display device, ViewPortIn is ignored.</p>
|
||||
<p>ViewPortIn is also ignored if PixelShiftMode is enabled, as
|
||||
PixelShiftMode implies a transformation of double width and
|
||||
height.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"PanningTrackingArea": this defines the region of the MetaMode
|
||||
inside which cursor movement will influence panning of the display
|
||||
device. The format is "WIDTH x HEIGHT + X + Y", to describe the
|
||||
size and offset of the region within the X screen. E.g.,</p>
|
||||
<pre class="screen">
|
||||
"DFP-0: 1920x1200 +0+0 { PanningTrackingArea = 1920x1200 +0+0 }"
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>If not specified in the MetaMode, this will default to the
|
||||
entire X screen. If the <a href=
|
||||
"xconfigoptions.html#PanAllDisplays">PanAllDisplays</a> X
|
||||
configuration option is explicitly set to False, then
|
||||
PanningTrackingArea will default to the panning domain of the
|
||||
display device.</p>
|
||||
<p>This is equivalent to the panning tracking_area region in the
|
||||
RRSetPanning RandR 1.3 protocol request.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"PanningBorder": this defines the distances from the edges of
|
||||
the ViewPortIn that will activate panning if the pointer hits them.
|
||||
If the borders are 0, the display device will pan when the pointer
|
||||
hits the edge of the ViewPortIn (the default). If the borders are
|
||||
positive, the display device will pan when the pointer gets close
|
||||
to the edge of the ViewPortIn. If the borders are negative, the
|
||||
display device will pan when the pointer is beyond the edge of the
|
||||
ViewPortIn.</p>
|
||||
<p>The format is "LeftBorder/TopBorder/RightBorder/BottomBorder".
|
||||
E.g.,</p>
|
||||
<pre class="screen">
|
||||
"DFP-0: 1920x1200 +0+0 { PanningBorder = 10/10/10/10 }"
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>This is equivalent to the panning border in the RRSetPanning
|
||||
RandR 1.3 protocol request.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"ForceCompositionPipeline": possible values are "On" or "Off".
|
||||
The NVIDIA X driver can use a composition pipeline to apply X
|
||||
screen transformations and rotations. "ForceCompositionPipeline"
|
||||
can be used to force the use of this pipeline, even when no
|
||||
transformations or rotations are applied to the screen.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"ForceFullCompositionPipeline": possible values are "On" or
|
||||
"Off". This option implicitly enables "ForceCompositionPipeline"
|
||||
and additionally makes use of the composition pipeline to apply
|
||||
ViewPortOut scaling.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"WarpMesh", "BlendTexture", "OffsetTexture": these string
|
||||
attributes control the operation of Warp and Blend, an advanced
|
||||
transformation feature available on select NVIDIA RTX/Quadro GPUs.
|
||||
Warp and Blend can adjust a display's geometry (warp) with a
|
||||
greater level of control than a simple matrix transformation: for
|
||||
example, to facilitate projecting an image onto a non-planar
|
||||
surface, and its intensity (blend) per pixel: for example, to
|
||||
seamlessly combine images from multiple overlapping projectors into
|
||||
a single large image. Each of the "WarpMesh", "BlendTexture", and
|
||||
"OffsetTexture" MetaMode tokens can be set to the name of a pixmap
|
||||
which has already been bound to a name via the
|
||||
XNVCtrlBindWarpPixmapName() NV_CONTROL call. See the <code class=
|
||||
"filename">nv-control-warpblend</code> sample application
|
||||
distributed with the <span><strong class=
|
||||
"command">nvidia-settings</strong></span> source code for a more
|
||||
detailed description of the functionality of each of these pixmaps,
|
||||
how to lay data out into the pixmaps, and an example implementation
|
||||
of an X application that loads and binds pixmaps so that they are
|
||||
ready to use in a MetaMode.</p>
|
||||
<p>If driving the current mode in the RGB 4:4:4 color space would
|
||||
require a pixel clock that exceeds the display's or GPU's
|
||||
capabilities, and the display and GPU are capable of driving that
|
||||
mode in the YCbCr 4:2:0 color space, then the color space will be
|
||||
overridden to YCbCr 4:2:0. In this case, if a Turing or earlier GPU
|
||||
is in use, or if a DisplayPort display device is in use regardless
|
||||
of GPU, then Warp and Blend will be disabled.</p>
|
||||
<p>Warp and Blend is not yet supported with the GLX_NV_swap_group
|
||||
OpenGL extension.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"BlendOrder": Controls the order of warping and blending when
|
||||
using Warp and Blend. By default, warping is performed first,
|
||||
followed by blending; setting the "BlendOrder" MetaMode token to
|
||||
"BlendAfterWarp" will reverse the default order.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"ResamplingMethod": Controls the filtering method used to smooth
|
||||
the display image when scaling screen transformations (such as a
|
||||
WarpMesh or scaling ViewPortOut) are in use. Possible values are
|
||||
"Bilinear" (default), "BicubicTriangular", "BicubicBellShaped",
|
||||
"BicubicBspline", "BicubicAdaptiveTriangular",
|
||||
"BicubicAdaptiveBellShaped", "BicubicAdaptiveBspline", and
|
||||
"Nearest".</p>
|
||||
<p>Bicubic resampling is only available on NVIDIA RTX/Quadro GPUs.
|
||||
If a mode requiring a YCbCr 4:2:0 color space is in use on a
|
||||
DisplayPort display device or a Turing or earlier GPU, then bicubic
|
||||
resampling is unavailable. Bicubic resampling is not supported with
|
||||
the GLX_NV_swap_group OpenGL extension.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"AllowGSYNC" or "AllowGSYNCCompatible": Controls whether capable
|
||||
monitors are put into G-SYNC or G-SYNC Compatible mode or left in
|
||||
continuous refresh mode.</p>
|
||||
<p>By default, G-SYNC monitors are put into G-SYNC mode when a mode
|
||||
is set, and transition into and out of variable refresh mode
|
||||
seamlessly. However, this prevents certain other features, such as
|
||||
Ultra Low Motion Blur and Frame Lock, from working. Set this to
|
||||
"Off" to use continuous refresh rates that are compatible with
|
||||
these features.</p>
|
||||
<p>In addition, G-SYNC Compatible monitors are supported via
|
||||
DisplayPort on Pascal and newer GPUs, and via HDMI on Turing and
|
||||
newer GPUs. Supported monitors will enable variable refresh mode by
|
||||
default. This behavior may be overridden by setting the
|
||||
AllowGSYNCCompatible=Off MetaMode attribute. Pascal GPUs only
|
||||
support G-SYNC Compatible monitors in systems containing no more
|
||||
than one monitor in variable refresh mode. Monitors that have not
|
||||
been validated as G-SYNC Compatible have G-SYNC Compatible mode
|
||||
disabled by default, and can be forced into G-SYNC Compatible mode
|
||||
by setting the AllowGSYNCCompatible=On MetaMode attribute. A list
|
||||
of supported G-SYNC and G-SYNC Compatible monitors can be found at
|
||||
<a href=
|
||||
"https://www.nvidia.com/en-us/geforce/products/g-sync-monitors/specs/"
|
||||
target=
|
||||
"_top">https://www.nvidia.com/en-us/geforce/products/g-sync-monitors/specs/</a></p>
|
||||
<p>Note: Vulkan direct-to-display applications may allow or
|
||||
disallow G-SYNC or G-SYNC Compatible at modeset time using the
|
||||
VKDirectGSYNCAllowed and VKDirectGSYNCCompatibleAllowed environment
|
||||
variables. VKDirectGSYNCAllowed is set to true by default (allowing
|
||||
VRR on all G-SYNC monitors) and VKDirectGSYNCCompatibleAllowed may
|
||||
be set to 0 (disallowing VRR on all G-SYNC Compatible monitors), 1
|
||||
(default, allowing VRR only on monitors validated as G-SYNC
|
||||
Compatible), or 2 (allowing VRR regardless of whether a monitor has
|
||||
been validated as G-SYNC Compatible).</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"VRRMinRefreshRate": Overrides a G-SYNC Compatible monitor's
|
||||
minimum refresh rate. Some monitors that have not been validated as
|
||||
G-SYNC Compatible may flicker when applications are swapping close
|
||||
to the monitor's minimum refresh rate, and this MetaMode flag may
|
||||
be used to compensate for this. This MetaMode flag has no effect on
|
||||
G-SYNC monitors.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p>Note that the current MetaMode can also be configured through
|
||||
the NV-CONTROL X extension and the nvidia-settings utility. For
|
||||
example:</p>
|
||||
<pre class="screen">
|
||||
nvidia-settings --assign CurrentMetaMode="DFP-0: 1920x1200 { ViewPortIn=800x600, ViewPortOut=1600x1200+160+0 }"
|
||||
</pre>
|
||||
<p></p>
|
||||
</dd>
|
||||
<dt><span class="term">MetaModeOrientation</span></dt>
|
||||
<dd>
|
||||
<p>This option controls the positioning of the display devices
|
||||
within the virtual X screen, when offsets are not explicitly given
|
||||
in the MetaModes. The possible values are:</p>
|
||||
<pre class="screen">
|
||||
"RightOf" (the default)
|
||||
"LeftOf"
|
||||
"Above"
|
||||
"Below"
|
||||
"SamePositionAs"
|
||||
</pre>
|
||||
<p>When "SamePositionAs" is specified, all display devices will be
|
||||
assigned an offset of 0,0. For backwards compatibility, "Clone" is
|
||||
a synonym for "SamePositionAs".</p>
|
||||
<p>Because it is often unclear which display device relates to
|
||||
which, MetaModeOrientation can be confusing. You can further
|
||||
clarify the MetaModeOrientation with display device names to
|
||||
indicate which display device is positioned relative to which
|
||||
display device. For example:</p>
|
||||
<pre class="screen">
|
||||
"CRT-0 LeftOf DFP-0"
|
||||
</pre>
|
||||
<p></p>
|
||||
</dd>
|
||||
<dt><span class="term">ConnectedMonitor</span></dt>
|
||||
<dd>
|
||||
<p>With this option you can override what the NVIDIA kernel module
|
||||
detects is connected to your graphics card. This may be useful, for
|
||||
example, if any of your display devices do not support detection
|
||||
using Display Data Channel (DDC) protocols. Valid values are a
|
||||
comma-separated list of display device names; for example:</p>
|
||||
<pre class="screen">
|
||||
"CRT-0, CRT-1"
|
||||
"CRT"
|
||||
"CRT-1, DFP-0"
|
||||
</pre>
|
||||
<p>WARNING: this option overrides what display devices are detected
|
||||
by the NVIDIA kernel module, and is very seldom needed. You really
|
||||
only need this if a display device is not detected, either because
|
||||
it does not provide DDC information, or because it is on the other
|
||||
side of a KVM (Keyboard-Video-Mouse) switch. In most other cases,
|
||||
it is best not to specify this option.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
</div>
|
||||
<p>Just as in all X config entries, spaces are ignored and all
|
||||
entries are case insensitive.</p>
|
||||
<div class="qandaset">
|
||||
<table border="0" summary="Q and A Set">
|
||||
<col align="left" width="1%">
|
||||
<tbody>
|
||||
<tr class="qandadiv">
|
||||
<td align="left" valign="top" colspan="2"><a name=
|
||||
"FrequentlyAsked7a5bb" id="FrequentlyAsked7a5bb"></a>
|
||||
<h3 class="title">12.1. Frequently Asked TwinView Questions</h3>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name="NothingGetsDispcf9c6" id=
|
||||
"NothingGetsDispcf9c6"></a></td>
|
||||
<td align="left" valign="top">
|
||||
<p><b>Nothing gets displayed on my second monitor; what is
|
||||
wrong?</b></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="answer">
|
||||
<td align="left" valign="top"></td>
|
||||
<td align="left" valign="top">
|
||||
<p>Monitors that do not support monitor detection using Display
|
||||
Data Channel (DDC) protocols (this includes most older monitors)
|
||||
are not detectable by your NVIDIA card. You need to explicitly tell
|
||||
the NVIDIA X driver what you have connected using the
|
||||
"ConnectedMonitor" option; e.g.,</p>
|
||||
<pre class="screen">
|
||||
Option "ConnectedMonitor" "CRT, CRT"
|
||||
</pre>
|
||||
<p></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name="WillWindowManag82696" id=
|
||||
"WillWindowManag82696"></a></td>
|
||||
<td align="left" valign="top">
|
||||
<p><b>Will window managers be able to appropriately place windows
|
||||
(e.g., avoiding placing windows across both display devices, or in
|
||||
inaccessible regions of the virtual desktop)?</b></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="answer">
|
||||
<td align="left" valign="top"></td>
|
||||
<td align="left" valign="top">
|
||||
<p>Yes. Window managers can query the layout of display devices
|
||||
through either RandR 1.2 or Xinerama.</p>
|
||||
<p>The NVIDIA X driver provides a Xinerama extension that X clients
|
||||
(such as window managers) can use to discover the current layout of
|
||||
display devices. Note that the Xinerama protocol provides no way to
|
||||
notify clients when a configuration change occurs, so if you
|
||||
modeswitch to a different MetaMode, your window manager may still
|
||||
think you have the previous configuration. Using RandR 1.2, or the
|
||||
Xinerama extension in conjunction with the XF86VidMode extension to
|
||||
get modeswitch events, window managers should be able to determine
|
||||
the display device configuration at any given time.</p>
|
||||
<p>Unfortunately, the data provided by XineramaQueryScreens()
|
||||
appears to confuse some window managers; to work around such broken
|
||||
window managers, you can disable communication of the display
|
||||
device layout with the <a href=
|
||||
"xconfigoptions.html#nvidiaXineramaInfo">nvidiaXineramaInfo</a> X
|
||||
configuration option.</p>
|
||||
<p>The order that display devices are reported in via the NVIDIA
|
||||
Xinerama information can be configured with the
|
||||
nvidiaXineramaInfoOrder X configuration option.</p>
|
||||
<p>Be aware that the NVIDIA driver cannot provide the Xinerama
|
||||
extension if the X server's own Xinerama extension is being used.
|
||||
Explicitly specifying Xinerama in the X config file or on the X
|
||||
server commandline will prohibit NVIDIA's Xinerama extension from
|
||||
installing, so make sure that the X server's log file does not
|
||||
contain:</p>
|
||||
<pre class="screen">
|
||||
(++) Xinerama: enabled
|
||||
</pre>
|
||||
<p>if you want the NVIDIA driver to be able to provide the Xinerama
|
||||
extension while in TwinView.</p>
|
||||
<p>Another solution is to use panning domains to eliminate
|
||||
inaccessible regions of the virtual screen (see the MetaMode
|
||||
description above).</p>
|
||||
<p>A third solution is to use two separate X screens, rather than
|
||||
use TwinView. See <a href="configmultxscreens.html" title=
|
||||
"Chapter 14. Configuring Multiple X Screens on One Card">Chapter 14,
|
||||
<i>Configuring Multiple X Screens on One Card</i></a>.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name="HowAreVirtualScad03c" id=
|
||||
"HowAreVirtualScad03c"></a></td>
|
||||
<td align="left" valign="top">
|
||||
<p><b>How are virtual screen dimensions determined in
|
||||
TwinView?</b></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="answer">
|
||||
<td align="left" valign="top"></td>
|
||||
<td align="left" valign="top">
|
||||
<p>After all requested modes have been validated, and the offsets
|
||||
for each MetaMode's viewports have been computed, the NVIDIA driver
|
||||
computes the bounding box of the panning domains for each MetaMode.
|
||||
The maximum bounding box width and height is then found.</p>
|
||||
<p>Note that one side effect of this is that the virtual width and
|
||||
virtual height may come from different MetaModes. Given the
|
||||
following MetaMode string:</p>
|
||||
<pre class="screen">
|
||||
"1600x1200,NULL; 1024x768+0+0, 1024x768+0+768"
|
||||
</pre>
|
||||
<p>the resulting virtual screen size will be 1600 x 1536.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name="CanIPlayFullScr76116" id=
|
||||
"CanIPlayFullScr76116"></a></td>
|
||||
<td align="left" valign="top">
|
||||
<p><b>Can I play full screen games across both display
|
||||
devices?</b></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="answer">
|
||||
<td align="left" valign="top"></td>
|
||||
<td align="left" valign="top">
|
||||
<p>Yes. While the details of configuration will vary from game to
|
||||
game, the basic idea is that a MetaMode presents X with a mode
|
||||
whose resolution is the bounding box of the viewports for that
|
||||
MetaMode. For example, the following:</p>
|
||||
<pre class="screen">
|
||||
Option "MetaModes" "1024x768,1024x768; 800x600,800x600"
|
||||
Option "MetaModeOrientation" "RightOf"
|
||||
</pre>
|
||||
<p>produce two modes: one whose resolution is 2048x768, and another
|
||||
whose resolution is 1600x600. Games such as Quake 3 Arena use the
|
||||
VidMode extension to discover the resolutions of the modes
|
||||
currently available. To configure Quake 3 Arena to use the above
|
||||
MetaMode string, add the following to your q3config.cfg file:</p>
|
||||
<pre class="screen">
|
||||
seta r_customaspect "1"
|
||||
seta r_customheight "600"
|
||||
seta r_customwidth "1600"
|
||||
seta r_fullscreen "1"
|
||||
seta r_mode "-1"
|
||||
</pre>
|
||||
<p>Note that, given the above configuration, there is no mode with
|
||||
a resolution of 800x600 (remember that the MetaMode "800x600,
|
||||
800x600" has a resolution of 1600x600"), so if you change Quake 3
|
||||
Arena to use a resolution of 800x600, it will display in the lower
|
||||
left corner of your screen, with the rest of the screen grayed out.
|
||||
To have single head modes available as well, an appropriate
|
||||
MetaMode string might be something like:</p>
|
||||
<pre class="screen">
|
||||
"800x600,800x600; 1024x768,NULL; 800x600,NULL; 640x480,NULL"
|
||||
</pre>
|
||||
<p>More precise configuration information for specific games is
|
||||
beyond the scope of this document, but the above examples coupled
|
||||
with numerous online sources should be enough to point you in the
|
||||
right direction.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"openglenvvariables.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"xineramaglx.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 11. Specifying OpenGL Environment Variable
|
||||
Settings </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 13. Configuring GLX in Xinerama</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,90 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 33. Configuring Depth 30 Displays</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="framelock.html" title=
|
||||
"Chapter 32. Configuring Frame Lock and Genlock">
|
||||
<link rel="next" href="randr14.html" title=
|
||||
"Chapter 34. Offloading Graphics Display with RandR 1.4">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 33. Configuring
|
||||
Depth 30 Displays</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"framelock.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"randr14.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="depth30" id=
|
||||
"depth30"></a>Chapter 33. Configuring Depth 30
|
||||
Displays</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>This driver release supports X screens with screen depths of 30
|
||||
bits per pixel (10 bits per color component). This provides about 1
|
||||
billion possible colors, allowing for higher color precision and
|
||||
smoother gradients.</p>
|
||||
<p>When displaying a depth 30 image, the color data may be dithered
|
||||
to lower bit depths, depending on the capabilities of the display
|
||||
device and how it is connected to the GPU. Some devices connected
|
||||
via analog VGA or DisplayPort can display the full 10 bit range of
|
||||
colors. Devices connected via DVI or HDMI, as well as laptop
|
||||
internal panels connected via LVDS, will be dithered to 8 or 6 bits
|
||||
per pixel.</p>
|
||||
<p>To work reliably, depth 30 requires pixman 0.11.6 or higher.</p>
|
||||
<p>In addition to the above software requirements, many X
|
||||
applications and toolkits do not understand depth 30 visuals as of
|
||||
this writing. Some programs may work correctly, some may work but
|
||||
display incorrect colors, and some may simply fail to run. In
|
||||
particular, many OpenGL applications request 8 bits of alpha when
|
||||
searching for FBConfigs. Since depth 30 visuals have only 2 bits of
|
||||
alpha, no suitable FBConfigs will be found and such applications
|
||||
will fail to start.</p>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"framelock.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"randr14.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 32. Configuring Frame Lock and Genlock </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 34. Offloading Graphics Display with RandR
|
||||
1.4</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,247 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Appendix C. Display Device Names</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="appendices.html" title=
|
||||
"Part II. Appendices">
|
||||
<link rel="prev" href="xconfigoptions.html" title=
|
||||
"Appendix B. X Config Options">
|
||||
<link rel="next" href="glxsupport.html" title=
|
||||
"Appendix D. GLX Support">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Appendix C. Display Device
|
||||
Names</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"xconfigoptions.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part II. Appendices</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"glxsupport.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="appendix" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="displaydevicenames" id=
|
||||
"displaydevicenames"></a>Appendix C. Display Device
|
||||
Names</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>A "display device" refers to a hardware device capable of
|
||||
displaying an image. Most NVIDIA GPUs can drive multiple display
|
||||
devices simultaneously.</p>
|
||||
<p>Many X configuration options can be used to separately configure
|
||||
each display device in use by the X screen. To address an
|
||||
individual display device, you can use one of several names that
|
||||
are assigned to it.</p>
|
||||
<p>For example, the "ModeValidation" X configuration option by
|
||||
default applies to all display devices on the X screen. E.g.,</p>
|
||||
<pre class="screen">
|
||||
Option "ModeValidation" "NoMaxPClkCheck"
|
||||
</pre>
|
||||
<p>You can use a display device name qualifier to configure each
|
||||
display device's ModeValidation separately. E.g.,</p>
|
||||
<pre class="screen">
|
||||
Option "ModeValidation" "DFP-0: NoMaxPClkCheck; CRT-1: NoVesaModes"
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>The description of each X configuration option in <a href=
|
||||
"xconfigoptions.html" title=
|
||||
"Appendix B. X Config Options">Appendix B, <i>X
|
||||
Config Options</i></a> provides more detail on the available syntax
|
||||
for each option.</p>
|
||||
<p>The available display device names vary by GPU. To find all
|
||||
available names for your configuration, start the X server with
|
||||
verbose logging enabled (e.g., <strong class=
|
||||
"userinput"><code>startx -- -logverbose 5</code></strong>, or
|
||||
enable the "ModeDebug" X configuration option with <strong class=
|
||||
"userinput"><code>nvidia-xconfig --mode-debug</code></strong> and
|
||||
restart the X server).</p>
|
||||
<p>The X log (normally /var/log/Xorg.0.log) will contain a list of
|
||||
what display devices are valid for the GPU. E.g.,</p>
|
||||
<pre class="screen">
|
||||
(--) NVIDIA(0): Valid display device(s) on Quadro 6000 at PCI:10:0:0
|
||||
(--) NVIDIA(0): CRT-0
|
||||
(--) NVIDIA(0): CRT-1
|
||||
(--) NVIDIA(0): DELL U2410 (DFP-0) (connected)
|
||||
(--) NVIDIA(0): NEC LCD1980SXi (DFP-1) (connected)
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>The X log will also contain a list of which display devices are
|
||||
assigned to the X screen. E.g.,</p>
|
||||
<pre class="screen">
|
||||
(II) NVIDIA(0): Display device(s) assigned to X screen 0:
|
||||
(II) NVIDIA(0): CRT-0
|
||||
(II) NVIDIA(0): CRT-1
|
||||
(II) NVIDIA(0): DELL U2410 (DFP-0)
|
||||
(II) NVIDIA(0): NEC LCD1980SXi (DFP-1)
|
||||
</pre>
|
||||
<p>Note that when multiple X screens are configured on the same
|
||||
GPU, the NVIDIA X driver assigns different display devices to each
|
||||
X screen. On X servers that support RandR 1.2 or later, the NVIDIA
|
||||
X driver will create an RandR output for each display device
|
||||
assigned to an X screen.</p>
|
||||
<p>The X log will also report a list of "Name Aliases" for each
|
||||
display device. E.g.,</p>
|
||||
<pre class="screen">
|
||||
(--) NVIDIA(0): Name Aliases for NEC LCD1980SXi (DFP-1):
|
||||
(--) NVIDIA(0): DFP
|
||||
(--) NVIDIA(0): DFP-1
|
||||
(--) NVIDIA(0): DPY-3
|
||||
(--) NVIDIA(0): DVI-I-3
|
||||
(--) NVIDIA(0): DPY-EDID-373091cb-5c07-6430-54d2-1112efd64b44
|
||||
(--) NVIDIA(0): Connector-0
|
||||
</pre>
|
||||
<p>These aliases can be used interchangeably to refer to the same
|
||||
display device in any X configuration option, as an nvidia-settings
|
||||
target specification, or in NV-CONTROL protocol that uses similar
|
||||
strings, such as NV_CTRL_STRING_CURRENT_METAMODE_VERSION_2
|
||||
(available through the nvidia-settings command line as
|
||||
<strong class="userinput"><code>nvidia-settings --query
|
||||
CurrentMetaMode</code></strong>).</p>
|
||||
<p>Each alias has different properties that may affect which alias
|
||||
is appropriate to use. The possible alias names are:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>A "type"-based name (e.g., "DFP-1"). This name is a unique index
|
||||
plus a display device type name, though in actuality the "type
|
||||
name" is selected based on the protocol through which the X driver
|
||||
communicates to the display device. If the X driver communicates
|
||||
using VGA, then the name is "CRT"; if the driver communicates using
|
||||
TMDS, LVDS, or DP, then the name is "DFP".</p>
|
||||
<p>This may cause confusion in some cases (e.g., a digital flat
|
||||
panel connected via VGA will have the name "CRT"), but this name
|
||||
alias is provided for backwards compatibility with earlier NVIDIA
|
||||
driver releases.</p>
|
||||
<p>Also for backwards compatibility, an alias is provided that uses
|
||||
the "type name" without an index. This name alias will match any
|
||||
display device of that type: it is not unique across the X
|
||||
screen.</p>
|
||||
<p>Note that the index in this type-based name is based on which
|
||||
physical connector is used. If you reconnect a display device to a
|
||||
different connector on the GPU, the type-based name will be
|
||||
different.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>A connector-based name (e.g., "DVI-I-3"). This name is a unique
|
||||
index plus a name that is based on the physical connector through
|
||||
which the display device is connected to the GPU. E.g., "VGA-1",
|
||||
"DVI-I-0", "DVI-D-3", "LVDS-1", "DP-2", "HDMI-3", "eDP-6",
|
||||
"USB-C-0". On X servers that support RandR 1.2 or later, this name
|
||||
is also used as the RandR output name.</p>
|
||||
<p>Note that the index in this connector-based name is based on
|
||||
which physical connector is used. If you reconnect a display device
|
||||
to a different connector on the GPU, the connector-based name will
|
||||
be different.</p>
|
||||
<p>When Mosaic is enabled, this name is prefixed with a GPU
|
||||
identifier to make it unique. For example, a Mosaic configuration
|
||||
with two DisplayPort devices might have two different outputs with
|
||||
names "GPU-0.DP-0" and "GPU-1.DP-0", respectively. See <a href=
|
||||
"gpunames.html" title=
|
||||
"Appendix K. GPU Names">Appendix K, <i>GPU
|
||||
Names</i></a> for a description of valid GPU names.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>An EDID-based name (e.g.,
|
||||
"DPY-EDID-373091cb-5c07-6430-54d2-1112efd64b44"). This name is a
|
||||
SHA-1 hash, formatted in canonical UUID 8-4-4-4-12 format, of the
|
||||
display device's EDID. This name will be the same regardless of
|
||||
which physical connector on the GPU you use, but it will not be
|
||||
unique if you have multiple display devices with the same EDID.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>An NV-CONTROL target ID-based name (e.g., "DPY-3"). The NVIDIA X
|
||||
driver will assign a unique ID to each display device on the entire
|
||||
X server. These IDs are not guaranteed to be persistent from one
|
||||
run of the X server to the next, so is likely not convenient for X
|
||||
configuration file use. It is more frequently used in communication
|
||||
with NV-CONTROL clients such as nvidia-settings.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>A connector number-based name (e.g., "Connector-0"), where each
|
||||
name identifies a physical connector on the graphics card.
|
||||
Connector numbers for these names are guaranteed to begin at 0 and
|
||||
monotonically increase to the maximum number of connectors on the
|
||||
graphics card.</p>
|
||||
<p>Note that multiple display devices may have the same connector
|
||||
number-based name: DisplayPort Multi-Stream devices on the same
|
||||
connector, or display devices representing different protocols that
|
||||
can be possibly driven by the same connector (e.g., DisplayPort
|
||||
versus TMDS protocols driven over a DisplayPort connector).</p>
|
||||
<p>This name is most useful with the "ConnectedMonitor" X
|
||||
configuration option in situations where you want to emulate the
|
||||
presence of one or more connected monitors, but do not necessarily
|
||||
care which physical connectors are used. E.g.,</p>
|
||||
<pre class="screen">
|
||||
Option "ConnectedMonitor" "Connector-0, Connector-1"
|
||||
</pre>
|
||||
<p></p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p>When DisplayPort 1.2 branch devices are present, display devices
|
||||
will be created with type- and connector-based names that are based
|
||||
on how they are connected to the branch device tree. For example,
|
||||
if a connector named DP-2 has a branch device attached and a
|
||||
DisplayPort device is connected to the branch device's first
|
||||
downstream port, a display device named <code class=
|
||||
"computeroutput">DP-2.1</code> might be created. If another branch
|
||||
device is connected between the first branch device and the display
|
||||
device, the name might be <code class=
|
||||
"computeroutput">DP-2.1.1</code>.</p>
|
||||
<p>Any display device name can have an optional GPU qualifier
|
||||
prefix. E.g., "GPU-0.DVI-I-3". This is useful in Mosaic
|
||||
configurations: type- and connector-based display device names are
|
||||
only unique within a GPU, so the GPU qualifier is used to
|
||||
distinguish between identically named display devices on different
|
||||
GPUs. For example:</p>
|
||||
<pre class="screen">
|
||||
Option "MetaModes" "GPU-0.CRT-0: 1600x1200, GPU-1.CRT-0: 1024x768"
|
||||
</pre>
|
||||
<p>If no GPU is specified for a particular display device name, the
|
||||
setting will apply to any devices with that name across all GPUs.
|
||||
Note that the GPU UUID can also be used as the qualifier. E.g.,
|
||||
"GPU-758a4cf7-0761-62c7-9bf7-c7d950b817c6.DVI-I-1". See <a href=
|
||||
"gpunames.html" title=
|
||||
"Appendix K. GPU Names">Appendix K, <i>GPU
|
||||
Names</i></a> For details.</p>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"xconfigoptions.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"appendices.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"glxsupport.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">Appendix B. X
|
||||
Config Options </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Appendix D. GLX Support</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,115 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 10. Allocating DMA Buffers on 64-bit
|
||||
Platforms</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="knownissues.html" title=
|
||||
"Chapter 9. Known Issues">
|
||||
<link rel="next" href="openglenvvariables.html" title=
|
||||
"Chapter 11. Specifying OpenGL Environment Variable Settings">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 10. Allocating DMA
|
||||
Buffers on 64-bit Platforms</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"knownissues.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"openglenvvariables.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="dma_issues" id=
|
||||
"dma_issues"></a>Chapter 10. Allocating DMA Buffers on
|
||||
64-bit Platforms</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>NVIDIA GPUs have limits on how much physical memory they can
|
||||
address. This directly impacts DMA buffers, as a DMA buffer
|
||||
allocated in physical memory that is unaddressable by the NVIDIA
|
||||
GPU cannot be used (or may be truncated, resulting in bad memory
|
||||
accesses). See <a href="addressingcapabilities.html" title=
|
||||
"Chapter 41. Addressing Capabilities">Chapter 41,
|
||||
<i>Addressing Capabilities</i></a> for details on the addressing
|
||||
limitations of specific GPUs.</p>
|
||||
<p>When an NVIDIA GPU has an addressing limit less than the maximum
|
||||
possible physical system memory address, the NVIDIA Linux driver
|
||||
will use the __GFP_DMA32 flag to limit system memory allocations to
|
||||
the lowest 4 GB of physical memory in order to guarantee
|
||||
accessibility. This restriction applies even if there is hardware
|
||||
capable of remapping physical memory into an accessible range
|
||||
present, such as an IOMMU, because the NVIDIA Linux driver cannot
|
||||
determine at the time of memory allocation whether the memory can
|
||||
be remapped. This limitation can significantly reduce the amount of
|
||||
physical memory available to the NVIDIA GPU in some
|
||||
configurations.</p>
|
||||
<p>The Linux kernel requires that device drivers use the DMA
|
||||
remapping APIs to make physical memory accessible to devices, even
|
||||
when no remapping hardware is present. The NVIDIA Linux driver
|
||||
generally adheres to this requirement, except when it detects that
|
||||
the remapping is implemented using the SWIOTLB, which is not
|
||||
supported by the NVIDIA Linux driver. When the NVIDIA Linux driver
|
||||
detects that the SWIOTLB is in use, it will instead calculate the
|
||||
correct bus address needed to access a physical allocation instead
|
||||
of calling the kernel DMA remapping APIs to do so, as SWIOTLB space
|
||||
is very limited and exhaustion can result in a kernel panic.</p>
|
||||
<p>The NVIDIA Linux driver does not generally limit its usage of
|
||||
the Linux kernel DMA remapping APIs, and this can result in IOMMU
|
||||
space exhaustion when large amounts of physical memory are remapped
|
||||
for use by the NVIDIA GPU. Most modern IOMMU drivers generally fail
|
||||
gracefully when IOMMU space is exhausted, but NVIDIA recommends
|
||||
configuring the IOMMU in such a way to avoid resource exhaustion if
|
||||
possible, either by increasing the size of the IOMMU or disabling
|
||||
the IOMMU.</p>
|
||||
<p>On AMD's AMD64 platform, the size of the IOMMU can be configured
|
||||
in the system BIOS or, if no IOMMU BIOS option is available, using
|
||||
the 'iommu=memaper' kernel parameter. This kernel parameter expects
|
||||
an order and instructs the Linux kernel to create an IOMMU of size
|
||||
32 MB^order overlapping physical memory. If the system's default
|
||||
IOMMU is smaller than 64 MB, the Linux kernel automatically
|
||||
replaces it with a 64 MB IOMMU.</p>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"knownissues.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"openglenvvariables.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 9. Known Issues </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 11. Specifying OpenGL Environment Variable
|
||||
Settings</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,198 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Appendix E. Dots Per Inch</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="appendices.html" title=
|
||||
"Part II. Appendices">
|
||||
<link rel="prev" href="glxsupport.html" title=
|
||||
"Appendix D. GLX Support">
|
||||
<link rel="next" href="i2c.html" title=
|
||||
"Appendix F. i2c Bus Support">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Appendix E. Dots Per
|
||||
Inch</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"glxsupport.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part II. Appendices</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"i2c.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="appendix" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="dpi" id=
|
||||
"dpi"></a>Appendix E. Dots Per Inch</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>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.</p>
|
||||
<p>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:</p>
|
||||
<pre class="screen">
|
||||
DPI = SizeInPixels / SizeInInches
|
||||
</pre>
|
||||
<p>Since the X screen stores its physical size in millimeters
|
||||
rather than inches (1 inch = 25.4 millimeters):</p>
|
||||
<pre class="screen">
|
||||
DPI = (SizeInPixels * 25.4) / SizeInMillimeters
|
||||
</pre>
|
||||
<p>The NVIDIA X driver reports the size of the X screen in pixels
|
||||
and in millimeters. 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 <a href=
|
||||
"xconfigoptions.html#ConstantDPI">ConstantDPI</a> option to
|
||||
FALSE.</p>
|
||||
<p>You can query the DPI of your X screen by running:</p>
|
||||
<pre class="screen">
|
||||
% xdpyinfo | grep -B1 dot
|
||||
</pre>
|
||||
<p>which should generate output like this:</p>
|
||||
<pre class="screen">
|
||||
dimensions: 1280x1024 pixels (382x302 millimeters)
|
||||
resolution: 85x86 dots per inch
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>The NVIDIA X driver performs several steps during X screen
|
||||
initialization to determine the DPI of each X screen:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>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.</p>
|
||||
<p>Note that in some cases, the physical size information stored in
|
||||
a display device's EDID may be unreliable. This could result in a
|
||||
display device's DPI being computed incorrectly, potentially
|
||||
leading to undesired consequences such as fonts that are scaled
|
||||
larger or smaller than expected. These issues can be worked around
|
||||
by manually setting a DPI using the "DPI" X configuration option,
|
||||
or by disabling the use of the EDID's physical size information for
|
||||
computing DPI by setting the <a href=
|
||||
"xconfigoptions.html#UseEdidDpi">UseEdidDpi</a> X configuration
|
||||
option to "FALSE"'.</p>
|
||||
<p>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.:</p>
|
||||
<pre class="screen">
|
||||
Option "UseEdidDpi" "DFP-1"
|
||||
</pre>
|
||||
<p>or disable EDID-computed DPI by setting this option to
|
||||
false:</p>
|
||||
<pre class="screen">
|
||||
Option "UseEdidDpi" "FALSE"
|
||||
</pre>
|
||||
<p>EDID-based DPI computation is enabled by default when an EDID is
|
||||
available.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>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.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>If the <a href="xconfigoptions.html#DPI">DPI</a> X configuration
|
||||
option is specified, that will be used to set the DPI. This will
|
||||
override the "UseEdidDpi" option.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>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 man page for details.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>If none of the above are available, the DPI defaults to
|
||||
75x75.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p>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:</p>
|
||||
<pre class="screen">
|
||||
(--) NVIDIA(0): DPI set to (101, 101); computed from "UseEdidDpi" X config option
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>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.</p>
|
||||
<p>The DPI of an X screen can be poorly defined when multiple
|
||||
display devices are enabled on the X screen: those display devices
|
||||
might have different actual DPIs, yet DPI is advertised from the X
|
||||
server to the X application with X screen granularity. Solutions
|
||||
for this include:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>Use separate X screens, with one display device on each X
|
||||
screen; see <a href="configmultxscreens.html" title=
|
||||
"Chapter 14. Configuring Multiple X Screens on One Card">Chapter 14,
|
||||
<i>Configuring Multiple X Screens on One Card</i></a> for
|
||||
details.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The RandR X extension version 1.2 and later reports the physical
|
||||
size of each RandR Output, so applications could possibly choose to
|
||||
render content at different sizes, depending on which portion of
|
||||
the X screen is displayed on which display devices. Client
|
||||
applications can also configure the reported per-RandR Output
|
||||
physical size. See, e.g., the xrandr(1) '--fbmm' command line
|
||||
option.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Experiment with different DPI settings to find a DPI that is
|
||||
suitable for all display devices on the X screen.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"glxsupport.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"appendices.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"i2c.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">Appendix D. GLX
|
||||
Support </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Appendix F. i2c Bus Support</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,228 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 23. Dynamic Boost on Linux</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="dynamicpowermanagement.html" title=
|
||||
"Chapter 22. PCI-Express Runtime D3 (RTD3) Power Management">
|
||||
<link rel="next" href="xcompositeextension.html" title=
|
||||
"Chapter 24. Using the X Composite Extension">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 23. Dynamic Boost
|
||||
on Linux</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"dynamicpowermanagement.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"xcompositeextension.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="dynamicboost" id=
|
||||
"dynamicboost"></a>Chapter 23. Dynamic Boost on
|
||||
Linux</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="toc">
|
||||
<p><b>Table of Contents</b></p>
|
||||
<dl>
|
||||
<dt><span class="section"><a href=
|
||||
"dynamicboost.html#Introductiond7a86">Introduction</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"dynamicboost.html#HardwareRequire1d82a">Hardware
|
||||
Requirements</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"dynamicboost.html#SoftwareRequirea030b">Software
|
||||
Requirements</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"dynamicboost.html#ConfigurationSt5d898">Configuration
|
||||
Steps</a></span></dt>
|
||||
</dl>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name="Introductiond7a86"
|
||||
id="Introductiond7a86"></a>Introduction</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>The <code class="filename">nvidia-powerd</code> daemon provides
|
||||
support for the NVIDIA Dynamic Boost feature on Linux platforms.
|
||||
Dynamic Boost is a system-wide power controller which manages GPU
|
||||
and CPU power, according to the workload on the system. By shifting
|
||||
power between the GPU and the CPU, Dynamic Boost can deliver more
|
||||
power to the component that would benefit most from it, without
|
||||
impacting the system's total thermal and electrical budgets. This
|
||||
optimizes overall system performance per watt.</p>
|
||||
<p>Dynamic Boost will be active only when the notebook system is
|
||||
powered by AC and there is enough load on the GPU. It will not be
|
||||
engaged when the system is running on battery. Dynamic Boost is
|
||||
intended to improve performance on balanced as well as heavily
|
||||
GPU-bound or CPU-bound applications. Dynamic Boost requests the
|
||||
CPUFreq Governor to set the CPU frequency by updating the
|
||||
<code class=
|
||||
"filename">/sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq</code>
|
||||
sysfs entries.</p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"HardwareRequire1d82a" id="HardwareRequire1d82a"></a>Hardware
|
||||
Requirements</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>Dynamic Boost is supported only on platforms that meet all of
|
||||
the following requirements:</p>
|
||||
<div class="orderedlist">
|
||||
<ol type="1">
|
||||
<li>
|
||||
<p>Notebook form factor.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Ampere or newer GPUs.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Intel CometLake or newer Intel chipsets, or AMD Renoir, Cezanne,
|
||||
Rembrandt, or newer AMD chipsets.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>SBIOS support for Dynamic Boost</p>
|
||||
<p>Run the following command to check if the SBIOS supports Dynamic
|
||||
Boost:</p>
|
||||
<p><strong class="userinput"><code>nvidia-settings -q
|
||||
DynamicBoostSupport</code></strong></p>
|
||||
</li>
|
||||
</ol>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"SoftwareRequirea030b" id="SoftwareRequirea030b"></a>Software
|
||||
Requirements</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>The system must fulfill all of the following requirements:</p>
|
||||
<div class="orderedlist">
|
||||
<ol type="1">
|
||||
<li>
|
||||
<p>Use the <span><strong class="command">systemd</strong></span>
|
||||
init daemon.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Support the <span><strong class="command">D-Bus</strong></span>
|
||||
message bus system.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Use the <span><strong class="command">cpufreq</strong></span>
|
||||
infrastructure.</p>
|
||||
</li>
|
||||
</ol>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"ConfigurationSt5d898" id="ConfigurationSt5d898"></a>Configuration
|
||||
Steps</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>Note: The following commands must be run with root
|
||||
permissions</p>
|
||||
<div class="orderedlist">
|
||||
<ol type="1">
|
||||
<li>
|
||||
<p>Copy the dbus configuration file <code class=
|
||||
"filename">nvidia-dbus.conf</code> from <code class=
|
||||
"filename">/usr/share/doc/NVIDIA_GLX-1.0/</code> to <code class=
|
||||
"filename">/etc/dbus-1/system.d</code>. If the <code class=
|
||||
"filename">/etc/dbus-1/system.d</code> directory does not exist,
|
||||
create it before copying the file and reboot the system so that
|
||||
dbus can scan the newly created directory in the next boot.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>To enable the nvidia-powerd service, causing it to start
|
||||
automatically on boot:</p>
|
||||
<p><strong class="userinput"><code>systemctl enable
|
||||
nvidia-powerd.service</code></strong></p>
|
||||
</li>
|
||||
<li>
|
||||
<p>To start the nvidia-powerd service:</p>
|
||||
<p><strong class="userinput"><code>systemctl start
|
||||
nvidia-powerd.service</code></strong></p>
|
||||
</li>
|
||||
</ol>
|
||||
</div>
|
||||
<p>Steps to Stop and disable the nvidia-powerd service:</p>
|
||||
<div class="orderedlist">
|
||||
<ol type="1">
|
||||
<li>
|
||||
<p>To stop the service:</p>
|
||||
<p><strong class="userinput"><code>systemctl stop
|
||||
nvidia-powerd.service</code></strong></p>
|
||||
</li>
|
||||
<li>
|
||||
<p>To disable the service such that it does not automatically start
|
||||
on boot:</p>
|
||||
<p><strong class="userinput"><code>systemctl disable
|
||||
nvidia-powerd.service</code></strong></p>
|
||||
</li>
|
||||
</ol>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"dynamicpowermanagement.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"xcompositeextension.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 22. PCI-Express Runtime D3 (RTD3) Power
|
||||
Management </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 24. Using the X Composite Extension</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,569 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 22. PCI-Express Runtime D3 (RTD3) Power
|
||||
Management</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="powermanagement.html" title=
|
||||
"Chapter 21. Configuring Power Management Support">
|
||||
<link rel="next" href="dynamicboost.html" title=
|
||||
"Chapter 23. Dynamic Boost on Linux">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 22. PCI-Express
|
||||
Runtime D3 (RTD3) Power Management</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"powermanagement.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"dynamicboost.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="dynamicpowermanagement" id=
|
||||
"dynamicpowermanagement"></a>Chapter 22. PCI-Express
|
||||
Runtime D3 (RTD3) Power Management</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="toc">
|
||||
<p><b>Table of Contents</b></p>
|
||||
<dl>
|
||||
<dt><span class="section"><a href=
|
||||
"dynamicpowermanagement.html#Introduction70e5e">Introduction</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"dynamicpowermanagement.html#SupportedConfigaffb4">Supported
|
||||
Configurations</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"dynamicpowermanagement.html#SystemSettings1be5e">System
|
||||
Settings</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"dynamicpowermanagement.html#DriverSettingsfe624">Driver
|
||||
Settings</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"dynamicpowermanagement.html#VidMemThreshold">Video Memory
|
||||
Utilization Threshold</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"dynamicpowermanagement.html#ProcfsInterface01474">Procfs Interface
|
||||
For Runtime D3</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"dynamicpowermanagement.html#KnownIssuesAndW6426e">Known Issues And
|
||||
Workarounds</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"dynamicpowermanagement.html#AutomatedSetup803b0">Automated
|
||||
Setup</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"dynamicpowermanagement.html#ReportingIssues42249">Reporting
|
||||
Issues</a></span></dt>
|
||||
</dl>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name="Introduction70e5e"
|
||||
id="Introduction70e5e"></a>Introduction</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>NVIDIA GPUs have many power-saving mechanisms. Some of them will
|
||||
reduce clocks and voltages to different parts of the chip, and in
|
||||
some cases turn off clocks or power to parts of the chip entirely,
|
||||
without affecting functionality or while continuing to function,
|
||||
just at a slower speed.</p>
|
||||
<p>However, the lowest power states for NVIDIA GPUs require turning
|
||||
power off to the entire chip, often through ACPI calls. Obviously,
|
||||
this impacts functionality. Nothing can run on the GPU while it is
|
||||
powered off. Care has to be taken to only enter this state when
|
||||
there are no workloads running on the GPU and any attempts to start
|
||||
work or any memory mapped I/O (MMIO) access must be preceded with a
|
||||
sequence to first turn the GPU back on and restore any necessary
|
||||
state.</p>
|
||||
<p>The NVIDIA GPU may have one, two or four PCI functions:</p>
|
||||
<p></p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>Function 0: VGA controller / 3D controller</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Function 1: Audio device</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Function 2: USB xHCI Host controller</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Function 3: USB Type-C UCSI controller</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
<p>Out of the four PCI functions, the NVIDIA driver directly
|
||||
manages the VGA controller / 3D Controller PCI function. Other PCI
|
||||
functions are managed by the device drivers provided with the Linux
|
||||
kernel. The NVIDIA driver is capable of handling entry into and
|
||||
exit from these low power states, for the PCI function 0. The
|
||||
remaining PCI functions are also powered down along with function 0
|
||||
when entering these low power states. As a result, the device
|
||||
drivers for the other three functions also need to be taken into
|
||||
account to:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>prevent entering the lowest-power state when the device is in
|
||||
use, </li>
|
||||
<li>trigger exiting the lowest-power state when the device is
|
||||
needed, </li>
|
||||
<li>save and restore any hardware state around power-off
|
||||
events.</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
<p>The NVIDIA Linux driver includes support for dynamically
|
||||
managing power to the NVIDIA GPU. It depends on the runtime power
|
||||
management framework within the Linux kernel to arbitrate power
|
||||
needs of various PCI functions. In order to have maximum power
|
||||
saving from this feature, two conditions must be met:</p>
|
||||
<p>1. Runtime power management for all the PCI functions of the GPU
|
||||
should be enabled.</p>
|
||||
<p>2. The device drivers for all the PCI functions should support
|
||||
runtime power management.</p>
|
||||
<p>If these conditions are satisfied and if all the PCI functions
|
||||
are idle, then The NVIDIA GPU will go to the lowest power state
|
||||
resulting into maximum power savings.</p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"SupportedConfigaffb4" id="SupportedConfigaffb4"></a>Supported
|
||||
Configurations</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>This feature is available only when the following conditions are
|
||||
satisfied:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>This feature is supported only on notebooks.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>This feature requires system hardware as well as ACPI support
|
||||
(ACPI "_PR0" and "_PR3" methods are needed to control PCIe power).
|
||||
The necessary hardware and ACPI support was first added in Intel
|
||||
Coffeelake chipset series. Hence, this feature is supported from
|
||||
Intel Coffeelake chipset series.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>This feature requires a Turing or newer GPU.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>This feature is supported with Linux kernel versions 4.18 and
|
||||
newer. With older kernel versions, it may not work as intended.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>This feature is supported when Linux kernel defines CONFIG_PM
|
||||
(CONFIG_PM=y). Typically, if the system supports S3
|
||||
(suspend-to-RAM), then CONFIG_PM would be defined.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name="SystemSettings1be5e"
|
||||
id="SystemSettings1be5e"></a>System Settings</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="orderedlist">
|
||||
<ol type="1">
|
||||
<li>
|
||||
<p>Enable runtime power management for each PCI function.</p>
|
||||
<p>For Ampere or later notebooks with supported configurations,
|
||||
runtime D3 power management is enabled by default for the GPU's PCI
|
||||
function 0 (VGA controller / 3D controller).</p>
|
||||
<p>For pre-Ampere notebooks, runtime D3 power management can be
|
||||
enabled for each PCI function using the following command.</p>
|
||||
<p><span><strong class="command">echo auto >
|
||||
/sys/bus/pci/devices/<Domain>:<Bus>:<Device>.<Function>/power/control</strong></span></p>
|
||||
<p>For example:</p>
|
||||
<p><span><strong class="command">echo auto >
|
||||
/sys/bus/pci/devices/0000\:01\:00.0/power/control</strong></span></p>
|
||||
</li>
|
||||
</ol>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name="DriverSettingsfe624"
|
||||
id="DriverSettingsfe624"></a>Driver Settings</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>This feature is enabled by default on supported Ampere or newer
|
||||
notebook computers, and disabled by default otherwise.</p>
|
||||
<p>It can be enabled or disabled via the <code class=
|
||||
"systemitem">NVreg_DynamicPowerManagement</code> nvidia.ko kernel
|
||||
module parameter.</p>
|
||||
<p></p>
|
||||
<div class="variablelist">
|
||||
<dl>
|
||||
<dt><a name="Disable" id="Disable"></a><span class=
|
||||
"term"><code class="systemitem">Option
|
||||
"NVreg_DynamicPowerManagement=0x00"</code></span></dt>
|
||||
<dd>
|
||||
<p>This setting will disable runtime D3 power management features.
|
||||
With this setting, the NVIDIA driver will only use the GPU's
|
||||
built-in power management so it always is powered on. Actual power
|
||||
usage will vary with the GPU's workload.</p>
|
||||
</dd>
|
||||
<dt><a name="Coarse-grain" id="Coarse-grain"></a><span class=
|
||||
"term"><code class="systemitem">Option
|
||||
"NVreg_DynamicPowerManagement=0x01"</code></span></dt>
|
||||
<dd>
|
||||
<p>This setting is called coarse-grained power control. With this
|
||||
setting, the NVIDIA GPU driver will allow the GPU to go into its
|
||||
lowest power state when no applications are running that use the
|
||||
nvidia driver stack. Whenever an application requiring NVIDIA GPU
|
||||
access is started, the GPU is put into an active state. When the
|
||||
application exits, the GPU is put into a low power state.</p>
|
||||
</dd>
|
||||
<dt><a name="Fine-grain" id="Fine-grain"></a><span class=
|
||||
"term"><code class="systemitem">Option
|
||||
"NVreg_DynamicPowerManagement=0x02"</code></span></dt>
|
||||
<dd>
|
||||
<p>This setting is called fine-grained power control. With this
|
||||
setting, the NVIDIA GPU driver will allow the GPU to go into its
|
||||
lowest power state when no applications are running that use the
|
||||
nvidia driver stack. Whenever an application requiring NVIDIA GPU
|
||||
access is started, the GPU is put into an active state. When the
|
||||
application exits, the GPU is put into a low power state.</p>
|
||||
<p>Additionally, the NVIDIA driver will actively monitor GPU usage
|
||||
while applications using the GPU are running. When the applications
|
||||
have not used the GPU for a short period, the driver will allow the
|
||||
GPU to be powered down. As soon as the application starts using the
|
||||
GPU, the GPU is reactivated.</p>
|
||||
<p>Furthermore, the NVIDIA GPU driver controls power to the NVIDIA
|
||||
GPU and its video memory separately. While turning off the NVIDIA
|
||||
GPU, the video memory will be kept in a low power self-refresh mode
|
||||
unless the following conditions are met:</p>
|
||||
<p></p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>The system is configured in PRIME render offload mode. See
|
||||
<a href="primerenderoffload.html" title=
|
||||
"Chapter 35. PRIME Render Offload">Chapter 35,
|
||||
<i>PRIME Render Offload</i></a> for details.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Less than a certain threshold of video memory is in use. The
|
||||
default threshold value is 200 MB. See <a href=
|
||||
"dynamicpowermanagement.html#VidMemThreshold" title=
|
||||
"Video Memory Utilization Threshold">the section called
|
||||
“Video Memory Utilization Threshold”</a> for
|
||||
details.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Sufficient system memory is available for saving the video
|
||||
memory contents.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
<p>If these conditions are met, the NVIDIA GPU driver will
|
||||
completely turn off the video memory, in addition to the rest of
|
||||
the GPU.</p>
|
||||
<p>Keeping video memory in a self-refresh mode uses more power than
|
||||
turning off video memory, but allows the GPU to be powered off and
|
||||
reactivated more quickly.</p>
|
||||
<p>It is important to note that the NVIDIA GPU will remain in an
|
||||
active state if it is driving a display. In this case, the NVIDIA
|
||||
GPU will go to a low power state only when the X configuration
|
||||
option <a href="xconfigoptions.html#HardDPMS">HardDPMS</a> is
|
||||
enabled and the display is turned off by some means - either
|
||||
automatically due to an OS setting or manually using commands like
|
||||
<span><strong class="command">xset</strong></span>.</p>
|
||||
<p>Similarly, the NVIDIA GPU will remain in an active state if a
|
||||
CUDA application is running.</p>
|
||||
</dd>
|
||||
<dt><a name="Default" id="Default"></a><span class=
|
||||
"term"><code class="systemitem">Option
|
||||
"NVreg_DynamicPowerManagement=0x03"</code></span></dt>
|
||||
<dd>
|
||||
<p>This is the default setting.</p>
|
||||
<p>For Ampere or later notebooks with supported configurations,
|
||||
this value translates to fine-grained power control. For pre-Ampere
|
||||
notebooks, this value disables runtime D3 power management
|
||||
features.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
</div>
|
||||
<p></p>
|
||||
<p>Option <code class=
|
||||
"computeroutput">NVreg_DynamicPowerManagement</code> can be set on
|
||||
the command line while loading the NVIDIA Linux kernel module. For
|
||||
example,</p>
|
||||
<p><span><strong class="command">modprobe nvidia
|
||||
"NVreg_DynamicPowerManagement=0x02"</strong></span></p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name="VidMemThreshold" id=
|
||||
"VidMemThreshold"></a>Video Memory Utilization Threshold</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>The NVIDIA GPU driver uses 200 MB as the default video memory
|
||||
utilization threshold to decide whether the video memory can be
|
||||
turned off or kept in a self-refresh mode. This threshold value can
|
||||
be decreased or increased (up to 1024 MB) using an option
|
||||
<code class=
|
||||
"systemitem">NVreg_DynamicPowerManagementVideoMemoryThreshold</code>.
|
||||
This option can be set on the command line while loading the NVIDIA
|
||||
Linux kernel module. For example,</p>
|
||||
<p><span><strong class="command">modprobe nvidia
|
||||
"NVreg_DynamicPowerManagementVideoMemoryThreshold=100"</strong></span></p>
|
||||
<p>The video memory utilization threshold value should be a
|
||||
positive integer. It is expressed in Megabytes (1048576 bytes). In
|
||||
the example above, the threshold value will be set to 100 MB. The
|
||||
maximum threshold value can be 1024 MB. Any value greater than 1024
|
||||
MB will be clamped to 1024 MB.</p>
|
||||
<p>The use of a higher threshold value will increase the latency
|
||||
during RTD3 entry and exit transitions, so use this option only if
|
||||
the latency increase is not affecting the usability of the
|
||||
system.</p>
|
||||
<p>This threshold can be set to 0 in order to prevent the video
|
||||
memory from being turned off.</p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"ProcfsInterface01474" id="ProcfsInterface01474"></a>Procfs
|
||||
Interface For Runtime D3</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>The following entries in the file <code class=
|
||||
"filename">/proc/driver/nvidia/gpus/domain:bus:device.function/power</code>
|
||||
provide more details regarding the runtime D3 feature.</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>"Runtime D3 status" entry gives the current status of this
|
||||
feature.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"Video Memory" entry gives the power status of the video
|
||||
memory.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"Video Memory Self Refresh" entry reports whether the NVIDIA GPU
|
||||
hardware supports video memory self refresh mode.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"Video Memory Off" entry reports whether the NVIDIA GPU hardware
|
||||
supports video memory off mode.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"KnownIssuesAndW6426e" id="KnownIssuesAndW6426e"></a>Known Issues
|
||||
And Workarounds</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>The first two workarounds in the below section are not required
|
||||
on Linux kernel 5.5 or newer.</p>
|
||||
<div class="orderedlist">
|
||||
<ol type="1">
|
||||
<li>
|
||||
<p>The USB xHCI Host controller and USB Type-C UCSI controller
|
||||
drivers present in most Linux distributions do not fully support
|
||||
runtime power management. Full support for runtime power management
|
||||
in these drivers is available in kernel version 5.5. For kernel
|
||||
versions before 5.5, these two PCI functions have to be disabled
|
||||
for this feature to work properly. This can be done using the
|
||||
following command.</p>
|
||||
<p><span><strong class="command">echo 1 >
|
||||
/sys/bus/pci/devices/<Domain>:<Bus>:<Device>.2/remove</strong></span></p>
|
||||
<p><span><strong class="command">echo 1 >
|
||||
/sys/bus/pci/devices/<Domain>:<Bus>:<Device>.3/remove</strong></span></p>
|
||||
<p>For example:</p>
|
||||
<p><span><strong class="command">echo 1 >
|
||||
/sys/bus/pci/devices/0000\:01\:00.2/remove</strong></span></p>
|
||||
<p><span><strong class="command">echo 1 >
|
||||
/sys/bus/pci/devices/0000\:01\:00.3/remove</strong></span></p>
|
||||
</li>
|
||||
<li>
|
||||
<p>There is a known issue with the audio driver due to which the
|
||||
audio PCI function remains in an active state. This affects Linux
|
||||
kernel versions 4.19 (starting with git commit id <code class=
|
||||
"computeroutput">37a3a98ef601f89100e3bb657fb0e190b857028c</code> )
|
||||
through 5.4, and is fixed in Linux kernel version 5.5.</p>
|
||||
<p><span><strong class="command">echo 1 >
|
||||
/sys/bus/pci/devices/<Domain>:<Bus>:<Device>.1/remove</strong></span></p>
|
||||
<p>For example:</p>
|
||||
<p><span><strong class="command">echo 1 >
|
||||
/sys/bus/pci/devices/0000\:01\:00.1/remove</strong></span></p>
|
||||
<p>This workaround will result in audio loss when the audio
|
||||
function is being used to play audio over DP/HDMI connection. To
|
||||
recover from audio loss, rescanning the PCI tree will bring back
|
||||
the audio PCI function and audio operation can be recovered.
|
||||
However, after rescanning the PCI tree, all the disabled PCI
|
||||
functions will again become active. To ensure that this feature
|
||||
works again, the workarounds mentioned in this section have to be
|
||||
done again.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>When the NVIDIA GPU is driving a console, runtime power
|
||||
management is enabled for the VGA Controller PCI function and
|
||||
nvidia driver is uninstalled, the console will become blank. The
|
||||
workaround for this issue is to disable runtime power management
|
||||
for PCI function 0 before uninstalling the NVIDIA driver using the
|
||||
following command:</p>
|
||||
<p><span><strong class="command">echo on >
|
||||
/sys/bus/pci/devices/<Domain>:<Bus>:<Device>.<Function>/power/control</strong></span></p>
|
||||
<p>For example:</p>
|
||||
<p><span><strong class="command">echo on >
|
||||
/sys/bus/pci/devices/0000\:01\:00.0/power/control</strong></span></p>
|
||||
</li>
|
||||
</ol>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name="AutomatedSetup803b0"
|
||||
id="AutomatedSetup803b0"></a>Automated Setup</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>This section describes automated ways to perform the manual
|
||||
steps mentioned above so that this feature works seamlessly after
|
||||
boot.</p>
|
||||
<div class="orderedlist">
|
||||
<ol type="1">
|
||||
<li>
|
||||
<p>Create a file named <code class=
|
||||
"filename">80-nvidia-pm.rules</code> in <code class=
|
||||
"filename">/lib/udev/rules.d/</code> directory.</p>
|
||||
<p>Add the content given below to <code class=
|
||||
"filename">80-nvidia-pm.rules</code> file. This would enable
|
||||
runtime power management for the VGA Controller / 3D Controller PCI
|
||||
function. It would also remove Audio device PCI function, USB xHCI
|
||||
Host Controller function as well as USB Type-C UCSI Controller PCI
|
||||
function. Note that the first three rules given below are not
|
||||
required from Linux kernel 5.5 and newer.</p>
|
||||
<pre class="screen">
|
||||
# Remove NVIDIA USB xHCI Host Controller devices, if present
|
||||
ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{class}=="0x0c0330", ATTR{remove}="1"
|
||||
|
||||
# Remove NVIDIA USB Type-C UCSI devices, if present
|
||||
ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{class}=="0x0c8000", ATTR{remove}="1"
|
||||
|
||||
# Remove NVIDIA Audio devices, if present
|
||||
ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{class}=="0x040300", ATTR{remove}="1"
|
||||
|
||||
# Enable runtime PM for NVIDIA VGA/3D controller devices on driver bind
|
||||
ACTION=="bind", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{class}=="0x030000", TEST=="power/control", ATTR{power/control}="auto"
|
||||
ACTION=="bind", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{class}=="0x030200", TEST=="power/control", ATTR{power/control}="auto"
|
||||
|
||||
# Disable runtime PM for NVIDIA VGA/3D controller devices on driver unbind
|
||||
ACTION=="unbind", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{class}=="0x030000", TEST=="power/control", ATTR{power/control}="on"
|
||||
ACTION=="unbind", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{class}=="0x030200", TEST=="power/control", ATTR{power/control}="on"
|
||||
</pre></li>
|
||||
<li>
|
||||
<p>The driver option <code class=
|
||||
"systemitem">NVreg_DynamicPowerManagement</code> can be set via the
|
||||
distribution's kernel module configuration files (such as those
|
||||
under <code class="filename">/etc/modprobe.d</code>). For example,
|
||||
the following line can be added to <code class=
|
||||
"filename">/etc/modprobe.d/nvidia.conf</code> file to seamlessly
|
||||
enable this feature.</p>
|
||||
<p><code class="systemitem">options nvidia
|
||||
"NVreg_DynamicPowerManagement=0x02"</code></p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Reboot the system.</p>
|
||||
</li>
|
||||
</ol>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"ReportingIssues42249" id="ReportingIssues42249"></a>Reporting
|
||||
Issues</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>For better error reporting, nvidia-bug-report.sh collects a dump
|
||||
of ACPI tables using <span><strong class=
|
||||
"command">acpidump</strong></span> utility. Depending on your Linux
|
||||
distribution, this utility may be found in a package called
|
||||
<span><strong class="command">acpica-tools</strong></span> or
|
||||
<span><strong class="command">acpica</strong></span> or
|
||||
similar.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"powermanagement.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"dynamicboost.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 21. Configuring Power Management
|
||||
Support </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 23. Dynamic Boost on Linux</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,204 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 6. Configuring X for the NVIDIA
|
||||
Driver</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="installedcomponents.html" title=
|
||||
"Chapter 5. Listing of Installed Components">
|
||||
<link rel="next" href="faq.html" title=
|
||||
"Chapter 7. Frequently Asked Questions">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 6. Configuring X
|
||||
for the NVIDIA Driver</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"installedcomponents.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"faq.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="editxconfig" id=
|
||||
"editxconfig"></a>Chapter 6. Configuring X for the NVIDIA
|
||||
Driver</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="toc">
|
||||
<p><b>Table of Contents</b></p>
|
||||
<dl>
|
||||
<dt><span class="section"><a href=
|
||||
"editxconfig.html#UsingNvidiaxcon2beec">Using nvidia-xconfig to
|
||||
configure the X server</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"editxconfig.html#ManuallyEditing1ae61">Manually Editing the
|
||||
Configuration File</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"editxconfig.html#RestoringTheXCof7145">Restoring the X
|
||||
Configuration after Uninstalling the Driver</a></span></dt>
|
||||
</dl>
|
||||
</div>
|
||||
<p>The X configuration file provides a means to configure the X
|
||||
server. This section describes the settings necessary to enable the
|
||||
NVIDIA driver. A comprehensive list of parameters is provided in
|
||||
<a href="xconfigoptions.html" title=
|
||||
"Appendix B. X Config Options">Appendix B, <i>X
|
||||
Config Options</i></a>.</p>
|
||||
<p>The NVIDIA Driver includes a utility called nvidia-xconfig,
|
||||
which is designed to make editing the X configuration file easy.
|
||||
You can also edit it by hand.</p>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"UsingNvidiaxcon2beec" id="UsingNvidiaxcon2beec"></a>Using
|
||||
nvidia-xconfig to configure the X server</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>nvidia-xconfig will find the X configuration file and modify it
|
||||
to use the NVIDIA X driver. In most cases, you can simply answer
|
||||
"Yes" when the installer asks if it should run it. If you need to
|
||||
reconfigure your X server later, you can run nvidia-xconfig again
|
||||
from a terminal. nvidia-xconfig will make a backup copy of your
|
||||
configuration file before modifying it.</p>
|
||||
<p>Note that the X server must be restarted for any changes to its
|
||||
configuration file to take effect.</p>
|
||||
<p>More information about nvidia-xconfig can be found in the
|
||||
nvidia-xconfig manual page by running.</p>
|
||||
<pre class="screen">
|
||||
% man nvidia-xconfig
|
||||
</pre>
|
||||
<p></p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"ManuallyEditing1ae61" id="ManuallyEditing1ae61"></a>Manually
|
||||
Editing the Configuration File</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>If you do not have a working X config file, there are a few
|
||||
different ways to obtain one. A sample config file is included both
|
||||
with the X.Org distribution and with the NVIDIA driver package (at
|
||||
<code class="filename">/usr/share/doc/NVIDIA_GLX-1.0/</code>). The
|
||||
<span><strong class="command">nvidia-xconfig</strong></span>
|
||||
utility, provided with the NVIDIA driver package, can generate a
|
||||
new X configuration file. Additional information on the X config
|
||||
syntax can be found in the xorg.conf manual page (<strong class=
|
||||
"userinput"><code>man xorg.conf</code></strong>).</p>
|
||||
<p>If you have a working X config file for a different driver (such
|
||||
as the “<span class="quote">vesa</span>” or
|
||||
“<span class="quote">fbdev</span>” driver), then simply
|
||||
edit the file as follows.</p>
|
||||
<p>Remove the line:</p>
|
||||
<pre class="screen">
|
||||
Driver "vesa"
|
||||
(or Driver "fbdev")
|
||||
</pre>
|
||||
<p>and replace it with the line:</p>
|
||||
<pre class="screen">
|
||||
Driver "nvidia"
|
||||
</pre>
|
||||
<p>Remove the following lines:</p>
|
||||
<pre class="screen">
|
||||
Load "dri"
|
||||
Load "GLCore"
|
||||
</pre>
|
||||
<p>In the <code class="computeroutput">Module</code> section of the
|
||||
file, add the line (if it does not already exist):</p>
|
||||
<pre class="screen">
|
||||
Load "glx"
|
||||
</pre>
|
||||
<p>If the X config file does not have a <code class=
|
||||
"computeroutput">Module</code> section, you can safely skip the
|
||||
last step.</p>
|
||||
<p>There are numerous options that may be added to the X config
|
||||
file to tune the NVIDIA X driver. See <a href="xconfigoptions.html"
|
||||
title="Appendix B. X Config Options">Appendix B,
|
||||
<i>X Config Options</i></a> for a complete list of these
|
||||
options.</p>
|
||||
<p>Once you have completed these edits to the X config file, you
|
||||
may restart X and begin using the accelerated OpenGL libraries.
|
||||
After restarting X, any OpenGL application should automatically use
|
||||
the new NVIDIA libraries. (NOTE: If you encounter any problems, see
|
||||
<a href="commonproblems.html" title=
|
||||
"Chapter 8. Common Problems">Chapter 8, <i>Common
|
||||
Problems</i></a> for common problem diagnoses.)</p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"RestoringTheXCof7145" id="RestoringTheXCof7145"></a>Restoring the
|
||||
X Configuration after Uninstalling the Driver</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>If X is explicitly configured to use the NVIDIA driver, then the
|
||||
X config file should be edited to use a different X driver after
|
||||
uninstalling the NVIDIA driver. Otherwise, X may fail to start,
|
||||
since the driver it was configured to use will no longer be present
|
||||
on the system after uninstallation.</p>
|
||||
<p>If you edited the file manually, revert any edits you made. If
|
||||
you used the <span><strong class=
|
||||
"command">nvidia-xconfig</strong></span> utility, either by
|
||||
answering "Yes" when prompted to configure the X server by the
|
||||
installer, or by running it manually later on, then you may restore
|
||||
the backed-up X config file, if it exists and reflects the X config
|
||||
state that existed before the NVIDIA driver was installed.</p>
|
||||
<p>If you do not recall any manual changes that you made to the
|
||||
file, or do not have a backed-up X config file that uses a
|
||||
non-NVIDIA X driver, you may want to try simply renaming the X
|
||||
configuration file, to see if your X server loads a sensible
|
||||
default.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"installedcomponents.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"faq.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 5. Listing of Installed Components </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 7. Frequently Asked Questions</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,93 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 37. Configuring External and Removable
|
||||
GPUs</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="kms.html" title=
|
||||
"Chapter 36. Direct Rendering Manager Kernel Modesetting (DRM KMS)">
|
||||
<link rel="next" href="ngx.html" title="Chapter 38. NGX">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 37. Configuring
|
||||
External and Removable GPUs</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"kms.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"ngx.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="egpu" id=
|
||||
"egpu"></a>Chapter 37. Configuring External and Removable
|
||||
GPUs</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>This driver release supports the use of external GPUs, or eGPUs,
|
||||
such as those commonly connected via Thunderbolt. However, system
|
||||
stability when an eGPU is unplugged while in use (also known as
|
||||
"hot-unplug") is not guaranteed. This includes situations where the
|
||||
eGPU is being used to display the X11 desktop.</p>
|
||||
<p>External GPUs are often used in short-running compute scenarios,
|
||||
which better tolerate the eGPU being hot-unplugged. In such cases,
|
||||
a different GPU may be used to display the X11 desktop.</p>
|
||||
<p>To prevent system instability from hot-unplugging an eGPU while
|
||||
being used to display the X11 desktop, the NVIDIA X driver does not
|
||||
configure X screens on external GPUs by default.</p>
|
||||
<p>This behavior may also apply to GPUs attached to internal PCIe
|
||||
slots with hot-unplug support, such as in some enterprise
|
||||
systems.</p>
|
||||
<p>To override this behavior in xorg.conf, see <a href=
|
||||
"xconfigoptions.html#AllowExternalGpus"><code class=
|
||||
"computeroutput">Option "AllowExternalGpus" "boolean"</code></a>.
|
||||
Then, external GPUs may be configured with X as one would any other
|
||||
secondary GPU, by specifying the BusID in the Device section in
|
||||
xorg.conf. See the xorg.conf man page for more information on the
|
||||
BusID option, and <a href="faq.html#busid">“What is the
|
||||
format of a PCI Bus ID?”</a> for information on how to
|
||||
determine the BusID.</p>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"kms.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"ngx.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 36. Direct Rendering Manager Kernel Modesetting
|
||||
(DRM KMS) </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 38. NGX</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,843 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 7. Frequently Asked Questions</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="editxconfig.html" title=
|
||||
"Chapter 6. Configuring X for the NVIDIA Driver">
|
||||
<link rel="next" href="commonproblems.html" title=
|
||||
"Chapter 8. Common Problems">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 7. Frequently
|
||||
Asked Questions</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"editxconfig.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"commonproblems.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="faq" id=
|
||||
"faq"></a>Chapter 7. Frequently Asked Questions</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>This section provides answers to frequently asked questions
|
||||
associated with the NVIDIA Linux x86_64 Driver and its
|
||||
installation. Common problem diagnoses can be found in <a href=
|
||||
"commonproblems.html" title=
|
||||
"Chapter 8. Common Problems">Chapter 8, <i>Common
|
||||
Problems</i></a> and tips for new users can be found in <a href=
|
||||
"newusertips.html" title=
|
||||
"Appendix I. Tips for New Linux Users">Appendix I,
|
||||
<i>Tips for New Linux Users</i></a>. Also, detailed information for
|
||||
specific setups is provided in the <a href=
|
||||
"appendices.html">Appendices</a>.</p>
|
||||
<div class="qandaset">
|
||||
<table border="0" summary="Q and A Set">
|
||||
<col align="left" width="1%">
|
||||
<tbody>
|
||||
<tr class="qandadiv">
|
||||
<td align="left" valign="top" colspan="2"><a name=
|
||||
"Nvidiainstaller55f35" id="Nvidiainstaller55f35"></a>
|
||||
<h3 class="title">7.1. NVIDIA-INSTALLER</h3>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name="HowDoIExtractTh41874" id=
|
||||
"HowDoIExtractTh41874"></a></td>
|
||||
<td align="left" valign="top">
|
||||
<p><b>How do I extract the contents of the</b> <code class=
|
||||
"filename">.run</code> <b>without actually installing the
|
||||
driver?</b></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="answer">
|
||||
<td align="left" valign="top"></td>
|
||||
<td align="left" valign="top">
|
||||
<p>Run the installer as follows:</p>
|
||||
<pre class="screen">
|
||||
# sh NVIDIA-Linux-x86_64-535.161.07.run --extract-only
|
||||
</pre>
|
||||
<p>This will create the directory NVIDIA-Linux-x86_64-535.161.07,
|
||||
containing the uncompressed contents of the <code class=
|
||||
"filename">.run</code> file.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name="HowCanISeeTheSo057a4" id=
|
||||
"HowCanISeeTheSo057a4"></a></td>
|
||||
<td align="left" valign="top">
|
||||
<p><b>How can I see the source code to the kernel interface
|
||||
layer?</b></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="answer">
|
||||
<td align="left" valign="top"></td>
|
||||
<td align="left" valign="top">
|
||||
<p>The source files to the kernel interface layer are in the kernel
|
||||
directory of the extracted .run file. To get to these sources,
|
||||
run:</p>
|
||||
<pre class="screen">
|
||||
# sh NVIDIA-Linux-x86_64-535.161.07.run --extract-only
|
||||
# cd NVIDIA-Linux-x86_64-535.161.07/kernel/
|
||||
</pre>
|
||||
<p></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name="devicenodes" id=
|
||||
"devicenodes"></a></td>
|
||||
<td align="left" valign="top">
|
||||
<p><b>How and when are the NVIDIA device files created?</b></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="answer">
|
||||
<td align="left" valign="top"></td>
|
||||
<td align="left" valign="top">
|
||||
<p>When a user-space NVIDIA driver component needs to communicate
|
||||
with the NVIDIA kernel module, and the NVIDIA character device
|
||||
files do not yet exist, the user-space component will first attempt
|
||||
to load the kernel module and create the device files itself.</p>
|
||||
<p>Device file creation and kernel module loading generally require
|
||||
root privileges. The X driver, running within a setuid root X
|
||||
server, will have these privileges, but not, e.g., the CUDA driver
|
||||
within the environment of a normal user.</p>
|
||||
<p>If the user-space NVIDIA driver component cannot load the kernel
|
||||
module or create the device files itself, it will attempt to invoke
|
||||
the setuid root nvidia-modprobe utility, which will perform these
|
||||
operations on behalf of the non-privileged driver.</p>
|
||||
<p>See the nvidia-modprobe(1) man page, or its source code,
|
||||
available here: <a href=
|
||||
"https://download.nvidia.com/XFree86/nvidia-modprobe/" target=
|
||||
"_top">https://download.nvidia.com/XFree86/nvidia-modprobe/</a></p>
|
||||
<p>When possible, it is recommended to use your Linux
|
||||
distribution's native mechanisms for managing kernel module loading
|
||||
and device file creation. nvidia-modprobe is provided as a fallback
|
||||
to work out-of-the-box in a distribution-independent way.</p>
|
||||
<p>Whether a user-space NVIDIA driver component does so itself, or
|
||||
invokes nvidia-modprobe, it will default to creating the device
|
||||
files with the following attributes:</p>
|
||||
<pre class="screen">
|
||||
UID: 0 - 'root'
|
||||
GID: 0 - 'root'
|
||||
Mode: 0666 - 'rw-rw-rw-'
|
||||
</pre>
|
||||
<p>Existing device files are changed if their attributes don't
|
||||
match these defaults. If you want the NVIDIA driver to create the
|
||||
device files with different attributes, you can specify them with
|
||||
the "NVreg_DeviceFileUID" (user), "NVreg_DeviceFileGID" (group) and
|
||||
"NVreg_DeviceFileMode" NVIDIA Linux kernel module parameters.</p>
|
||||
<p>For example, the NVIDIA driver can be instructed to create
|
||||
device files with UID=0 (root), GID=44 (video) and Mode=0660 by
|
||||
passing the following module parameters to the NVIDIA Linux kernel
|
||||
module:</p>
|
||||
<pre class="screen">
|
||||
NVreg_DeviceFileUID=0
|
||||
NVreg_DeviceFileGID=44
|
||||
NVreg_DeviceFileMode=0660
|
||||
</pre>
|
||||
<p>The "NVreg_ModifyDeviceFiles" NVIDIA kernel module parameter
|
||||
will disable dynamic device file management, if set to 0.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name="WhyDoesNvidiaNoc13de" id=
|
||||
"WhyDoesNvidiaNoc13de"></a></td>
|
||||
<td align="left" valign="top">
|
||||
<p><b>Why does NVIDIA not provide RPMs?</b></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="answer">
|
||||
<td align="left" valign="top"></td>
|
||||
<td align="left" valign="top">
|
||||
<p>Not every Linux distribution uses RPM, and NVIDIA provides a
|
||||
single solution that works across all Linux distributions. NVIDIA
|
||||
encourages Linux distributions to repackage and redistribute the
|
||||
NVIDIA Linux driver in their native package management formats.
|
||||
These repackaged NVIDIA drivers are likely to inter-operate best
|
||||
with the Linux distribution's package management technology. For
|
||||
this reason, NVIDIA encourages users to use their distribution's
|
||||
repackaged NVIDIA driver, where available.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name="WhatIsTheSignifadd36" id=
|
||||
"WhatIsTheSignifadd36"></a></td>
|
||||
<td align="left" valign="top">
|
||||
<p><b>What is the significance of the</b> <code class=
|
||||
"filename">-no-compat32</code> <b>suffix on Linux-x86_64</b>
|
||||
<code class="filename">.run</code> <b>files?</b></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="answer">
|
||||
<td align="left" valign="top"></td>
|
||||
<td align="left" valign="top">
|
||||
<p>To distinguish between Linux-x86_64 driver package files that do
|
||||
or do not also contain 32-bit compatibility libraries,
|
||||
"-no-compat32" is be appended to the latter. <code class=
|
||||
"filename">NVIDIA-Linux-x86_64-535.161.07.run</code> contains both
|
||||
64-bit and 32-bit driver binaries; but <code class=
|
||||
"filename">NVIDIA-Linux-x86_64-535.161.07-no-compat32.run</code>
|
||||
omits the 32-bit compatibility libraries.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name="CanIAddMyOwnPre4e8c2" id=
|
||||
"CanIAddMyOwnPre4e8c2"></a></td>
|
||||
<td align="left" valign="top">
|
||||
<p><b>Can I add my own precompiled kernel interfaces to a</b>
|
||||
<code class="filename">.run</code> <b>file?</b></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="answer">
|
||||
<td align="left" valign="top"></td>
|
||||
<td align="left" valign="top">
|
||||
<p>Yes, the <code class="option">--add-this-kernel</code>
|
||||
<code class="filename">.run</code> file option will unpack the
|
||||
<code class="filename">.run</code> file, build a precompiled kernel
|
||||
interface for the currently running kernel, and repackage the
|
||||
<code class="filename">.run</code> file, appending <code class=
|
||||
"filename">-custom</code> to the filename. This may be useful, for
|
||||
example. if you administer multiple Linux computers, each running
|
||||
the same kernel.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name="WhereCanIFindThdef43" id=
|
||||
"WhereCanIFindThdef43"></a></td>
|
||||
<td align="left" valign="top">
|
||||
<p><b>Where can I find the source code for the</b> <code class=
|
||||
"filename">nvidia-installer</code> <b>utility?</b></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="answer">
|
||||
<td align="left" valign="top"></td>
|
||||
<td align="left" valign="top">
|
||||
<p>The <code class="filename">nvidia-installer</code> utility is
|
||||
released under the GPL. The source code for the version of
|
||||
nvidia-installer built with driver 535.161.07 is in <code class=
|
||||
"filename">nvidia-installer-535.161.07.tar.bz2</code> available
|
||||
here: <a href=
|
||||
"https://download.nvidia.com/XFree86/nvidia-installer/" target=
|
||||
"_top">https://download.nvidia.com/XFree86/nvidia-installer/</a></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="qandadiv">
|
||||
<td align="left" valign="top" colspan="2"><a name=
|
||||
"NvidiaDriver8f330" id="NvidiaDriver8f330"></a>
|
||||
<h3 class="title">7.2. NVIDIA Driver</h3>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name="WhereShouldISta91e27" id=
|
||||
"WhereShouldISta91e27"></a></td>
|
||||
<td align="left" valign="top">
|
||||
<p><b>Where should I start when diagnosing display
|
||||
problems?</b></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="answer">
|
||||
<td align="left" valign="top"></td>
|
||||
<td align="left" valign="top">
|
||||
<p>One of the most useful tools for diagnosing problems is the X
|
||||
log file in <code class="filename">/var/log</code>. Lines that
|
||||
begin with <code class="computeroutput">(II)</code> are
|
||||
information, <code class="computeroutput">(WW)</code> are warnings,
|
||||
and <code class="computeroutput">(EE)</code> are errors. You should
|
||||
make sure that the correct config file (i.e. the config file you
|
||||
are editing) is being used; look for the line that begins with:</p>
|
||||
<pre class="screen">
|
||||
(==) Using config file:
|
||||
</pre>
|
||||
<p>Also make sure that the NVIDIA driver is being used, rather than
|
||||
another driver. Search for</p>
|
||||
<pre class="screen">
|
||||
(II) LoadModule: "nvidia"
|
||||
</pre>
|
||||
<p>Lines from the driver should begin with:</p>
|
||||
<pre class="screen">
|
||||
(II) NVIDIA(0)
|
||||
</pre>
|
||||
<p></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name="xverboselog" id=
|
||||
"xverboselog"></a></td>
|
||||
<td align="left" valign="top">
|
||||
<p><b>How can I increase the amount of data printed in the X log
|
||||
file?</b></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="answer">
|
||||
<td align="left" valign="top"></td>
|
||||
<td align="left" valign="top">
|
||||
<p>By default, the NVIDIA X driver prints relatively few messages
|
||||
to stderr and the X log file. If you need to troubleshoot, then it
|
||||
may be helpful to enable more verbose output by using the X command
|
||||
line options <code class="option">-verbose</code> and <code class=
|
||||
"option">-logverbose</code>, which can be used to set the verbosity
|
||||
level for the <code class="filename">stderr</code> and log file
|
||||
messages, respectively. The NVIDIA X driver will output more
|
||||
messages when the verbosity level is at or above 5 (X defaults to
|
||||
verbosity level 1 for <code class="filename">stderr</code> and
|
||||
level 3 for the log file). So, to enable verbose messaging from the
|
||||
NVIDIA X driver to both the log file and <code class=
|
||||
"filename">stderr</code>, you could start X with the verbosity
|
||||
level set to 5, by doing the following</p>
|
||||
<pre class="screen">
|
||||
% startx -- -verbose 5 -logverbose 5
|
||||
</pre>
|
||||
<p></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name="WhatIsNvidiasPo6882d" id=
|
||||
"WhatIsNvidiasPo6882d"></a></td>
|
||||
<td align="left" valign="top">
|
||||
<p><b>What is NVIDIA's policy towards development series Linux
|
||||
kernels?</b></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="answer">
|
||||
<td align="left" valign="top"></td>
|
||||
<td align="left" valign="top">
|
||||
<p>NVIDIA does not officially support development series kernels.
|
||||
However, all the kernel module source code that interfaces with the
|
||||
Linux kernel is available in the <code class=
|
||||
"filename">kernel/</code> directory of the <code class=
|
||||
"filename">.run</code> file. NVIDIA encourages members of the Linux
|
||||
community to develop patches to these source files to support
|
||||
development series kernels. A web search will most likely yield
|
||||
several community supported patches.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name="WhereCanIFindTh2e635" id=
|
||||
"WhereCanIFindTh2e635"></a></td>
|
||||
<td align="left" valign="top">
|
||||
<p><b>Where can I find the tarballs?</b></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="answer">
|
||||
<td align="left" valign="top"></td>
|
||||
<td align="left" valign="top">
|
||||
<p>Plain tarballs are not available. The <code class=
|
||||
"filename">.run</code> file is a tarball with a shell script
|
||||
prepended. You can execute the <code class="filename">.run</code>
|
||||
file with the <code class="option">--extract-only</code> option to
|
||||
unpack the tarball.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name="HowDoITellIfIHa96f1f" id=
|
||||
"HowDoITellIfIHa96f1f"></a></td>
|
||||
<td align="left" valign="top">
|
||||
<p><b>How do I tell if I have my kernel sources installed?</b></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="answer">
|
||||
<td align="left" valign="top"></td>
|
||||
<td align="left" valign="top">
|
||||
<p>If you are running on a distro that uses RPM (Red Hat, Mandriva,
|
||||
SuSE, etc), then you can use <span><strong class=
|
||||
"command">rpm</strong></span> to tell you. At a shell prompt,
|
||||
type:</p>
|
||||
<pre class="screen">
|
||||
% rpm -qa | grep kernel
|
||||
</pre>
|
||||
<p>and look at the output. You should see a package that
|
||||
corresponds to your kernel (often named something like
|
||||
kernel-2.6.15-7) and a kernel source package with the same version
|
||||
(often named something like kernel-devel-2.6.15-7). If none of the
|
||||
lines seem to correspond to a source package, then you will
|
||||
probably need to install it. If the versions listed mismatch (e.g.,
|
||||
kernel-2.6.15-7 vs. kernel-devel-2.6.15-10), then you will need to
|
||||
update the kernel-devel package to match the installed kernel. If
|
||||
you have multiple kernels installed, you need to install the
|
||||
kernel-devel package that corresponds to your <span class=
|
||||
"emphasis"><em>running</em></span> kernel (or make sure your
|
||||
installed source package matches the running kernel). You can do
|
||||
this by looking at the output of <span><strong class=
|
||||
"command">uname -r</strong></span> and matching versions.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name="WhatIsSelinuxAn7bd2f" id=
|
||||
"WhatIsSelinuxAn7bd2f"></a></td>
|
||||
<td align="left" valign="top">
|
||||
<p><b>What is SELinux and how does it interact with the NVIDIA
|
||||
driver ?</b></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="answer">
|
||||
<td align="left" valign="top"></td>
|
||||
<td align="left" valign="top">
|
||||
<p>Security-Enhanced Linux (SELinux) is a set of modifications
|
||||
applied to the Linux kernel and utilities that implement a security
|
||||
policy architecture. When in use it requires that the security type
|
||||
on all shared libraries be set to 'shlib_t'. The installer detects
|
||||
when to set the security type, and sets it on all shared libraries
|
||||
it installs. The option <code class="option">--force-selinux</code>
|
||||
passed to the <code class="filename">.run</code> file overrides the
|
||||
detection of when to set the security type.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name="WhyDoesXUseSoMu6a4ed" id=
|
||||
"WhyDoesXUseSoMu6a4ed"></a></td>
|
||||
<td align="left" valign="top">
|
||||
<p><b>Why does X use so much memory?</b></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="answer">
|
||||
<td align="left" valign="top"></td>
|
||||
<td align="left" valign="top">
|
||||
<p>When measuring any application's memory usage, you must be
|
||||
careful to distinguish between physical system RAM used and virtual
|
||||
mappings of shared resources. For example, most shared libraries
|
||||
exist only once in physical memory but are mapped into multiple
|
||||
processes. This memory should only be counted once when computing
|
||||
total memory usage. In the same way, the video memory on a graphics
|
||||
card or register memory on any device can be mapped into multiple
|
||||
processes. These mappings do not consume normal system RAM.</p>
|
||||
<p>This has been a frequently discussed topic on XFree86 mailing
|
||||
lists; see, for example:</p>
|
||||
<p><a href=
|
||||
"http://marc.theaimsgroup.com/?l=xfree-xpert&m=96835767116567&w=2"
|
||||
target=
|
||||
"_top">http://marc.theaimsgroup.com/?l=xfree-xpert&m=96835767116567&w=2</a></p>
|
||||
<p>Additionally, the nvidia X driver reserves virtual memory ranges
|
||||
that will never be backed by physical memory to use for addressing
|
||||
video memory that isn't directly mapped to the CPU. The amount of
|
||||
virtual memory reserved for this purpose will vary depending on GPU
|
||||
capabilities, and is printed to the X log:</p>
|
||||
<pre class="screen">
|
||||
[ 1859.106] (II) NVIDIA: Reserving 24576.00 MB of virtual memory for
|
||||
[ 1859.106] (II) NVIDIA: indirect memory access.
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>The <span><strong class="command">pmap</strong></span> utility
|
||||
described in the above thread is available in the "procps" package
|
||||
shipped with most recent Linux distributions, and is a useful tool
|
||||
in distinguishing between types of memory mappings. For example,
|
||||
while <span><strong class="command">top</strong></span> may
|
||||
indicate that X is using several GB of memory, the last line of
|
||||
output from the output of pmap (note that pmap may need to be run
|
||||
as root):</p>
|
||||
<pre class="screen">
|
||||
# pmap -d `pidof Xorg` | tail -n 1
|
||||
mapped: 25435416K writeable/private: 20908K shared: 10768K
|
||||
</pre>
|
||||
<p>reveals that X is really only using roughly 21MB of system RAM
|
||||
(the "writeable/private" value).</p>
|
||||
<p>Note, also, that X must allocate resources on behalf of X
|
||||
clients (the window manager, your web browser, etc); the X server's
|
||||
memory usage will increase as more clients request resources such
|
||||
as pixmaps, and decrease as you close X applications.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name="WhyDoApplicatio54851" id=
|
||||
"WhyDoApplicatio54851"></a></td>
|
||||
<td align="left" valign="top">
|
||||
<p><b>Why do applications that use DGA graphics fail?</b></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="answer">
|
||||
<td align="left" valign="top"></td>
|
||||
<td align="left" valign="top">
|
||||
<p>The NVIDIA driver does not support the graphics component of the
|
||||
XFree86-DGA (Direct Graphics Access) extension. Applications can
|
||||
use the XDGASelectInput() function to acquire relative pointer
|
||||
motion, but graphics-related functions such as XDGASetMode() and
|
||||
XDGAOpenFramebuffer() will fail.</p>
|
||||
<p>The graphics component of XFree86-DGA is not supported because
|
||||
it requires a CPU mapping of framebuffer memory. As graphics cards
|
||||
ship with increasing quantities of video memory, the NVIDIA X
|
||||
driver has had to switch to a more dynamic memory mapping scheme
|
||||
that is incompatible with DGA. Furthermore, DGA does not cooperate
|
||||
with other graphics rendering libraries such as Xlib and OpenGL
|
||||
because it accesses GPU resources directly.</p>
|
||||
<p>NVIDIA recommends that applications use OpenGL or Xlib, rather
|
||||
than DGA, for graphics rendering. Using rendering libraries other
|
||||
than DGA will yield better performance and improve interoperability
|
||||
with other X applications.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name="MyKernelLogCont895da" id=
|
||||
"MyKernelLogCont895da"></a></td>
|
||||
<td align="left" valign="top">
|
||||
<p><b>My kernel log contains messages that are prefixed with "Xid";
|
||||
what do these messages mean?</b></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="answer">
|
||||
<td align="left" valign="top"></td>
|
||||
<td align="left" valign="top">
|
||||
<p>"Xid" messages indicate that a general GPU error occurred, most
|
||||
often due to the driver misprogramming the GPU or to corruption of
|
||||
the commands sent to the GPU. These messages provide diagnostic
|
||||
information that can be used by NVIDIA to aid in debugging reported
|
||||
problems.</p>
|
||||
<p>Some information on how to interpret Xid messages is available
|
||||
here: <a href="http://docs.nvidia.com/deploy/xid-errors/index.html"
|
||||
target=
|
||||
"_top">http://docs.nvidia.com/deploy/xid-errors/index.html</a></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name="MyKernelLogCont0ecdc" id=
|
||||
"MyKernelLogCont0ecdc"></a></td>
|
||||
<td align="left" valign="top">
|
||||
<p><b>My kernel log contains the message "NVRM: Xid (...): 81, VGA
|
||||
Subsystem Error." How can I fix this?</b></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="answer">
|
||||
<td align="left" valign="top"></td>
|
||||
<td align="left" valign="top">
|
||||
<p>In some extreme cases, the VGA console can hang if messages are
|
||||
printed to a legacy VGA text console concurrently with applications
|
||||
that generate high GPU memory traffic.</p>
|
||||
<p>The solution to this problem is to not use a legacy VGA text
|
||||
console. Instead, on capable systems, use pure UEFI mode (not
|
||||
Compatibility Support Module (CSM)). On legacy SBIOS systems, use a
|
||||
framebuffer console such as vesafb.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name="IUseTheCoolbits0ea09" id=
|
||||
"IUseTheCoolbits0ea09"></a></td>
|
||||
<td align="left" valign="top">
|
||||
<p><b>I use the Coolbits overclocking interface to adjust my
|
||||
graphics card's clock frequencies, but the defaults are reset
|
||||
whenever X is restarted. How do I make my changes
|
||||
persistent?</b></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="answer">
|
||||
<td align="left" valign="top"></td>
|
||||
<td align="left" valign="top">
|
||||
<p>Clock frequency settings are not saved/restored automatically by
|
||||
default to avoid potential stability and other problems that may be
|
||||
encountered if the chosen frequency settings differ from the
|
||||
defaults qualified by the manufacturer. You can add an <code class=
|
||||
"filename">nvidia-settings</code> command to <code class=
|
||||
"filename">~/.xinitrc</code> to automatically apply custom clock
|
||||
frequency settings when the X server is started. See the
|
||||
<code class="filename">nvidia-settings(1)</code> manual page for
|
||||
more information on setting clock frequency settings on the command
|
||||
line.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name="WhyIsTheRefresh924ee" id=
|
||||
"WhyIsTheRefresh924ee"></a></td>
|
||||
<td align="left" valign="top">
|
||||
<p><b>Why is the refresh rate not reported correctly by utilities
|
||||
that use the XF86VidMode X extension and/or RandR X extension
|
||||
versions prior to 1.2 (e.g., `xrandr --q1`)?</b></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="answer">
|
||||
<td align="left" valign="top"></td>
|
||||
<td align="left" valign="top">
|
||||
<p>These extensions are not aware of multiple display devices on a
|
||||
single X screen; they only see the MetaMode bounding box, which may
|
||||
contain one or more actual modes. This means that if multiple
|
||||
MetaModes have the same bounding box, these extensions will not be
|
||||
able to distinguish between them. In order to support dynamic
|
||||
display configuration, the NVIDIA X driver must make each MetaMode
|
||||
appear to be unique and accomplishes this by using the refresh rate
|
||||
as a unique identifier.</p>
|
||||
<p>You can use `nvidia-settings -q RefreshRate` to query the actual
|
||||
refresh rate on each display device.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name="WhyDoesStarting61617" id=
|
||||
"WhyDoesStarting61617"></a></td>
|
||||
<td align="left" valign="top">
|
||||
<p><b>Why does starting certain applications result in Xlib error
|
||||
messages indicating extensions like "XFree86-VidModeExtension" or
|
||||
"SHAPE" are missing?</b></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="answer">
|
||||
<td align="left" valign="top"></td>
|
||||
<td align="left" valign="top">
|
||||
<p>If your X config file has a <code class=
|
||||
"computeroutput">Module</code> section that does not list the
|
||||
"extmod" module, some X server extensions may be missing, resulting
|
||||
in error messages of the form:</p>
|
||||
<pre class="screen">
|
||||
Xlib: extension "SHAPE" missing on display ":0.0"
|
||||
Xlib: extension "XFree86-VidModeExtension" missing on display ":0.0"
|
||||
Xlib: extension "XFree86-DGA" missing on display ":0.0"
|
||||
</pre>
|
||||
<p>You can solve this problem by adding the line below to your X
|
||||
config file's <code class="computeroutput">Module</code>
|
||||
section:</p>
|
||||
<pre class="screen">
|
||||
Load "extmod"
|
||||
</pre>
|
||||
<p></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name="WhereCanIFindOl8f618" id=
|
||||
"WhereCanIFindOl8f618"></a></td>
|
||||
<td align="left" valign="top">
|
||||
<p><b>Where can I find older driver versions?</b></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="answer">
|
||||
<td align="left" valign="top"></td>
|
||||
<td align="left" valign="top">
|
||||
<p>Please visit <a href=
|
||||
"https://download.nvidia.com/XFree86/Linux-x86_64/" target=
|
||||
"_top">https://download.nvidia.com/XFree86/Linux-x86_64/</a></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name="busid" id="busid"></a></td>
|
||||
<td align="left" valign="top">
|
||||
<p><b>What is the format of a PCI Bus ID?</b></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="answer">
|
||||
<td align="left" valign="top"></td>
|
||||
<td align="left" valign="top">
|
||||
<p>Different tools have different formats for the PCI Bus ID of a
|
||||
PCI device.</p>
|
||||
<p>The X server's "BusID" X configuration file option interprets
|
||||
the BusID string in the format "bus@domain:device:function" (the
|
||||
"@domain" portion is only needed if the PCI domain is non-zero), in
|
||||
decimal. More specifically,</p>
|
||||
<pre class="screen">
|
||||
"%d@%d:%d:%d", bus, domain, device, function
|
||||
</pre>
|
||||
<p>in printf(3) syntax. NVIDIA X driver logging, nvidia-xconfig,
|
||||
and nvidia-settings match the X configuration file BusID
|
||||
convention.</p>
|
||||
<p>The lspci(8) utility, in contrast, reports the PCI BusID of a
|
||||
PCI device in the format "domain:bus:device.function", printing the
|
||||
values in hexadecimal. More specifically,</p>
|
||||
<pre class="screen">
|
||||
"%04x:%02x:%02x.%x", domain, bus, device, function
|
||||
</pre>
|
||||
<p>in printf(3) syntax. The "Bus Location" reported in the
|
||||
information file matches the lspci format. Also, the name of
|
||||
per-GPU directory in /proc/driver/nvidia/gpus is the same as the
|
||||
corresponding GPU's PCI BusID in lspci format.</p>
|
||||
<p>On systems where both an integrated GPU and a PCI slot are
|
||||
present, setting the "BusID" option to "AXI" selects the integrated
|
||||
GPU. By default, not specifying this option or setting it to an
|
||||
empty string selects a discrete GPU if available, the integrated
|
||||
GPU otherwise.</p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name="randrmodelist" id=
|
||||
"randrmodelist"></a></td>
|
||||
<td align="left" valign="top">
|
||||
<p><b>Why doesn't the NVIDIA X driver make more display resolutions
|
||||
and refresh rates available via RandR?</b></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="answer">
|
||||
<td align="left" valign="top"></td>
|
||||
<td align="left" valign="top">
|
||||
<p>Prior to the 302.* driver series, the list of modes reported to
|
||||
applications by the NVIDIA X driver was not limited to the list of
|
||||
modes natively supported by a display device. In order to expose
|
||||
the largest possible set of modes on digital flat panel displays,
|
||||
which typically do not accept arbitrary mode timings, the driver
|
||||
maintained separate sets of "front-end" and "back-end" mode
|
||||
timings, and scaled between them to simulate the availability of
|
||||
more modes than would otherwise be supported.</p>
|
||||
<p>Front-end timings were the values reported to applications, and
|
||||
back-end timings were what was actually sent to the display. Both
|
||||
sets of timings went through the full mode validation process, with
|
||||
the back-end timings having the additional constraint that they
|
||||
must be provided by the display's EDID, as only EDID-provided modes
|
||||
can be safely assumed to be supported by the display hardware.
|
||||
Applications could request any available front-end timings, which
|
||||
the driver would implicitly scale to either the "best fit" or
|
||||
"native" mode timings. For example, an application might request an
|
||||
800x600 @ 60 Hz mode and the driver would provide it, but the real
|
||||
mode sent to the display would be 1920x1080 @ 30 Hz. While the
|
||||
availability of modes beyond those natively supported by a display
|
||||
was convenient for some uses, it created several problems. For
|
||||
example:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>The complete front-end timings were reported to applications,
|
||||
but only the width and height were actually used. This could cause
|
||||
confusion because in many cases, changing the front-end timings did
|
||||
not change the back-end timings. This was especially confusing when
|
||||
trying to change the refresh rate, because the refresh rate in the
|
||||
front-end timings was ignored, but was still reported to
|
||||
applications.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The front-end timings reported to the user could be different
|
||||
from the backend timings reported in the display device's on screen
|
||||
display, leading to user confusion. Finding out the back-end
|
||||
timings (e.g. to find the real refresh rate) required using the
|
||||
NVIDIA-specific NV-CONTROL X extension.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The process by which back-end timings were selected for use with
|
||||
any given front-end timings was not transparent to users, and this
|
||||
process could only be explicitly configured with NVIDIA-specific
|
||||
xorg.conf options or the NV-CONTROL X extension. Confusion over how
|
||||
changing front-end timings could affect the back-end timings was
|
||||
especially problematic in use cases that were sensitive to the
|
||||
timings the display device receives, such as NVIDIA 3D Vision.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>User-specified modes underwent normal mode validation, even
|
||||
though the timings in those modes were not used. For example, a
|
||||
1920x1080 @ 100 Hz mode might fail the VertRefresh check, even
|
||||
though the back-end timings might actually be 1920x1080 @ 30
|
||||
Hz.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
<p>Version 1.2 of the X Resize and Rotate extension (henceforth
|
||||
referred to as "RandR 1.2") allows configuration of display scaling
|
||||
in a much more flexible and standardized way. The protocol allows
|
||||
applications to choose exactly which (back-end) mode timing is
|
||||
used, and exactly how the screen is scaled to fill that mode. It
|
||||
also allows explicit control over which displays are enabled, and
|
||||
which portions of the screen they display. This also provides
|
||||
much-needed transparency: the mode timings reported by RandR 1.2
|
||||
are the actual mode timings being sent to the display. However,
|
||||
this means that only modes actually supported by the display are
|
||||
reported in the RandR 1.2 mode list. Scaling configurations, such
|
||||
as the 800x600 to 1920x1080 example above, need to be configured
|
||||
via the RandR 1.2 transform feature. Adding implicitly scaled modes
|
||||
to the mode list would conflict with the transform configuration
|
||||
options and reintroduce the same problems that the previous
|
||||
front-end/back-end timing system had.</p>
|
||||
<p>With the introduction of RandR 1.2 support to the 302.* driver
|
||||
series, the front-end/back-end timing system was abandoned, and the
|
||||
list of mode timings exposed by the NVIDIA X driver was simplified
|
||||
to include only those modes which would actually be driven by the
|
||||
hardware. Although it remained possible to manually configure all
|
||||
of the scaling configurations that were previously possible, and
|
||||
many scaling configurations which were previously impossible, this
|
||||
change resulted in some inconvenient losses of functionality:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>Applications which used RandR 1.1 or earlier or XF86VidMode to
|
||||
set modes no longer had the implicitly scaled front-end timings
|
||||
available to them. Many displays have EDIDs which advertise only
|
||||
the display's native resolution, or a list of resolutions that is
|
||||
otherwise small, compared to the list that would previously have
|
||||
been exposed as front-end timings, preventing these applications
|
||||
from setting modes that were possible with previous versions of the
|
||||
NVIDIA driver.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The <span><strong class=
|
||||
"command">nvidia-settings</strong></span> control panel, which
|
||||
formerly listed all available front-end modes for displays in its X
|
||||
Server Display Configuration page, only listed the actual back-end
|
||||
modes.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
<p>Subsequent driver releases restored some of this functionality
|
||||
without reverting to the front-end/back-end system:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>The NVIDIA X driver now builds a list of "Implicit MetaModes",
|
||||
which implicitly scale many common resolutions to a mode that is
|
||||
supported by the display. These modes are exposed to applications
|
||||
which use RandR 1.1 and XF86VidMode, as neither supports the
|
||||
scaling or other transform capabilities of RandR 1.2.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The resolution list in the <span><strong class=
|
||||
"command">nvidia-settings</strong></span> X Server Display
|
||||
Configuration page now includes explicitly scaled modes for many
|
||||
common resolutions which are not directly supported by the display.
|
||||
To reduce confusion, the scaled modes are identified as being
|
||||
scaled, and it is not possible to set a refresh rate for any of the
|
||||
scaled modes.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
<p>As mentioned previously, the RandR 1.2 mode list contains only
|
||||
modes which are supported by the display. Modern applications that
|
||||
wish to set modes other than those available in the RandR 1.2 mode
|
||||
list are encouraged to use RandR 1.2 transformations to program any
|
||||
required scaling operations. For example, the <span><strong class=
|
||||
"command">xrandr</strong></span> utility can program RandR scaling
|
||||
transformations, and the following command can scale a 1280x720
|
||||
mode to a display connected to output DVI-I-0 that does not support
|
||||
the desired mode, but does support 1920x1080:</p>
|
||||
<pre class="screen">
|
||||
xrandr --output DVI-I-0 --mode 1920x1080 --scale-from 1280x720
|
||||
</pre>
|
||||
<p></p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"editxconfig.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"commonproblems.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 6. Configuring X for the NVIDIA Driver </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 8. Common Problems</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,99 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 19. Configuring Flipping and UBB</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="programmingmodes.html" title=
|
||||
"Chapter 18. Programming Modes">
|
||||
<link rel="next" href="procinterface.html" title=
|
||||
"Chapter 20. Using the /proc File System Interface">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 19. Configuring
|
||||
Flipping and UBB</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"programmingmodes.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"procinterface.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="flippingubb" id=
|
||||
"flippingubb"></a>Chapter 19. Configuring Flipping and
|
||||
UBB</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>The NVIDIA Accelerated Linux Graphics Driver supports Unified
|
||||
Back Buffer (UBB) and OpenGL Flipping. These features can provide
|
||||
performance gains in certain situations.</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>Unified Back Buffer (UBB): UBB is available only on NVIDIA
|
||||
RTX/Quadro GPUs (Quadro NVS GPUs excluded) and is enabled by
|
||||
default when there is sufficient video memory available. This can
|
||||
be disabled with the <a href="xconfigoptions.html#UBB">UBB</a> X
|
||||
config option. When UBB is enabled, all windows share the same
|
||||
back, stencil and depth buffers. When there are many windows, the
|
||||
back, stencil and depth usage will never exceed the size of that
|
||||
used by a full screen window. However, even for a single small
|
||||
window, the back, stencil, and depth video memory usage is that of
|
||||
a full screen window. In that case video memory may be used less
|
||||
efficiently than in the non-UBB case.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Flipping: When OpenGL flipping is enabled, OpenGL can perform
|
||||
buffer swaps by changing which buffer is scanned out rather than
|
||||
copying the back buffer contents to the front buffer; this is
|
||||
generally a higher performance mechanism and allows tearless
|
||||
swapping during the vertical retrace (when __GL_SYNC_TO_VBLANK is
|
||||
set).</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"programmingmodes.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"procinterface.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 18. Programming Modes </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 20. Using the <code class=
|
||||
"computeroutput">/proc</code> File System Interface</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,633 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 32. Configuring Frame Lock and
|
||||
Genlock</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="sli.html" title=
|
||||
"Chapter 31. Configuring SLI and Multi-GPU Mosaic">
|
||||
<link rel="next" href="depth30.html" title=
|
||||
"Chapter 33. Configuring Depth 30 Displays">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 32. Configuring
|
||||
Frame Lock and Genlock</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"sli.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"depth30.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="framelock" id=
|
||||
"framelock"></a>Chapter 32. Configuring Frame Lock and
|
||||
Genlock</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>NOTE: Frame Lock and Genlock features are supported only on
|
||||
specific hardware, as noted below.</p>
|
||||
<p>Visual computing applications that involve multiple displays, or
|
||||
even multiple windows within a display, can require special signal
|
||||
processing and application controls in order to function properly.
|
||||
For example, in order to produce quality video recording of
|
||||
animated graphics, the graphics display must be synchronized with
|
||||
the video camera. As another example, applications presented on
|
||||
multiple displays must be synchronized in order to complete the
|
||||
illusion of a larger, virtual canvas.</p>
|
||||
<p>This synchronization is enabled through the Frame Lock and
|
||||
Genlock capabilities of the NVIDIA driver. This section describes
|
||||
the setup and use of Frame Lock and Genlock.</p>
|
||||
<h3>Definition of Terms</h3>
|
||||
<p>GENLOCK: Genlock refers to the process of synchronizing the
|
||||
pixel scanning of one or more displays to an external
|
||||
synchronization source. Genlock requires the external signal to be
|
||||
either TTL or composite, such as used for NTSC, PAL, or HDTV. It
|
||||
should be noted that Genlock is guaranteed only to be
|
||||
frame-synchronized, and not necessarily pixel-synchronized.</p>
|
||||
<p>FRAME LOCK: Frame Lock involves the use of hardware to
|
||||
synchronize the frames on each display in a connected system. When
|
||||
graphics and video are displayed across multiple monitors, Frame
|
||||
Locked systems help maintain image continuity to create a virtual
|
||||
canvas. Frame Lock is especially critical for stereo viewing, where
|
||||
the left and right fields must be in sync across all displays.</p>
|
||||
<p>In short, to enable Genlock means to sync to an external signal.
|
||||
To enable Frame Lock means to sync 2 or more display devices to a
|
||||
signal generated internally by the hardware, and to use both means
|
||||
to sync 2 or more display devices to an external signal.</p>
|
||||
<p>SWAP SYNC: Swap sync refers to the synchronization of buffer
|
||||
swaps of multiple application windows. By means of swap sync,
|
||||
applications running on multiple systems can synchronize the
|
||||
application buffer swaps between all the systems. In order to work
|
||||
across multiple systems, swap sync requires that the systems are
|
||||
Frame Locked.</p>
|
||||
<p>QUADRO SYNC DEVICE: A Quadro Sync Device refers to a device
|
||||
capable of Frame Lock/Genlock. See "Supported Hardware" below.</p>
|
||||
<h3>Supported Hardware</h3>
|
||||
<p>Frame Lock and Genlock are supported for the following
|
||||
hardware:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>Quadro Sync II, used in conjunction with an NVIDIA RTX A6000,
|
||||
NVIDIA A40, Quadro RTX 8000, Quadro RTX 6000, Quadro RTX 5000,
|
||||
Quadro RTX 4000, Quadro GV100, Quadro GP100, Quadro P6000, Quadro
|
||||
P5000, or Quadro P4000</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Quadro Sync, used in conjunction with a Quadro M6000 24GB,
|
||||
Quadro M6000, Quadro M5000, Quadro M4000, Quadro K6000, Quadro
|
||||
K5200, Quadro K5000, or Quadro K4200</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
<h3>Hardware Setup</h3>
|
||||
<p>Before you begin, you should check that your hardware has been
|
||||
properly installed. The following steps must be performed while the
|
||||
system is off.</p>
|
||||
<div class="orderedlist">
|
||||
<ol type="1">
|
||||
<li>
|
||||
<p>On a Quadro Sync card with four Sync connectors, connect a
|
||||
ribbon cable to any of the four connectors, if none are already
|
||||
connected.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Install the Quadro Sync card in any available slot. Note that
|
||||
the slot itself is only used for physical mounting, so even a known
|
||||
"bad" slot is acceptable. The slot must be close enough to the
|
||||
graphics card that the ribbon cable can reach.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>On a Quadro Sync card with four Sync connectors, external power
|
||||
is required. Connect a 6-pin PCIe power cable or a SATA power cable
|
||||
to the card.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Connect the other end of the ribbon cable to the Quadro Sync
|
||||
connector on the graphics card.</p>
|
||||
<p>On supported Quadro Kepler cards, the Quadro Sync connector is
|
||||
identical in appearance to the SLI connector. The ribbon cable from
|
||||
the Quadro Sync card should be connected to the connector labeled
|
||||
"SDI | SYNC". If the ribbon cable is connected to the SLI
|
||||
connector, the GPU will not be able to synchronize with the Quadro
|
||||
Sync card.</p>
|
||||
</li>
|
||||
</ol>
|
||||
</div>
|
||||
<p>You may now boot the system and begin the software setup of
|
||||
Genlock and/or Frame Lock. These instructions assume that you have
|
||||
already successfully installed the NVIDIA Accelerated Linux Driver
|
||||
Set. If you have not done so, see <a href="installdriver.html"
|
||||
title=
|
||||
"Chapter 4. Installing the NVIDIA Driver">Chapter 4,
|
||||
<i>Installing the NVIDIA Driver</i></a>.</p>
|
||||
<h3>Configuration with nvidia-settings GUI</h3>
|
||||
<p>Frame Lock and Genlock are configured through the
|
||||
nvidia-settings utility. See the <code class=
|
||||
"filename">nvidia-settings(1)</code> man page, and the
|
||||
nvidia-settings online help (click the "Help" button in the lower
|
||||
right corner of the interface for per-page help information).</p>
|
||||
<p>From the nvidia-settings Frame Lock panel, you may control the
|
||||
addition of Quadro Sync (and display) devices to the Frame
|
||||
Lock/Genlock group, monitor the status of that group, and
|
||||
enable/disable Frame Lock and Genlock.</p>
|
||||
<p>After the system has booted and X Windows has been started, run
|
||||
nvidia-settings as</p>
|
||||
<pre class="screen">
|
||||
% nvidia-settings
|
||||
</pre>
|
||||
<p>You may wish to start this utility before continuing, as we
|
||||
refer to it frequently in the subsequent discussion.</p>
|
||||
<p>The setup of Genlock and Frame Lock are described separately. We
|
||||
then describe the use of Genlock and Frame Lock together.</p>
|
||||
<h3>Genlock Setup</h3>
|
||||
<p>After the system has been booted, connect the external signal to
|
||||
the house sync connector (the BNC connector) on either the graphics
|
||||
card or the Quadro Sync card. There is a status LED next to the
|
||||
connector. A solid red or unlit LED indicates that the hardware
|
||||
cannot detect the timing signal. A green LED indicates that the
|
||||
hardware is detecting a timing signal. An occasional red flash is
|
||||
okay. On a Quadro Sync card with four Sync connectors, a blinking
|
||||
green LED indicates that the server is locked to the house sync.
|
||||
The Quadro Sync device (graphics card or Quadro Sync card) will
|
||||
need to be configured correctly for the signal to be detected.</p>
|
||||
<p>In the Frame Lock panel of the nvidia-settings interface, add
|
||||
the X Server that contains the display and Quadro Sync devices that
|
||||
you would like to sync to this external source by clicking the "Add
|
||||
Devices..." button. An X Server is typically specified in the
|
||||
format <code class="computeroutput">system:m</code>, e.g.:</p>
|
||||
<pre class="screen">
|
||||
mycomputer.domain.com:0
|
||||
</pre>
|
||||
<p>or</p>
|
||||
<pre class="screen">
|
||||
localhost:0
|
||||
</pre>
|
||||
<p>After adding an X Server, rows will appear in the "Quadro Sync
|
||||
Devices" section on the Frame Lock panel that displays relevant
|
||||
status information about the Quadro Sync devices, GPUs attached to
|
||||
those Quadro Sync devices and the display devices driven by those
|
||||
GPUs. In particular, the Quadro Sync rows will display the server
|
||||
name and Quadro Sync device number along with "Receiving" LED,
|
||||
"Rate", "House" LED, "Port 0"/"Port 1" Images, and "Delay"
|
||||
information. The GPU rows will display the GPU product name
|
||||
information along with the GPU ID for the server. The Display
|
||||
Device rows will show the display device name and device type along
|
||||
with server/client check boxes, refresh rate, "Timing" LED and
|
||||
"Stereo" LED.</p>
|
||||
<p>Once the Quadro Sync and display devices have been added to the
|
||||
Frame Lock/Genlock group, a Server display device will need to be
|
||||
selected. This is done by selecting the "Server" check box of the
|
||||
desired display device.</p>
|
||||
<p>If you are using a Quadro Sync card, you must also click the
|
||||
"Use House Sync if Present" check box. To enable synchronization of
|
||||
this Quadro Sync device to the external source, click the "Enable
|
||||
Frame Lock" button. The display device(s) may take a moment to
|
||||
stabilize. If it does not stabilize, you may have selected a
|
||||
synchronization signal that the system cannot support. You should
|
||||
disable synchronization by clicking the "Disable Frame Lock" button
|
||||
and check the external sync signal.</p>
|
||||
<p>Modifications to Genlock settings (e.g., "Use House Sync if
|
||||
Present", "Add Devices...") must be done while synchronization is
|
||||
disabled.</p>
|
||||
<p><a name="framelocksetup" id="framelocksetup"></a></p>
|
||||
<h3>Frame Lock Setup</h3>
|
||||
<p>Frame Lock is supported across an arbitrary number of Quadro
|
||||
Sync systems, although mixing different generations of Quadro Sync
|
||||
products in the same Frame Lock group is not supported.
|
||||
Additionally, each system to be included in the Frame Lock group
|
||||
must be configured with identical mode timings. See <a href=
|
||||
"programmingmodes.html" title=
|
||||
"Chapter 18. Programming Modes">Chapter 18,
|
||||
<i>Programming Modes</i></a> for information on mode timings.</p>
|
||||
<p>Connect the systems through their RJ45 ports using standard CAT5
|
||||
patch cables. These ports are located on the Frame Lock card.
|
||||
<span class="emphasis"><em>Do not connect a Frame Lock port to an
|
||||
ethernet card or hub. Doing so may permanently damage the
|
||||
hardware</em></span>. The connections should be made in a
|
||||
daisy-chain fashion: each card has two RJ45 ports, call them 1 and
|
||||
2. Connect port 1 of system A to port 2 of system B, connect port 1
|
||||
of system B to port 2 of system C, etc. Note that you will always
|
||||
have two empty ports in your Frame Lock group.</p>
|
||||
<p>The ports self-configure as inputs or outputs once Frame Lock is
|
||||
enabled. Each port has a yellow and a green LED that reflect this
|
||||
state. A flashing yellow LED indicates an output and a flashing
|
||||
green LED indicates an input. On a Quadro Sync card with four Sync
|
||||
connectors, a solid green LED indicates that the port has been
|
||||
configured as an input, but no sync pulse is detected, and a solid
|
||||
yellow LED means the card is configured as an output, but no sync
|
||||
is being transmitted.</p>
|
||||
<p>In the Frame Lock panel of the nvidia-settings interface, add
|
||||
the X server that contains the display devices that you would like
|
||||
to include in the Frame Lock group by clicking the "Add Devices..."
|
||||
button (see the description for adding display devices in the
|
||||
previous section on GENLOCK SETUP. Like the Genlock status
|
||||
indicators, the "Port 0" and "Port 1" columns in the table on the
|
||||
Frame Lock panel contain indicators whose states mirror the states
|
||||
of the physical LEDs on the RJ45 ports. Thus, you may monitor the
|
||||
status of these ports from the software interface.</p>
|
||||
<p>Any X Server can be added to the Frame Lock group, provided
|
||||
that</p>
|
||||
<div class="orderedlist">
|
||||
<ol type="1">
|
||||
<li>
|
||||
<p>The system supporting the X Server is configured to support
|
||||
Frame Lock and is connected via RJ45 cable to the other systems in
|
||||
the Frame Lock group.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The system driving nvidia-settings can communicate with the X
|
||||
server that is to be included for Frame Lock. This means that
|
||||
either the server must be listening over TCP and the system's
|
||||
firewall is permissive enough to allow remote X11 display
|
||||
connections, or that you've configured an alternative mechanism
|
||||
such as ssh(1) forwarding between the machines.</p>
|
||||
<p>For the case of listening over TCP, verify that the "-nolisten
|
||||
tcp" commandline option was not used when starting the X server.
|
||||
You can find the X server commandline with a command such as</p>
|
||||
<pre class="screen">
|
||||
% ps ax | grep X
|
||||
</pre>
|
||||
<p>If "-nolisten tcp" is on the X server commandline, consult your
|
||||
Linux distribution documentation for details on how to properly
|
||||
remove this option. For example, distributions configured to use
|
||||
the GDM login manager may need to set "DisallowTCP=false" in the
|
||||
GDM configuration file (e.g., /etc/gdm/custom.conf,
|
||||
/etc/X11/gdm/gdm.conf, or /etc/gdb/gdb.conf; the exact
|
||||
configuration file name and path varies by the distribution). Or,
|
||||
distributions configured to use the KDM login manager may have the
|
||||
line</p>
|
||||
<pre class="screen">
|
||||
ServerArgsLocal=-nolisten tcp
|
||||
</pre>
|
||||
<p>in their kdm file (e.g., /etc/kde3/kdm/kdmrc). This line can be
|
||||
commented out by prepending with "#". Starting with version 1.17,
|
||||
the X.org X server no longer allows listening over TCP by default
|
||||
when built with its default build configuration options. On newer X
|
||||
servers that were not built with --enable-listen-tcp at build
|
||||
configuration time, in addition to ensuring that "-nolisten tcp" is
|
||||
not set on the X server commandline, you will also need to ensure
|
||||
that "-listen tcp" is explicitly set.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The system driving nvidia-settings can locate and has display
|
||||
privileges on the X server that is to be included for Frame
|
||||
Lock.</p>
|
||||
<p>A system can gain display privileges on a remote system by
|
||||
executing</p>
|
||||
<pre class="screen">
|
||||
% xhost +
|
||||
</pre>
|
||||
<p>on the remote system. See the xhost(1) man page for details.</p>
|
||||
</li>
|
||||
</ol>
|
||||
</div>
|
||||
<p>Typically, Frame Lock is controlled through one of the systems
|
||||
that will be included in the Frame Lock group. While this is not a
|
||||
requirement, note that nvidia-settings will only display the Frame
|
||||
Lock panel when running on an X server that supports Frame
|
||||
Lock.</p>
|
||||
<p>To enable synchronization on these display devices, click the
|
||||
"Enable Frame Lock" button. The screens may take a moment to
|
||||
stabilize. If they do not stabilize, you may have selected mode
|
||||
timings that one or more of the systems cannot support. In this
|
||||
case you should disable synchronization by clicking the "Disable
|
||||
Frame Lock" button and refer to <a href="programmingmodes.html"
|
||||
title="Chapter 18. Programming Modes">Chapter 18,
|
||||
<i>Programming Modes</i></a> for information on mode timings.</p>
|
||||
<p>Modifications to Frame Lock settings (e.g. "Add/Remove
|
||||
Devices...") must be done while synchronization is disabled.</p>
|
||||
<p>nvidia-settings will not automatically enable Frame Lock via the
|
||||
nvidia-settings.rc file. To enable Frame Lock when starting the X
|
||||
server, a line such as the following can be added to the
|
||||
<code class="filename">~/.xinitrc</code> file:</p>
|
||||
<pre class="screen">
|
||||
# nvidia-settings -a [gpu:0]/FrameLockEnable=1
|
||||
</pre>
|
||||
<p></p>
|
||||
<h3>Frame Lock + Genlock</h3>
|
||||
<p>The use of Frame Lock and Genlock together is a simple extension
|
||||
of the above instructions for using them separately. You should
|
||||
first follow the instructions for <a href=
|
||||
"framelock.html#framelocksetup" title="Frame Lock Setup">Frame Lock
|
||||
Setup</a>, and then to one of the systems that will be included in
|
||||
the Frame Lock group, attach an external sync source. In order to
|
||||
sync the Frame Lock group to this single external source, you must
|
||||
select a display device driven by the GPU connected to the Quadro
|
||||
Sync card that is connected to the external source to be the signal
|
||||
server for the group. This is done by selecting the check box
|
||||
labeled "Server" of the tree on the Frame Lock panel in
|
||||
nvidia-settings. If you are using a Quadro Sync based Frame Lock
|
||||
group, you must also select the "Use House Sync if Present" check
|
||||
box. Enable synchronization by clicking the "Enable Frame Lock"
|
||||
button. As with other Frame Lock/Genlock controls, you must select
|
||||
the signal server while synchronization is disabled.</p>
|
||||
<h3>GPU Status LEDs on the Quadro Sync Card</h3>
|
||||
<p>In addition to the graphical indicators in the control panel
|
||||
described in the Genlock Setup section above, the Quadro Sync card
|
||||
has two status LEDs for each of the four ports:</p>
|
||||
<p>A sync status LED indicates the sync status for each port. An
|
||||
unlit LED indicates that no GPU is connected to the port; a steady
|
||||
amber LED indicates that a GPU is connected, but not synced to any
|
||||
sync source; and a steady green LED indicates that a GPU is
|
||||
connected and in sync with an internal or external sync source. A
|
||||
flashing LED indicates that a connected GPU is in the process of
|
||||
locking to a sync source; flashing green indicates that the sync
|
||||
source's timings are within a reasonable range, and flashing amber
|
||||
indicates that the timings are out of range, and the GPU may be
|
||||
unable to lock to the sync source.</p>
|
||||
<p>A stereo status LED indicates the stereo sync status for each
|
||||
port. The LED will be lit steady amber when the card first powers
|
||||
on. An unlit LED indicates that stereo is not active, or that no
|
||||
GPU is connected; a blinking green LED indicates that stereo is
|
||||
active, but not locked to the stereo master; and a steady green LED
|
||||
indicates that stereo is active and locked to the stereo
|
||||
master.</p>
|
||||
<h3>Configuration with nvidia-settings command line</h3>
|
||||
<p>Frame Lock may also be configured through the nvidia-settings
|
||||
command line. This method of configuring Frame Lock may be useful
|
||||
in a scripted environment to automate the setup process. (Note that
|
||||
the examples listed below depend on the actual hardware
|
||||
configuration and as such may not work as-is.)</p>
|
||||
<p>To properly configure Frame Lock, the following steps should be
|
||||
completed:</p>
|
||||
<div class="orderedlist">
|
||||
<ol type="1">
|
||||
<li>
|
||||
<p>Make sure Frame Lock Sync is disabled on all GPUs.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Make sure all display devices that are to be Frame Locked have
|
||||
the same refresh rate.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Configure which (display/GPU) device should be the master.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Configure house sync (if applicable).</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Configure the slave display devices.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Enable Frame Lock sync on the master GPU.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Enable Frame Lock sync on the slave GPUs.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Toggle the test signal on the master GPU (for testing the
|
||||
hardware connectivity.)</p>
|
||||
</li>
|
||||
</ol>
|
||||
</div>
|
||||
<p></p>
|
||||
<p>For a full list of the nvidia-settings Frame Lock attributes,
|
||||
please see the <code class="filename">nvidia-settings(1)</code> man
|
||||
page. Examples:</p>
|
||||
<div class="orderedlist">
|
||||
<ol type="1">
|
||||
<li>
|
||||
<p>1 System, 1 Frame Lock board, 1 GPU, and 1 display device
|
||||
syncing to the house signal:</p>
|
||||
<pre class="screen">
|
||||
# - Make sure Frame Lock sync is disabled
|
||||
nvidia-settings -a [gpu:0]/FrameLockEnable=0
|
||||
nvidia-settings -q [gpu:0]/FrameLockEnable
|
||||
|
||||
# - Enable use of house sync signal
|
||||
nvidia-settings -a [framelock:0]/FrameLockUseHouseSync=1
|
||||
|
||||
# - Configure the house sync signal video mode
|
||||
nvidia-settings -a [framelock:0]/FrameLockVideoMode=0
|
||||
|
||||
# - Query the enabled displays on the gpu(s)
|
||||
nvidia-settings -V all -q gpus
|
||||
|
||||
# - Check the refresh rate is as desired
|
||||
nvidia-settings -q [dpy:DVI-I-0]/RefreshRate
|
||||
|
||||
# - Query the valid Frame Lock configurations for the display device
|
||||
nvidia-settings -q [dpy:DVI-I-0]/FrameLockDisplayConfig
|
||||
|
||||
# - Set DVI-I-0 as a slave (this display will be synchronized to the
|
||||
# input signal)
|
||||
#
|
||||
# NOTE: FrameLockDisplayConfig takes one of three values:
|
||||
# 0 (disabled), 1 (client), 2 (server).
|
||||
nvidia-settings -a [dpy:DVI-I-0]/FrameLockDisplayConfig=0
|
||||
|
||||
# - Enable Frame Lock
|
||||
nvidia-settings -a [gpu:0]/FrameLockEnable=1
|
||||
|
||||
# - Toggle the test signal
|
||||
nvidia-settings -a [gpu:0]/FrameLockTestSignal=1
|
||||
nvidia-settings -a [gpu:0]/FrameLockTestSignal=0
|
||||
</pre>
|
||||
<p></p>
|
||||
</li>
|
||||
<li>
|
||||
<p>2 Systems, each with 2 GPUs, 1 Frame Lock board and 1 display
|
||||
device per GPU syncing from the first system's first display
|
||||
device:</p>
|
||||
<pre class="screen">
|
||||
# - Make sure Frame Lock sync is disabled on all gpus
|
||||
nvidia-settings -a myserver:0[gpu]/FrameLockEnable=0
|
||||
nvidia-settings -a myslave1:0[gpu]/FrameLockEnable=0
|
||||
|
||||
# - Disable the house sync signal on the master device
|
||||
nvidia-settings -a myserver:0[framelock:0]/FrameLockUseHouseSync=0
|
||||
|
||||
# - Query the enabled displays on the GPUs
|
||||
nvidia-settings -c myserver:0 -q gpus
|
||||
nvidia-settings -c myslave1:0 -q gpus
|
||||
|
||||
# - Check the refresh rate is the same for all displays
|
||||
nvidia-settings -q myserver:0[dpy]/RefreshRate
|
||||
nvidia-settings -q myslave1:0[dpy]/RefreshRate
|
||||
|
||||
# - Query the valid Frame Lock configurations for the display devices
|
||||
nvidia-settings -q myserver:0[dpy]/FrameLockDisplayConfig
|
||||
nvidia-settings -q myslave1:0[dpy]/FrameLockDisplayConfig
|
||||
|
||||
# - Set the server display device
|
||||
nvidia-settings -a myserver:0[dpy:DVI-I-0]/FrameLockDisplayConfig=2
|
||||
|
||||
# - Set the slave display devices
|
||||
nvidia-settings -a myserver:0[dpy:DVI-I-1]/FrameLockDisplayConfig=1
|
||||
nvidia-settings -a myslave1:0[dpy]/FrameLockDisplayConfig=1
|
||||
|
||||
# - Enable Frame Lock on server
|
||||
nvidia-settings -a myserver:0[gpu:0]/FrameLockEnable=1
|
||||
|
||||
# - Enable Frame Lock on slave devices
|
||||
nvidia-settings -a myserver:0[gpu:1]/FrameLockEnable=1
|
||||
nvidia-settings -a myslave1:0[gpu]/FrameLockEnable=1
|
||||
|
||||
# - Toggle the test signal (on the master GPU)
|
||||
nvidia-settings -a myserver:0[gpu:0]/FrameLockTestSignal=1
|
||||
nvidia-settings -a myserver:0[gpu:0]/FrameLockTestSignal=0
|
||||
</pre>
|
||||
<p></p>
|
||||
</li>
|
||||
<li>
|
||||
<p>1 System, 4 GPUs, 2 Frame Lock boards and 2 display devices per
|
||||
GPU syncing from the first GPU's display device:</p>
|
||||
<pre class="screen">
|
||||
# - Make sure Frame Lock sync is disabled
|
||||
nvidia-settings -a [gpu]/FrameLockEnable=0
|
||||
|
||||
# - Disable the house sync signal on the master device
|
||||
nvidia-settings -a [framelock:0]/FrameLockUseHouseSync=0
|
||||
|
||||
# - Query the enabled displays on the GPUs
|
||||
nvidia-settings -V all -q gpus
|
||||
|
||||
# - Check the refresh rate is the same for all displays
|
||||
nvidia-settings -q [dpy]/RefreshRate
|
||||
|
||||
# - Query the valid Frame Lock configurations for the display devices
|
||||
nvidia-settings -q [dpy]/FrameLockDisplayConfig
|
||||
|
||||
# - Set the master display device
|
||||
nvidia-settings -a [gpu:0.dpy:DVI-I-0]/FrameLockDisplayConfig=2
|
||||
|
||||
# - Set the slave display devices
|
||||
nvidia-settings -a [gpu:0.dpy:DVI-I-1]/FrameLockDisplayConfig=1
|
||||
nvidia-settings -a [gpu:1.dpy]/FrameLockDisplayConfig=1
|
||||
nvidia-settings -a [gpu:2.dpy]/FrameLockDisplayConfig=1
|
||||
nvidia-settings -a [gpu:3.dpy]/FrameLockDisplayConfig=1
|
||||
|
||||
# - Enable Frame Lock on master GPU
|
||||
nvidia-settings -a [gpu:0]/FrameLockEnable=1
|
||||
|
||||
# - Enable Frame Lock on slave devices
|
||||
nvidia-settings -a [gpu:1]/FrameLockEnable=1
|
||||
nvidia-settings -a [gpu:2]/FrameLockEnable=1
|
||||
nvidia-settings -a [gpu:3]/FrameLockEnable=1
|
||||
|
||||
# - Toggle the test signal
|
||||
nvidia-settings -a [gpu:0]/FrameLockTestSignal=1
|
||||
nvidia-settings -a [gpu:0]/FrameLockTestSignal=0
|
||||
</pre>
|
||||
<p></p>
|
||||
</li>
|
||||
</ol>
|
||||
</div>
|
||||
<p></p>
|
||||
<h3>Leveraging Frame Lock/Genlock in OpenGL</h3>
|
||||
<p>With the GLX_NV_swap_group extension, OpenGL applications can be
|
||||
implemented to join a group of applications within a system for
|
||||
local swap sync, and bind the group to a barrier for swap sync
|
||||
across a Frame Lock group. A universal frame counter is also
|
||||
provided to promote synchronization across applications.</p>
|
||||
<h3>Frame Lock Restrictions:</h3>
|
||||
<p>The following restrictions must be met for enabling Frame
|
||||
Lock:</p>
|
||||
<div class="orderedlist">
|
||||
<ol type="1">
|
||||
<li>
|
||||
<p>All display devices set as client in a Frame Lock group must
|
||||
have the same mode timings as the server (master) display device.
|
||||
If a House Sync signal is used (instead of internal timings), all
|
||||
client display devices must be set to have the same refresh rate as
|
||||
the incoming house sync signal.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>All X Screens (driving the selected client/server display
|
||||
devices) must have the same stereo setting. See the <a href=
|
||||
"xconfigoptions.html#Stereo">Stereo</a> X configuration option for
|
||||
instructions on how to set the stereo X option.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>In configurations with more than one display device per GPU, we
|
||||
recommend enabling Frame Lock on all display devices on those
|
||||
GPUs.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Virtual terminal switching or mode switching will disable Frame
|
||||
Lock on the display device. Note that the glXQueryFrameCountNV
|
||||
entry point (provided by the GLX_NV_swap_group extension) will only
|
||||
provide incrementing numbers while Frame Lock is enabled.
|
||||
Therefore, applications that use glXQueryFrameCountNV to control
|
||||
animation will appear to stop animating while Frame Lock is
|
||||
disabled.</p>
|
||||
</li>
|
||||
</ol>
|
||||
</div>
|
||||
<p></p>
|
||||
<h3>Supported Frame Lock Configurations:</h3>
|
||||
<p>The following configurations are currently supported:</p>
|
||||
<div class="orderedlist">
|
||||
<ol type="1">
|
||||
<li>
|
||||
<p>Basic Frame Lock: Single GPU, Single X Screen, Single Display
|
||||
Device with or without OpenGL applications that make use of
|
||||
Quad-Buffered Stereo and/or the GLX_NV_swap_group extension.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Frame Lock + TwinView: Single GPU, Single X Screen, Multiple
|
||||
Display Devices with or without OpenGL applications that make use
|
||||
of Quad-Buffered Stereo and/or the GLX_NV_swap_group extension.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Frame Lock + Xinerama: 1 or more GPU(s), Multiple X Screens,
|
||||
Multiple Display Devices with or without OpenGL applications that
|
||||
make use of Quad-Buffered Stereo and/or the GLX_NV_swap_group
|
||||
extension.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Frame Lock + TwinView + Xinerama: 1 or more GPU(s), Multiple X
|
||||
Screens, Multiple Display Devices with or without OpenGL
|
||||
applications that make use of Quad-Buffered Stereo and/or the
|
||||
GLX_NV_swap_group extension.</p>
|
||||
</li>
|
||||
</ol>
|
||||
</div>
|
||||
<p></p>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"sli.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"depth30.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 31. Configuring SLI and Multi-GPU
|
||||
Mosaic </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 33. Configuring Depth 30 Displays</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,121 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 40. GBM and GBM-based Wayland
|
||||
Compositors</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="xwayland.html" title=
|
||||
"Chapter 39. OpenGL and Vulkan on Xwayland">
|
||||
<link rel="next" href="addressingcapabilities.html" title=
|
||||
"Chapter 41. Addressing Capabilities">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 40. GBM and
|
||||
GBM-based Wayland Compositors</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"xwayland.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"addressingcapabilities.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="gbm" id=
|
||||
"gbm"></a>Chapter 40. GBM and GBM-based Wayland
|
||||
Compositors</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<h3>Overview</h3>
|
||||
<p>GBM is a memory allocation API developed as a component of the
|
||||
Mesa project. Most Wayland compositors use the GBM API to
|
||||
initialize an EGLDisplay object directly on a GPU, and to allocate
|
||||
the EGLSurface representing the desktop. The NVIDIA driver includes
|
||||
a GBM backend enabling the use of such software on NVIDIA GPUs. A
|
||||
GBM EGL external platform library is also included to enable the
|
||||
use of GBM objects in EGL.</p>
|
||||
<h3>Requirements</h3>
|
||||
<p>The following are necessary to enable use of the NVIDIA driver's
|
||||
GBM backend and its EGL and related Wayland client support:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>DRM KMS must be enabled. See <a href="kms.html" title=
|
||||
"Chapter 36. Direct Rendering Manager Kernel Modesetting (DRM KMS)">
|
||||
Chapter 36, <i>Direct Rendering Manager Kernel Modesetting
|
||||
(DRM KMS)</i></a> for details.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>libgbm.so.1 from Mesa version 21.2 (<a href=
|
||||
"https://gitlab.freedesktop.org/mesa/mesa" target=
|
||||
"_top">https://gitlab.freedesktop.org/mesa/mesa</a>).</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>egl-wayland version 1.1.8 or later must be present (if installed
|
||||
separately from the the NVIDIA driver). To support applications
|
||||
that use the wl_drm Wayland protocol to select a GPU to render on,
|
||||
such as Xwayland, version 1.1.9 or later must be present.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
<h3>Xwayland and GBM</h3>
|
||||
<p>Xwayland uses the GLAMOR backend to accelerate X application
|
||||
rendering using EGL. While not required for basic functionality,
|
||||
GLAMOR acceleration is required for good performance when running
|
||||
accelerated Vulkan or OpenGL X11 applications. The GLAMOR
|
||||
integration code in Xwayland has paths to use either EGLStreams or
|
||||
GBM to allocate surfaces for use with accelerated rendering. To use
|
||||
the GBM path with the NVIDIA driver's GBM backend and GBM EGL
|
||||
external platform library, the installed copy of Xwayland should be
|
||||
a build from the master branch of <a href=
|
||||
"https://gitlab.freedesktop.org/xorg/xserver" target=
|
||||
"_top">https://gitlab.freedesktop.org/xorg/xserver</a> at least as
|
||||
recent as commit 5daf42b4. Xwayland versions 21.1.3 and above
|
||||
satisfy this requirement.</p>
|
||||
<p>See <a href="xwayland.html" title=
|
||||
"Chapter 39. OpenGL and Vulkan on Xwayland">Chapter 39,
|
||||
<i>OpenGL and Vulkan on Xwayland</i></a> for more details on
|
||||
Xwayland support in the NVIDIA driver.</p>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"xwayland.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"addressingcapabilities.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 39. OpenGL and Vulkan on Xwayland </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 41. Addressing Capabilities</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,250 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Appendix D. GLX Support</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="appendices.html" title=
|
||||
"Part II. Appendices">
|
||||
<link rel="prev" href="displaydevicenames.html" title=
|
||||
"Appendix C. Display Device Names">
|
||||
<link rel="next" href="dpi.html" title=
|
||||
"Appendix E. Dots Per Inch">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Appendix D. GLX
|
||||
Support</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"displaydevicenames.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part II. Appendices</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"dpi.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="appendix" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="glxsupport" id=
|
||||
"glxsupport"></a>Appendix D. GLX Support</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>This release supports GLX 1.4.</p>
|
||||
<p>Additionally, the following GLX extensions are supported on
|
||||
appropriate GPUs:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>GLX_EXT_visual_info</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_EXT_visual_rating</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_SGIX_fbconfig</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_SGIX_pbuffer</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_ARB_get_proc_address</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_SGI_video_sync</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_SGI_swap_control</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_ARB_multisample</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_NV_float_buffer</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_ARB_fbconfig_float</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_NV_swap_group</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_NV_video_out</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_EXT_texture_from_pixmap</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_NV_copy_image</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_ARB_create_context</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_EXT_import_context</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_EXT_fbconfig_packed_float</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_EXT_framebuffer_sRGB</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_NV_present_video</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_NV_multisample_coverage</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_EXT_swap_control</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_NV_video_capture</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_ARB_create_context_profile</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_EXT_create_context_es_profile</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_EXT_create_context_es2_profile</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_EXT_swap_control_tear</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_EXT_buffer_age</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_ARB_create_context_robustness</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_ARB_context_flush_control</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_ARB_create_context_no_error</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_EXT_libglvnd</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_EXT_stereo_tree</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_NV_copy_buffer</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_NV_delay_before_swap</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_NV_robustness_video_memory_purge</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLX_NV_multigpu_context</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p>For a description of these extensions, see the OpenGL extension
|
||||
registry at <a href="http://www.opengl.org/registry/" target=
|
||||
"_top">http://www.opengl.org/registry/</a></p>
|
||||
<p>Some of the above extensions exist as part of core GLX 1.4
|
||||
functionality, however, they are also exported as extensions for
|
||||
backwards compatibility.</p>
|
||||
<p>Unofficial GLX protocol support exists in NVIDIA's GLX client
|
||||
and GLX server implementations for the following OpenGL
|
||||
extensions:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>GL_ARB_geometry_shader4</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GL_ARB_shader_objects</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GL_ARB_texture_buffer_object</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GL_ARB_vertex_buffer_object</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GL_ARB_vertex_shader</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GL_EXT_bindable_uniform</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GL_EXT_compiled_vertex_array</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GL_EXT_geometry_shader4</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GL_EXT_gpu_shader4</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GL_EXT_texture_buffer_object</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GL_NV_geometry_program4</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GL_NV_vertex_program</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GL_NV_parameter_buffer_object</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GL_NV_vertex_program4</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p>Until the GLX protocol for these OpenGL extensions is finalized,
|
||||
using these extensions through GLX indirect rendering will require
|
||||
the AllowUnofficialGLXProtocol X configuration option, and the
|
||||
__GL_ALLOW_UNOFFICIAL_PROTOCOL environment variable in the
|
||||
environment of the client application. Unofficial protocol requires
|
||||
the use of NVIDIA GLX libraries on both the client and the server.
|
||||
Note: GLX protocol is used when an OpenGL application indirect
|
||||
renders (i.e., runs on one computer, but submits protocol requests
|
||||
such that the rendering is performed on another computer). The
|
||||
above OpenGL extensions are fully supported when doing direct
|
||||
rendering.</p>
|
||||
<p>GLX visuals and FBConfigs are only available for X screens with
|
||||
depths 16, 24, or 30.</p>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"displaydevicenames.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"appendices.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"dpi.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Appendix C. Display Device Names </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Appendix E. Dots Per Inch</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,167 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Appendix K. GPU Names</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="appendices.html" title=
|
||||
"Part II. Appendices">
|
||||
<link rel="prev" href="profiles.html" title=
|
||||
"Appendix J. Application Profiles">
|
||||
<link rel="next" href="wayland-issues.html" title=
|
||||
"Appendix L. Wayland Known Issues">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Appendix K. GPU Names</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"profiles.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part II. Appendices</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"wayland-issues.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="appendix" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="gpunames" id=
|
||||
"gpunames"></a>Appendix K. GPU Names</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>Many X configuration options that take a display device name can
|
||||
also be qualified with a GPU. This is done by prepending one of the
|
||||
GPU's names to the display device name. For example, the
|
||||
"MetaModes" X configuration option can be used to enable display
|
||||
devices from multiple GPUs in SLI Mosaic or Base Mosaic
|
||||
configurations:</p>
|
||||
<pre class="screen">
|
||||
Option "MetaModes" "1280x1024 +0+0, 1280x1024 +1280+0"
|
||||
</pre>
|
||||
<p>You can use a display device name qualifier along with a GPU
|
||||
qualifier to configure which display should be picked and from
|
||||
which GPU. E.g.,</p>
|
||||
<pre class="screen">
|
||||
Option "MetaModes" "GPU-1.DFP-0:1280x1024 +0+0, GPU-0.DFP-0:1280x1024 +1280+0"
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>Other X configuration options that support GPU names
|
||||
include:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>ColorRange</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>ColorSpace</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>ConnectedMonitor</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>CustomEDID</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>FlatPanelProperties</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>IgnoreEDIDChecksum</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>ModeValidation</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>nvidiaXineramaInfoOrder</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>UseDisplayDevice</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>UseEdidFreqs</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p>The description of each X configuration option in <a href=
|
||||
"xconfigoptions.html" title=
|
||||
"Appendix B. X Config Options">Appendix B, <i>X
|
||||
Config Options</i></a> provides more detail on the available syntax
|
||||
for each option.</p>
|
||||
<p>To find all available names for your configuration, start the X
|
||||
server with verbose logging enabled (e.g., <strong class=
|
||||
"userinput"><code>startx -- -logverbose 5</code></strong>, or
|
||||
enable the "ModeDebug" X configuration option with <strong class=
|
||||
"userinput"><code>nvidia-xconfig --mode-debug</code></strong> and
|
||||
restart the X server).</p>
|
||||
<p>The X log (normally /var/log/Xorg.0.log) will contain
|
||||
information regarding each GPU. E.g.,</p>
|
||||
<pre class="screen">
|
||||
(II) NVIDIA(0): NVIDIA GPU NVS 510 (GK107) at PCI:15:0:0 (GPU-0)
|
||||
(II) NVIDIA(0): VERBOSE: GPU UUID: GPU-758a4cf7-0761-62c7-9bf7-c7d950b817c6
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>Alternatively, nvidia-xconfig can be used to query the GPU
|
||||
names: <strong class="userinput"><code>nvidia-xconfig
|
||||
--query-gpu-info</code></strong></p>
|
||||
<pre class="screen">
|
||||
GPU #0:
|
||||
Name : NVS 510
|
||||
UUID : GPU-758a4cf7-0761-62c7-9bf7-c7d950b817c6
|
||||
PCI BusID : PCI:3:0:0
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>Each name has different properties that may affect which name is
|
||||
appropriate to use. The possible names are:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>An NV-CONTROL target ID-based name (e.g., "GPU-0"). The NVIDIA X
|
||||
driver will assign a unique ID to each GPU on the entire X server.
|
||||
These IDs are not guaranteed to be persistent from one run of the X
|
||||
server to the next, so is likely not convenient for X configuration
|
||||
file use. It is more frequently used in communication with
|
||||
NV-CONTROL clients such as nvidia-settings.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>An UUID-based name (e.g.,
|
||||
"GPU-758a4cf7-0761-62c7-9bf7-c7d950b817c6"). This name is a SHA-1
|
||||
hash, formatted in canonical UUID 8-4-4-4-12 format. This UUID is
|
||||
unique for each physical GPU, and will be the same regardless of
|
||||
where the GPU is connected.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"profiles.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"appendices.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"wayland-issues.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Appendix J. Application Profiles </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Appendix L. Wayland Known Issues</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,250 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 43. GSP Firmware</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="nvidia-peermem.html" title=
|
||||
"Chapter 42. GPUDirect RDMA Peer Memory Client">
|
||||
<link rel="next" href="kernel_open.html" title=
|
||||
"Chapter 44. Open Linux Kernel Modules">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 43. GSP
|
||||
Firmware</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"nvidia-peermem.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"kernel_open.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="gsp" id=
|
||||
"gsp"></a>Chapter 43. GSP Firmware</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>Some GPUs include a GPU System Processor (GSP) which can be used
|
||||
to offload GPU initialization and management tasks. This processor
|
||||
is driven by the <code class="filename">gsp_*.bin</code> firmware
|
||||
files under <code class=
|
||||
"filename">/lib/firmware/nvidia/535.161.07/</code>. Each GSP
|
||||
firmware file is named after a GPU architecture (for example,
|
||||
<code class="filename">gsp_tu10x.bin</code> is named after Turing)
|
||||
and supports GPUs from one or more architectures. A few select
|
||||
products currently use GSP by default, and more products will take
|
||||
advantage of GSP in future driver releases.</p>
|
||||
<p>Offloading tasks which were traditionally performed by the
|
||||
driver on the CPU can improve performance due to lower latency
|
||||
access to GPU hardware internals.</p>
|
||||
<h3>Query Mode</h3>
|
||||
<p>The nvidia-smi utility can be used to query the current use of
|
||||
GSP firmware. It will display a valid version if GSP firmware is
|
||||
enabled, or “<span class="quote">N/A</span>” if
|
||||
disabled:</p>
|
||||
<pre class="screen">
|
||||
$ nvidia-smi -q
|
||||
...
|
||||
GSP Firmware Version : 535.161.07
|
||||
...
|
||||
</pre>
|
||||
<p>This information is also present in the per-GPU information file
|
||||
in the <code class="filename">/proc</code> file system.</p>
|
||||
<pre class="screen">
|
||||
$ cat /proc/driver/nvidia/gpus/domain:bus:device.function/information
|
||||
...
|
||||
GSP Firmware: 535.161.07
|
||||
</pre>
|
||||
<p></p>
|
||||
<h3>Disabling GSP Mode</h3>
|
||||
<p>The driver can be forced to disable use of GSP firmware by
|
||||
setting the kernel module parameter NVreg_EnableGpuFirmware=0.</p>
|
||||
<h3>Enabling GSP Mode</h3>
|
||||
<p>Turing and later GPUs are capable of using the GSP firmware by
|
||||
setting the kernel module parameter NVreg_EnableGpuFirmware=1.
|
||||
However, note feature and GPU support limitations below.</p>
|
||||
<h3>Supported Features</h3>
|
||||
<p>However, in the current release, some display and graphics
|
||||
features (notably: SLI, G-Sync on notebooks, preserving video
|
||||
memory across power management events with
|
||||
NVreg_PreserveVideoMemoryAllocations set) and NVIDIA virtual GPU
|
||||
(vGPU), are not yet supported. These features will be added in
|
||||
upcoming driver releases.</p>
|
||||
<h3>Supported GPUs</h3>
|
||||
<p>The following GPUs default to using the GSP firmware:</p>
|
||||
<div class="informaltable">
|
||||
<table summary="(no summary available)" border="1">
|
||||
<colgroup>
|
||||
<col>
|
||||
<col></colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>NVIDIA GPU product</th>
|
||||
<th>Device PCI ID *</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Tesla T10</td>
|
||||
<td>1E37 10DE 1370</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>NVIDIA T4G</td>
|
||||
<td>1EB4 10DE 157D</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Tesla T4</td>
|
||||
<td>1EB8</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>NVIDIA T4 32GB</td>
|
||||
<td>1EB9</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>NVIDIA A100-PG509-200</td>
|
||||
<td>20B0 10DE 1450</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>NVIDIA A100-SXM4-40GB</td>
|
||||
<td>20B0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>NVIDIA A100-PCIE-40GB</td>
|
||||
<td>20B1 10DE 145F</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>NVIDIA A100-SXM4-80GB</td>
|
||||
<td>20B2 10DE 1463</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>NVIDIA A100-SXM4-80GB</td>
|
||||
<td>20B2 10DE 147F</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>NVIDIA A100-SXM4-80GB</td>
|
||||
<td>20B2 10DE 1484</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>NVIDIA PG506-242</td>
|
||||
<td>20B3 10DE 14A7</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>NVIDIA PG506-243</td>
|
||||
<td>20B3 10DE 14A8</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>NVIDIA A100-PCIE-80GB</td>
|
||||
<td>20B5 10DE 1533</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>NVIDIA PG506-230</td>
|
||||
<td>20B6 10DE 1491</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>NVIDIA PG506-232</td>
|
||||
<td>20B6 10DE 1492</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>NVIDIA A30</td>
|
||||
<td>20B7 10DE 1532</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>NVIDIA A100-PG506-207</td>
|
||||
<td>20F0 10DE 1583</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>NVIDIA A100-PCIE-40GB</td>
|
||||
<td>20F1 10DE 145F</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>NVIDIA A100-PG506-217</td>
|
||||
<td>20F2 10DE 1584</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>NVIDIA A40</td>
|
||||
<td>2235 10DE 145A</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>NVIDIA A10</td>
|
||||
<td>2236</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>NVIDIA A10G</td>
|
||||
<td>2237</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>NVIDIA A16</td>
|
||||
<td>25B6 10DE 14A9</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>NVIDIA A2</td>
|
||||
<td>25B6 10DE 157E</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>NVIDIA A800-80</td>
|
||||
<td>20F5</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>NVIDIA A800-40</td>
|
||||
<td>20F6</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>NVIDIA L40</td>
|
||||
<td>26B5</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>NVIDIA L40G</td>
|
||||
<td>26B8</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>NVIDIA L4</td>
|
||||
<td>27B8</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<p>* If three IDs are listed, the first is the PCI Device ID, the
|
||||
second is the PCI Subsystem Vendor ID, and the third is the PCI
|
||||
Subsystem Device ID.</p>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"nvidia-peermem.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"kernel_open.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 42. GPUDirect RDMA Peer Memory Client </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 44. Open Linux Kernel Modules</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,91 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Appendix F. i2c Bus Support</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="appendices.html" title=
|
||||
"Part II. Appendices">
|
||||
<link rel="prev" href="dpi.html" title=
|
||||
"Appendix E. Dots Per Inch">
|
||||
<link rel="next" href="vdpausupport.html" title=
|
||||
"Appendix G. VDPAU Support">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Appendix F. i2c Bus
|
||||
Support</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"dpi.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part II. Appendices</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"vdpausupport.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="appendix" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="i2c" id=
|
||||
"i2c"></a>Appendix F. i2c Bus Support</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>The NVIDIA Linux kernel module now includes i2c (also called
|
||||
I-squared-c, Inter-IC Communications, or IIC) functionality that
|
||||
allows the NVIDIA Linux kernel module to export i2c ports found on
|
||||
board NVIDIA cards to the Linux kernel. This allows i2c devices
|
||||
on-board the NVIDIA graphics card, as well as devices connected to
|
||||
the VGA and/or DVI ports, to be accessed from kernel modules or
|
||||
userspace programs in a manner consistent with other i2c ports
|
||||
exported by the Linux kernel through the i2c framework.</p>
|
||||
<p>You must have i2c support compiled into the kernel, or as a
|
||||
module, and X must be running. The Linux kernel documentation
|
||||
covers the kernel and userspace /dev APIs, which you may wish to
|
||||
use to access NVIDIA i2c ports.</p>
|
||||
<p>For further information regarding the Linux kernel's i2c
|
||||
framework, refer to the documentation for your kernel, located at
|
||||
.../Documentation/i2c/ within the kernel source tree.</p>
|
||||
<p>The following functionality is currently supported:</p>
|
||||
<pre class="screen">
|
||||
I2C_FUNC_I2C
|
||||
I2C_FUNC_SMBUS_QUICK
|
||||
I2C_FUNC_SMBUS_BYTE
|
||||
I2C_FUNC_SMBUS_BYTE_DATA
|
||||
I2C_FUNC_SMBUS_WORD_DATA
|
||||
</pre>
|
||||
<p></p>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"dpi.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"appendices.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"vdpausupport.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Appendix E. Dots Per Inch </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Appendix G. VDPAU Support</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,244 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>NVIDIA Accelerated Linux Graphics Driver README and
|
||||
Installation Guide</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="next" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">NVIDIA Accelerated Linux Graphics
|
||||
Driver README and Installation Guide</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"> </td>
|
||||
<th width="60%" align="center"> </th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"installationandconfiguration.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="book" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h1 class="title"><a name="README" id="README"></a>NVIDIA
|
||||
Accelerated Linux Graphics Driver README and Installation
|
||||
Guide</h1>
|
||||
</div>
|
||||
<div>
|
||||
<div class="author">
|
||||
<h3 class="author"><span class="firstname">NVIDIA</span>
|
||||
<span class="surname">Corporation</span></h3>
|
||||
</div>
|
||||
</div>
|
||||
<div>
|
||||
<p class="copyright">Copyright © 2006 - 2023 NVIDIA
|
||||
Corporation</p>
|
||||
</div>
|
||||
<div>
|
||||
<div class="legalnotice"><a name="NVIDIALegal" id=
|
||||
"NVIDIALegal"></a>
|
||||
<p>ALL NVIDIA DESIGN SPECIFICATIONS, REFERENCE BOARDS, FILES,
|
||||
DRAWINGS, DIAGNOSTICS, LISTS, AND OTHER DOCUMENTS (TOGETHER AND
|
||||
SEPARATELY, "MATERIALS") ARE BEING PROVIDED "AS IS." NVIDIA MAKES
|
||||
NO WARRANTIES, EXPRESSED, IMPLIED, STATUTORY, OR OTHERWISE WITH
|
||||
RESPECT TO THE MATERIALS, AND EXPRESSLY DISCLAIMS ALL IMPLIED
|
||||
WARRANTIES OF NONINFRINGEMENT, MERCHANTABILITY, AND FITNESS FOR A
|
||||
PARTICULAR PURPOSE. Information furnished is believed to be
|
||||
accurate and reliable. However, NVIDIA Corporation assumes no
|
||||
responsibility for the consequences of use of such information or
|
||||
for any infringement of patents or other rights of third parties
|
||||
that may result from its use. No license is granted by implication
|
||||
or otherwise under any patent or patent rights of NVIDIA
|
||||
Corporation. Specifications mentioned in this publication are
|
||||
subject to change without notice. This publication supersedes and
|
||||
replaces all information previously supplied. NVIDIA Corporation
|
||||
products are not authorized for use as critical components in life
|
||||
support devices or systems without express written approval of
|
||||
NVIDIA Corporation.</p>
|
||||
<p>NVIDIA, the NVIDIA logo, NVIDIA nForce, GeForce, NVIDIA Quadro,
|
||||
Vanta, TNT2, TNT, RIVA, RIVA TNT, Tegra, and TwinView are
|
||||
registered trademarks or trademarks of NVIDIA Corporation in the
|
||||
United States and/or other countries.</p>
|
||||
<p>Linux is a registered trademark of Linus Torvalds. Fedora and
|
||||
Red Hat are trademarks of Red Hat, Inc. SuSE is a registered
|
||||
trademark of SuSE AG. Mandriva is a registered trademark of
|
||||
Mandriva S.A. Intel is a registered trademark of Intel Corporation.
|
||||
OpenGL is a registered trademark of Silicon Graphics Inc. PCI
|
||||
Express is a registered trademark and/or service mark of PCI-SIG.
|
||||
Windows is a registered trademark of Microsoft Corporation in the
|
||||
United States and other countries. Other company and product names
|
||||
may be trademarks or registered trademarks of the respective owners
|
||||
with which they are associated.</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<hr></div>
|
||||
<div class="toc">
|
||||
<p><b>Table of Contents</b></p>
|
||||
<dl>
|
||||
<dt><span class="part"><a href=
|
||||
"installationandconfiguration.html">I. Installation and
|
||||
Configuration Instructions</a></span></dt>
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="chapter"><a href="introduction.html">1.
|
||||
Introduction</a></span></dt>
|
||||
<dt><span class="chapter"><a href="minimumrequirements.html">2.
|
||||
Minimum Requirements</a></span></dt>
|
||||
<dt><span class="chapter"><a href="selectdriver.html">3. Selecting
|
||||
and Downloading the NVIDIA Packages for Your System</a></span></dt>
|
||||
<dt><span class="chapter"><a href="installdriver.html">4.
|
||||
Installing the NVIDIA Driver</a></span></dt>
|
||||
<dt><span class="chapter"><a href="installedcomponents.html">5.
|
||||
Listing of Installed Components</a></span></dt>
|
||||
<dt><span class="chapter"><a href="editxconfig.html">6. Configuring
|
||||
X for the NVIDIA Driver</a></span></dt>
|
||||
<dt><span class="chapter"><a href="faq.html">7. Frequently Asked
|
||||
Questions</a></span></dt>
|
||||
<dt><span class="chapter"><a href="commonproblems.html">8. Common
|
||||
Problems</a></span></dt>
|
||||
<dt><span class="chapter"><a href="knownissues.html">9. Known
|
||||
Issues</a></span></dt>
|
||||
<dt><span class="chapter"><a href="dma_issues.html">10. Allocating
|
||||
DMA Buffers on 64-bit Platforms</a></span></dt>
|
||||
<dt><span class="chapter"><a href="openglenvvariables.html">11.
|
||||
Specifying OpenGL Environment Variable Settings</a></span></dt>
|
||||
<dt><span class="chapter"><a href="configtwinview.html">12.
|
||||
Configuring Multiple Display Devices on One X
|
||||
Screen</a></span></dt>
|
||||
<dt><span class="chapter"><a href="xineramaglx.html">13.
|
||||
Configuring GLX in Xinerama</a></span></dt>
|
||||
<dt><span class="chapter"><a href="configmultxscreens.html">14.
|
||||
Configuring Multiple X Screens on One Card</a></span></dt>
|
||||
<dt><span class="chapter"><a href="xrandrextension.html">15.
|
||||
Support for the X Resize and Rotate Extension</a></span></dt>
|
||||
<dt><span class="chapter"><a href="configlaptop.html">16.
|
||||
Configuring a Notebook</a></span></dt>
|
||||
<dt><span class="chapter"><a href="optimus.html">17. Using the
|
||||
NVIDIA Driver with Optimus Laptops</a></span></dt>
|
||||
<dt><span class="chapter"><a href="programmingmodes.html">18.
|
||||
Programming Modes</a></span></dt>
|
||||
<dt><span class="chapter"><a href="flippingubb.html">19.
|
||||
Configuring Flipping and UBB</a></span></dt>
|
||||
<dt><span class="chapter"><a href="procinterface.html">20. Using
|
||||
the <code class="computeroutput">/proc</code> File System
|
||||
Interface</a></span></dt>
|
||||
<dt><span class="chapter"><a href="powermanagement.html">21.
|
||||
Configuring Power Management Support</a></span></dt>
|
||||
<dt><span class="chapter"><a href="dynamicpowermanagement.html">22.
|
||||
PCI-Express Runtime D3 (RTD3) Power Management</a></span></dt>
|
||||
<dt><span class="chapter"><a href="dynamicboost.html">23. Dynamic
|
||||
Boost on Linux</a></span></dt>
|
||||
<dt><span class="chapter"><a href="xcompositeextension.html">24.
|
||||
Using the X Composite Extension</a></span></dt>
|
||||
<dt><span class="chapter"><a href="nvidiasettings.html">25. Using
|
||||
the nvidia-settings Utility</a></span></dt>
|
||||
<dt><span class="chapter"><a href="retpoline.html">26. NVIDIA
|
||||
Spectre V2 Mitigation</a></span></dt>
|
||||
<dt><span class="chapter"><a href="nvidia-smi.html">27. Using the
|
||||
nvidia-smi Utility</a></span></dt>
|
||||
<dt><span class="chapter"><a href="nvidia-ml.html">28. The NVIDIA
|
||||
Management Library</a></span></dt>
|
||||
<dt><span class="chapter"><a href="nvidia-debugdump.html">29. Using
|
||||
the nvidia-debugdump Utility</a></span></dt>
|
||||
<dt><span class="chapter"><a href="nvidia-persistenced.html">30.
|
||||
Using the nvidia-persistenced Utility</a></span></dt>
|
||||
<dt><span class="chapter"><a href="sli.html">31. Configuring SLI
|
||||
and Multi-GPU Mosaic</a></span></dt>
|
||||
<dt><span class="chapter"><a href="framelock.html">32. Configuring
|
||||
Frame Lock and Genlock</a></span></dt>
|
||||
<dt><span class="chapter"><a href="depth30.html">33. Configuring
|
||||
Depth 30 Displays</a></span></dt>
|
||||
<dt><span class="chapter"><a href="randr14.html">34. Offloading
|
||||
Graphics Display with RandR 1.4</a></span></dt>
|
||||
<dt><span class="chapter"><a href="primerenderoffload.html">35.
|
||||
PRIME Render Offload</a></span></dt>
|
||||
<dt><span class="chapter"><a href="kms.html">36. Direct Rendering
|
||||
Manager Kernel Modesetting (DRM KMS)</a></span></dt>
|
||||
<dt><span class="chapter"><a href="egpu.html">37. Configuring
|
||||
External and Removable GPUs</a></span></dt>
|
||||
<dt><span class="chapter"><a href="ngx.html">38.
|
||||
NGX</a></span></dt>
|
||||
<dt><span class="chapter"><a href="xwayland.html">39. OpenGL and
|
||||
Vulkan on Xwayland</a></span></dt>
|
||||
<dt><span class="chapter"><a href="gbm.html">40. GBM and GBM-based
|
||||
Wayland Compositors</a></span></dt>
|
||||
<dt><span class="chapter"><a href="addressingcapabilities.html">41.
|
||||
Addressing Capabilities</a></span></dt>
|
||||
<dt><span class="chapter"><a href="nvidia-peermem.html">42.
|
||||
GPUDirect RDMA Peer Memory Client</a></span></dt>
|
||||
<dt><span class="chapter"><a href="gsp.html">43. GSP
|
||||
Firmware</a></span></dt>
|
||||
<dt><span class="chapter"><a href="kernel_open.html">44. Open Linux
|
||||
Kernel Modules</a></span></dt>
|
||||
<dt><span class="chapter"><a href="addtlresources.html">45. NVIDIA
|
||||
Contact Info and Additional Resources</a></span></dt>
|
||||
<dt><span class="chapter"><a href="acknowledgements.html">46.
|
||||
Acknowledgements</a></span></dt>
|
||||
</dl>
|
||||
</dd>
|
||||
<dt><span class="part"><a href="appendices.html">II.
|
||||
Appendices</a></span></dt>
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="appendix"><a href="supportedchips.html">A.
|
||||
Supported NVIDIA GPU Products</a></span></dt>
|
||||
<dt><span class="appendix"><a href="xconfigoptions.html">B. X
|
||||
Config Options</a></span></dt>
|
||||
<dt><span class="appendix"><a href="displaydevicenames.html">C.
|
||||
Display Device Names</a></span></dt>
|
||||
<dt><span class="appendix"><a href="glxsupport.html">D. GLX
|
||||
Support</a></span></dt>
|
||||
<dt><span class="appendix"><a href="dpi.html">E. Dots Per
|
||||
Inch</a></span></dt>
|
||||
<dt><span class="appendix"><a href="i2c.html">F. i2c Bus
|
||||
Support</a></span></dt>
|
||||
<dt><span class="appendix"><a href="vdpausupport.html">G. VDPAU
|
||||
Support</a></span></dt>
|
||||
<dt><span class="appendix"><a href="audiosupport.html">H. Audio
|
||||
Support</a></span></dt>
|
||||
<dt><span class="appendix"><a href="newusertips.html">I. Tips for
|
||||
New Linux Users</a></span></dt>
|
||||
<dt><span class="appendix"><a href="profiles.html">J. Application
|
||||
Profiles</a></span></dt>
|
||||
<dt><span class="appendix"><a href="gpunames.html">K. GPU
|
||||
Names</a></span></dt>
|
||||
<dt><span class="appendix"><a href="wayland-issues.html">L. Wayland
|
||||
Known Issues</a></span></dt>
|
||||
</dl>
|
||||
</dd>
|
||||
</dl>
|
||||
</div>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"> </td>
|
||||
<td width="20%" align="center"> </td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"installationandconfiguration.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top"> </td>
|
||||
<td width="20%" align="center"> </td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Part I. Installation and Configuration
|
||||
Instructions</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,330 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Part I. Installation and Configuration
|
||||
Instructions</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="prev" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="next" href="introduction.html" title=
|
||||
"Chapter 1. Introduction">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"index.html">Prev</a> </td>
|
||||
<th width="60%" align="center"> </th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"introduction.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="part" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h1 class="title"><a name="installationandconfiguration" id=
|
||||
"installationandconfiguration"></a>Installation and Configuration
|
||||
Instructions</h1>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="toc">
|
||||
<p><b>Table of Contents</b></p>
|
||||
<dl>
|
||||
<dt><span class="chapter"><a href="introduction.html">1.
|
||||
Introduction</a></span></dt>
|
||||
<dt><span class="chapter"><a href="minimumrequirements.html">2.
|
||||
Minimum Requirements</a></span></dt>
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="section"><a href=
|
||||
"minimumrequirements.html#MinimumSoftware2486a">Minimum Software
|
||||
Requirements</a></span></dt>
|
||||
</dl>
|
||||
</dd>
|
||||
<dt><span class="chapter"><a href="selectdriver.html">3. Selecting
|
||||
and Downloading the NVIDIA Packages for Your System</a></span></dt>
|
||||
<dt><span class="chapter"><a href="installdriver.html">4.
|
||||
Installing the NVIDIA Driver</a></span></dt>
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="section"><a href=
|
||||
"installdriver.html#BeforeYouBegin89f39">Before you
|
||||
Begin</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"installdriver.html#StartingTheInst6624e">Starting the
|
||||
Installer</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"installdriver.html#InstallingTheKe997db">Installing the Kernel
|
||||
Interface</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"installdriver.html#RegisteringTheNda02d">Registering the NVIDIA
|
||||
Kernel Module with DKMS</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"installdriver.html#modulesigning">Signing the NVIDIA Kernel
|
||||
Module</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"installdriver.html#AddingPrecompil0c783">Adding Precompiled Kernel
|
||||
Interfaces to the Installer Package</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"installdriver.html#OtherFeaturesOfd7638">Other Features of the
|
||||
Installer</a></span></dt>
|
||||
</dl>
|
||||
</dd>
|
||||
<dt><span class="chapter"><a href="installedcomponents.html">5.
|
||||
Listing of Installed Components</a></span></dt>
|
||||
<dt><span class="chapter"><a href="editxconfig.html">6. Configuring
|
||||
X for the NVIDIA Driver</a></span></dt>
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="section"><a href=
|
||||
"editxconfig.html#UsingNvidiaxcon2beec">Using nvidia-xconfig to
|
||||
configure the X server</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"editxconfig.html#ManuallyEditing1ae61">Manually Editing the
|
||||
Configuration File</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"editxconfig.html#RestoringTheXCof7145">Restoring the X
|
||||
Configuration after Uninstalling the Driver</a></span></dt>
|
||||
</dl>
|
||||
</dd>
|
||||
<dt><span class="chapter"><a href="faq.html">7. Frequently Asked
|
||||
Questions</a></span></dt>
|
||||
<dt><span class="chapter"><a href="commonproblems.html">8. Common
|
||||
Problems</a></span></dt>
|
||||
<dt><span class="chapter"><a href="knownissues.html">9. Known
|
||||
Issues</a></span></dt>
|
||||
<dt><span class="chapter"><a href="dma_issues.html">10. Allocating
|
||||
DMA Buffers on 64-bit Platforms</a></span></dt>
|
||||
<dt><span class="chapter"><a href="openglenvvariables.html">11.
|
||||
Specifying OpenGL Environment Variable Settings</a></span></dt>
|
||||
<dt><span class="chapter"><a href="configtwinview.html">12.
|
||||
Configuring Multiple Display Devices on One X
|
||||
Screen</a></span></dt>
|
||||
<dt><span class="chapter"><a href="xineramaglx.html">13.
|
||||
Configuring GLX in Xinerama</a></span></dt>
|
||||
<dt><span class="chapter"><a href="configmultxscreens.html">14.
|
||||
Configuring Multiple X Screens on One Card</a></span></dt>
|
||||
<dt><span class="chapter"><a href="xrandrextension.html">15.
|
||||
Support for the X Resize and Rotate Extension</a></span></dt>
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="section"><a href=
|
||||
"xrandrextension.html#randr-support">RandR Support</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"xrandrextension.html#randr-1.1-rotation-behavior">RandR 1.1
|
||||
Rotation Behavior</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"xrandrextension.html#randr-properties">Output
|
||||
Properties</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"xrandrextension.html#randr-dp12">DisplayPort 1.2</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"xrandrextension.html#randr-monitor-options">Monitor Configuration
|
||||
Options</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"xrandrextension.html#randr-known-issues">Known
|
||||
Issues</a></span></dt>
|
||||
</dl>
|
||||
</dd>
|
||||
<dt><span class="chapter"><a href="configlaptop.html">16.
|
||||
Configuring a Notebook</a></span></dt>
|
||||
<dt><span class="chapter"><a href="optimus.html">17. Using the
|
||||
NVIDIA Driver with Optimus Laptops</a></span></dt>
|
||||
<dt><span class="chapter"><a href="programmingmodes.html">18.
|
||||
Programming Modes</a></span></dt>
|
||||
<dt><span class="chapter"><a href="flippingubb.html">19.
|
||||
Configuring Flipping and UBB</a></span></dt>
|
||||
<dt><span class="chapter"><a href="procinterface.html">20. Using
|
||||
the <code class="computeroutput">/proc</code> File System
|
||||
Interface</a></span></dt>
|
||||
<dt><span class="chapter"><a href="powermanagement.html">21.
|
||||
Configuring Power Management Support</a></span></dt>
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="section"><a href=
|
||||
"powermanagement.html#Backgroundc73a7">Background</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"powermanagement.html#Overview21f77">Overview</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"powermanagement.html#PreserveAllVide719f0">Preserve all video
|
||||
memory allocations</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"powermanagement.html#SystemdConfigur74e29"><span><strong class=
|
||||
"command">systemd</strong></span> Configuration</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"powermanagement.html#ExercisingPower89cc2">Exercising power
|
||||
management with <span><strong class=
|
||||
"command">systemd</strong></span></a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"powermanagement.html#KnownIssuesAndWf438e">Known Issues and
|
||||
Workarounds</a></span></dt>
|
||||
</dl>
|
||||
</dd>
|
||||
<dt><span class="chapter"><a href="dynamicpowermanagement.html">22.
|
||||
PCI-Express Runtime D3 (RTD3) Power Management</a></span></dt>
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="section"><a href=
|
||||
"dynamicpowermanagement.html#Introduction70e5e">Introduction</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"dynamicpowermanagement.html#SupportedConfigaffb4">Supported
|
||||
Configurations</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"dynamicpowermanagement.html#SystemSettings1be5e">System
|
||||
Settings</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"dynamicpowermanagement.html#DriverSettingsfe624">Driver
|
||||
Settings</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"dynamicpowermanagement.html#VidMemThreshold">Video Memory
|
||||
Utilization Threshold</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"dynamicpowermanagement.html#ProcfsInterface01474">Procfs Interface
|
||||
For Runtime D3</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"dynamicpowermanagement.html#KnownIssuesAndW6426e">Known Issues And
|
||||
Workarounds</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"dynamicpowermanagement.html#AutomatedSetup803b0">Automated
|
||||
Setup</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"dynamicpowermanagement.html#ReportingIssues42249">Reporting
|
||||
Issues</a></span></dt>
|
||||
</dl>
|
||||
</dd>
|
||||
<dt><span class="chapter"><a href="dynamicboost.html">23. Dynamic
|
||||
Boost on Linux</a></span></dt>
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="section"><a href=
|
||||
"dynamicboost.html#Introductiond7a86">Introduction</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"dynamicboost.html#HardwareRequire1d82a">Hardware
|
||||
Requirements</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"dynamicboost.html#SoftwareRequirea030b">Software
|
||||
Requirements</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"dynamicboost.html#ConfigurationSt5d898">Configuration
|
||||
Steps</a></span></dt>
|
||||
</dl>
|
||||
</dd>
|
||||
<dt><span class="chapter"><a href="xcompositeextension.html">24.
|
||||
Using the X Composite Extension</a></span></dt>
|
||||
<dt><span class="chapter"><a href="nvidiasettings.html">25. Using
|
||||
the nvidia-settings Utility</a></span></dt>
|
||||
<dt><span class="chapter"><a href="retpoline.html">26. NVIDIA
|
||||
Spectre V2 Mitigation</a></span></dt>
|
||||
<dt><span class="chapter"><a href="nvidia-smi.html">27. Using the
|
||||
nvidia-smi Utility</a></span></dt>
|
||||
<dt><span class="chapter"><a href="nvidia-ml.html">28. The NVIDIA
|
||||
Management Library</a></span></dt>
|
||||
<dt><span class="chapter"><a href="nvidia-debugdump.html">29. Using
|
||||
the nvidia-debugdump Utility</a></span></dt>
|
||||
<dt><span class="chapter"><a href="nvidia-persistenced.html">30.
|
||||
Using the nvidia-persistenced Utility</a></span></dt>
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="section"><a href=
|
||||
"nvidia-persistenced.html#Background46f43">Background</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"nvidia-persistenced.html#Usage01b5d">Usage</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"nvidia-persistenced.html#Troubleshootingc8305">Troubleshooting</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"nvidia-persistenced.html#NotesForPackage3f7a9">Notes for Package
|
||||
Maintainers</a></span></dt>
|
||||
</dl>
|
||||
</dd>
|
||||
<dt><span class="chapter"><a href="sli.html">31. Configuring SLI
|
||||
and Multi-GPU Mosaic</a></span></dt>
|
||||
<dt><span class="chapter"><a href="framelock.html">32. Configuring
|
||||
Frame Lock and Genlock</a></span></dt>
|
||||
<dt><span class="chapter"><a href="depth30.html">33. Configuring
|
||||
Depth 30 Displays</a></span></dt>
|
||||
<dt><span class="chapter"><a href="randr14.html">34. Offloading
|
||||
Graphics Display with RandR 1.4</a></span></dt>
|
||||
<dt><span class="chapter"><a href="primerenderoffload.html">35.
|
||||
PRIME Render Offload</a></span></dt>
|
||||
<dt><span class="chapter"><a href="kms.html">36. Direct Rendering
|
||||
Manager Kernel Modesetting (DRM KMS)</a></span></dt>
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="section"><a href=
|
||||
"kms.html#drm-kms-known-issues">Known Issues</a></span></dt>
|
||||
</dl>
|
||||
</dd>
|
||||
<dt><span class="chapter"><a href="egpu.html">37. Configuring
|
||||
External and Removable GPUs</a></span></dt>
|
||||
<dt><span class="chapter"><a href="ngx.html">38.
|
||||
NGX</a></span></dt>
|
||||
<dt><span class="chapter"><a href="xwayland.html">39. OpenGL and
|
||||
Vulkan on Xwayland</a></span></dt>
|
||||
<dt><span class="chapter"><a href="gbm.html">40. GBM and GBM-based
|
||||
Wayland Compositors</a></span></dt>
|
||||
<dt><span class="chapter"><a href="addressingcapabilities.html">41.
|
||||
Addressing Capabilities</a></span></dt>
|
||||
<dt><span class="chapter"><a href="nvidia-peermem.html">42.
|
||||
GPUDirect RDMA Peer Memory Client</a></span></dt>
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="section"><a href=
|
||||
"nvidia-peermem.html#Background03f8e">Background</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"nvidia-peermem.html#Usaged9d8e">Usage</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"nvidia-peermem.html#ModuleParameterb2f08">Module
|
||||
Parameters</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"nvidia-peermem.html#KnownIssues57784">Known Issues</a></span></dt>
|
||||
</dl>
|
||||
</dd>
|
||||
<dt><span class="chapter"><a href="gsp.html">43. GSP
|
||||
Firmware</a></span></dt>
|
||||
<dt><span class="chapter"><a href="kernel_open.html">44. Open Linux
|
||||
Kernel Modules</a></span></dt>
|
||||
<dt><span class="chapter"><a href="addtlresources.html">45. NVIDIA
|
||||
Contact Info and Additional Resources</a></span></dt>
|
||||
<dt><span class="chapter"><a href="acknowledgements.html">46.
|
||||
Acknowledgements</a></span></dt>
|
||||
</dl>
|
||||
</div>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"index.html">Prev</a> </td>
|
||||
<td width="20%" align="center"> </td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"introduction.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">NVIDIA Accelerated Linux
|
||||
Graphics Driver README and Installation Guide </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 1. Introduction</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,591 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 4. Installing the NVIDIA Driver</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="selectdriver.html" title=
|
||||
"Chapter 3. Selecting and Downloading the NVIDIA Packages for Your System">
|
||||
<link rel="next" href="installedcomponents.html" title=
|
||||
"Chapter 5. Listing of Installed Components">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 4. Installing the
|
||||
NVIDIA Driver</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"selectdriver.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"installedcomponents.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="installdriver" id=
|
||||
"installdriver"></a>Chapter 4. Installing the NVIDIA
|
||||
Driver</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="toc">
|
||||
<p><b>Table of Contents</b></p>
|
||||
<dl>
|
||||
<dt><span class="section"><a href=
|
||||
"installdriver.html#BeforeYouBegin89f39">Before you
|
||||
Begin</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"installdriver.html#StartingTheInst6624e">Starting the
|
||||
Installer</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"installdriver.html#InstallingTheKe997db">Installing the Kernel
|
||||
Interface</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"installdriver.html#RegisteringTheNda02d">Registering the NVIDIA
|
||||
Kernel Module with DKMS</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"installdriver.html#modulesigning">Signing the NVIDIA Kernel
|
||||
Module</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"installdriver.html#AddingPrecompil0c783">Adding Precompiled Kernel
|
||||
Interfaces to the Installer Package</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"installdriver.html#OtherFeaturesOfd7638">Other Features of the
|
||||
Installer</a></span></dt>
|
||||
</dl>
|
||||
</div>
|
||||
<p>This chapter provides instructions for installing the NVIDIA
|
||||
driver. Note that after installation, but prior to using the
|
||||
driver, you must complete the steps described in <a href=
|
||||
"editxconfig.html" title=
|
||||
"Chapter 6. Configuring X for the NVIDIA Driver">Chapter 6,
|
||||
<i>Configuring X for the NVIDIA Driver</i></a>. Additional details
|
||||
that may be helpful for the new Linux user are provided in <a href=
|
||||
"newusertips.html" title=
|
||||
"Appendix I. Tips for New Linux Users">Appendix I,
|
||||
<i>Tips for New Linux Users</i></a>.</p>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name="BeforeYouBegin89f39"
|
||||
id="BeforeYouBegin89f39"></a>Before you Begin</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>Before you begin the installation, exit the X server and
|
||||
terminate all OpenGL applications (note that it is possible that
|
||||
some OpenGL applications persist even after the X server has
|
||||
stopped). You should also set the default run level on your system
|
||||
such that it will boot to a VGA console, and not directly to X.
|
||||
Doing so will make it easier to recover if there is a problem
|
||||
during the installation process. See <a href="newusertips.html"
|
||||
title=
|
||||
"Appendix I. Tips for New Linux Users">Appendix I,
|
||||
<i>Tips for New Linux Users</i></a> for details.</p>
|
||||
<p>If you're installing on a system that is set up to use the
|
||||
Nouveau driver, then you should first disable it before attempting
|
||||
to install the NVIDIA driver. See <a href=
|
||||
"commonproblems.html#nouveau" title=
|
||||
"Interaction with the Nouveau Driver">Q & A 8.1,
|
||||
“Interaction with the Nouveau Driver”</a> for
|
||||
details.</p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"StartingTheInst6624e" id="StartingTheInst6624e"></a>Starting the
|
||||
Installer</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>After you have downloaded the file <code class=
|
||||
"filename">NVIDIA-Linux-x86_64-535.161.07.run</code>, change to
|
||||
the directory containing the downloaded file, and as the
|
||||
<code class="systemitem">root</code> user run the executable:</p>
|
||||
<pre class="screen">
|
||||
# cd yourdirectory
|
||||
# sh NVIDIA-Linux-x86_64-535.161.07.run
|
||||
</pre>
|
||||
<p>The <code class="filename">.run</code> file is a self-extracting
|
||||
archive. When executed, it extracts the contents of the archive and
|
||||
runs the contained <code class="filename">nvidia-installer</code>
|
||||
utility, which provides an interactive interface to walk you
|
||||
through the installation.</p>
|
||||
<p><code class="filename">nvidia-installer</code> will also install
|
||||
itself to <code class="filename">/usr/bin/nvidia-installer</code>,
|
||||
which may be used at some later time to uninstall drivers,
|
||||
auto-download updated drivers, etc. The use of this utility is
|
||||
detailed later in this chapter.</p>
|
||||
<p>You may also supply command line options to the <code class=
|
||||
"filename">.run</code> file. Some of the more common options are
|
||||
listed below.</p>
|
||||
<div class="variablelist">
|
||||
<p class="title"><b>Common <code class="filename">.run</code>
|
||||
Options</b></p>
|
||||
<dl>
|
||||
<dt><span class="term"><code class=
|
||||
"option">--info</code></span></dt>
|
||||
<dd>
|
||||
<p>Print embedded info about the <code class="filename">.run</code>
|
||||
file and exit.</p>
|
||||
</dd>
|
||||
<dt><span class="term"><code class=
|
||||
"option">--check</code></span></dt>
|
||||
<dd>
|
||||
<p>Check integrity of the archive and exit.</p>
|
||||
</dd>
|
||||
<dt><span class="term"><code class=
|
||||
"option">--extract-only</code></span></dt>
|
||||
<dd>
|
||||
<p>Extract the contents of <code class=
|
||||
"filename">./NVIDIA-Linux-x86_64-535.161.07.run</code>, but do not
|
||||
run <code class="filename">nvidia-installer</code>.</p>
|
||||
</dd>
|
||||
<dt><span class="term"><code class=
|
||||
"option">--help</code></span></dt>
|
||||
<dd>
|
||||
<p>Print usage information for the common commandline options and
|
||||
exit.</p>
|
||||
</dd>
|
||||
<dt><span class="term"><code class=
|
||||
"option">--advanced-options</code></span></dt>
|
||||
<dd>
|
||||
<p>Print usage information for common command line options as well
|
||||
as the advanced options, and then exit.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
</div>
|
||||
<p></p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"InstallingTheKe997db" id="InstallingTheKe997db"></a>Installing the
|
||||
Kernel Interface</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>The NVIDIA kernel module has a kernel interface layer that must
|
||||
be compiled specifically for each kernel. NVIDIA distributes the
|
||||
source code to this kernel interface layer.</p>
|
||||
<p>When the installer is run, it will check your system for the
|
||||
required kernel sources and compile the kernel interface. You must
|
||||
have the source code for your kernel installed for compilation to
|
||||
work. On most systems, this means that you will need to locate and
|
||||
install the correct kernel-source, kernel-headers, or kernel-devel
|
||||
package; on some distributions, no additional packages are
|
||||
required.</p>
|
||||
<p>After the correct kernel interface has been compiled, the kernel
|
||||
interface will be linked with the closed-source portion of the
|
||||
NVIDIA kernel module. This requires that you have a linker
|
||||
installed on your system. The linker, usually <code class=
|
||||
"filename">/usr/bin/ld</code>, is part of the binutils package. You
|
||||
must have a linker installed prior to installing the NVIDIA
|
||||
driver.</p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"RegisteringTheNda02d" id="RegisteringTheNda02d"></a>Registering
|
||||
the NVIDIA Kernel Module with DKMS</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>The installer will check for the presence of DKMS on your
|
||||
system. If DKMS is found, you will be given the option of
|
||||
registering the kernel module with DKMS. On most systems with DKMS,
|
||||
DKMS will take care of automatically rebuilding registered kernel
|
||||
modules when installing a different Linux kernel. This is typically
|
||||
done by hooks that Linux distributions set up to be triggered as
|
||||
part of the kernel installation process. If your system is not
|
||||
configured to automatically run DKMS to rebuild kernel modules
|
||||
after installing a different kernel, you may run <strong class=
|
||||
"userinput"><code>dkms autoinstall</code></strong> to trigger the
|
||||
process manually.</p>
|
||||
<p>Note that while DKMS is useful for rebuilding the kernel modules
|
||||
after a minor kernel update, such as typical maintenance and
|
||||
security updates that Linux distributions may publish on a regular
|
||||
basis, a major kernel update may require installing a newer NVIDIA
|
||||
driver, as changes to the kernel APIs may not be compatible with
|
||||
the existing driver version.</p>
|
||||
<p>On systems which require signed kernel modules, newer versions
|
||||
of DKMS may assist you in generating and enrolling a Machine Owner
|
||||
Key (MOK), so that future automated DKMS builds can reuse the
|
||||
already trusted signing keys. This is more convenient than having
|
||||
to create a new signature every time the kernel modules are
|
||||
rebuilt; however, it is slightly less secure, as the keys will be
|
||||
stored at a well-known location in your filesystem.</p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name="modulesigning" id=
|
||||
"modulesigning"></a>Signing the NVIDIA Kernel Module</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>Some kernels may require that kernel modules be
|
||||
cryptographically signed by a key trusted by the kernel in order to
|
||||
be loaded. In particular, many distributions require modules to be
|
||||
signed when loaded into kernels running on UEFI systems with Secure
|
||||
Boot enabled. <code class="filename">nvidia-installer</code>
|
||||
includes support for signing the kernel module before installation,
|
||||
to ensure that it can be loaded on such systems. Note that not all
|
||||
UEFI systems have Secure Boot enabled, and not all kernels running
|
||||
on UEFI Secure Boot systems will require signed kernel modules, so
|
||||
if you are uncertain about whether your system requires signed
|
||||
kernel modules, you may try installing the driver without signing
|
||||
the kernel module, to see if the unsigned kernel module can be
|
||||
loaded.</p>
|
||||
<p>In order to sign the kernel module, you will need a private
|
||||
signing key, and an X.509 certificate for the corresponding public
|
||||
key. The X.509 certificate must be trusted by the kernel before the
|
||||
module can be loaded: we recommend ensuring that the signing key be
|
||||
trusted before beginning the driver installation, so that the newly
|
||||
signed module can be used immediately. If you do not already have a
|
||||
key pair suitable for module signing use, you must generate one.
|
||||
Please consult your distribution's documentation for details on the
|
||||
types of keys suitable for module signing, and how to generate
|
||||
them. <code class="filename">nvidia-installer</code> can generate a
|
||||
key pair for you at install time, but it is preferable to have a
|
||||
key pair already generated and trusted by the kernel before
|
||||
installation begins.</p>
|
||||
<p>Once you have a key pair ready, you can use that key pair in
|
||||
<code class="filename">nvidia-installer</code> by passing the keys
|
||||
to the installer on the command line with the <code class=
|
||||
"option">--module-signing-secret-key</code> and <code class=
|
||||
"option">--module-signing-public-key</code> options. As an example,
|
||||
it is possible to install the driver with a signed kernel module in
|
||||
silent mode (i.e., non-interactively) by running:</p>
|
||||
<pre class="screen">
|
||||
# sh ./NVIDIA-Linux-x86_64-535.161.07.run -s \
|
||||
--module-signing-secret-key=/path/to/signing.key \
|
||||
--module-signing-public-key=/path/to/signing.x509
|
||||
</pre>
|
||||
<p>In the example above, <code class="filename">signing.key</code>
|
||||
and <code class="filename">signing.x509</code> are a private/public
|
||||
key pair, and the public key is already enrolled in one of the
|
||||
kernel's trusted module signing key sources.</p>
|
||||
<p>On UEFI systems with secure boot enabled, nvidia-installer will
|
||||
present a series of interactive prompts to guide users through the
|
||||
module signing process. As an alternative to setting the key paths
|
||||
on the command line, the paths can be provided interactively in
|
||||
response to the prompts. These prompts will also appear when
|
||||
building the NVIDIA kernel module against a kernel which has
|
||||
CONFIG_MODULE_SIG_FORCE enabled in its configuration, or if the
|
||||
installer is run in expert mode.</p>
|
||||
<h3>Key Sources Trusted by the Kernel</h3>
|
||||
<p>In order to load a kernel module into a kernel that requires
|
||||
module signatures, the module must be signed by a key that the
|
||||
kernel trusts. There are several sources that a kernel may draw
|
||||
upon to build its pool of trusted keys. If you have generated a key
|
||||
pair, but it is not yet trusted by your kernel, you must add a
|
||||
certificate for your public key to a trusted key source before it
|
||||
can be used to verify signatures of signed kernel modules. These
|
||||
trusted sources include:</p>
|
||||
<div class="variablelist">
|
||||
<dl>
|
||||
<dt><span class="term">Certificates embedded into the kernel
|
||||
image</span></dt>
|
||||
<dd>
|
||||
<p>On kernels with <code class="option">CONFIG_MODULE_SIG</code>
|
||||
set, a certificate for the public key used to sign the in-tree
|
||||
kernel modules is embedded, along with any additional module
|
||||
signing certificates provided at build time, into the kernel image.
|
||||
Modules signed by the private keys that correspond to the embedded
|
||||
public key certificates will be trusted by the kernel.</p>
|
||||
<p>Since the keys are embedded at build time, the only way to add a
|
||||
new public key is to build a new kernel. On UEFI systems with
|
||||
Secure Boot enabled, the kernel image will, in turn, need to be
|
||||
signed by a key that is trusted by the bootloader, so users
|
||||
building their own kernels with custom embedded keys should have a
|
||||
plan for making sure that the bootloader will load the new
|
||||
kernel.</p>
|
||||
</dd>
|
||||
<dt><span class="term">Certificates stored in the UEFI firmware
|
||||
database</span></dt>
|
||||
<dd>
|
||||
<p>On kernels with <code class=
|
||||
"option">CONFIG_MODULE_SIG_UEFI</code>, in addition to any
|
||||
certificates embedded into the kernel image, the kernel can use
|
||||
certificates stored in the <code class="filename">db</code>,
|
||||
<code class="filename">KEK</code>, or <code class=
|
||||
"filename">PK</code> databases of the computer's UEFI firmware to
|
||||
verify the signatures of kernel modules, as long as they are not in
|
||||
the UEFI <code class="filename">dbx</code> blacklist.</p>
|
||||
<p>Any user who holds the private key for the Secure Boot
|
||||
<code class="filename">PK</code>, or any of the keys in the
|
||||
<code class="filename">KEK</code> list should be able to add new
|
||||
keys that can be used by a kernel with <code class=
|
||||
"option">CONFIG_MODULE_SIG_UEFI</code>, and any user with physical
|
||||
access to the computer should be able to delete any existing Secure
|
||||
Boot keys, and install his or her own keys instead. Please consult
|
||||
the documentation for your UEFI-based computer system for details
|
||||
on how to manage the UEFI Secure Boot keys.</p>
|
||||
</dd>
|
||||
<dt><span class="term">Certificates stored in a supplementary key
|
||||
database</span></dt>
|
||||
<dd>
|
||||
<p>Some distributions include utilities that allow for the secure
|
||||
storage and management of cryptographic keys in a database that is
|
||||
separate from the kernel's built-in key list, and the key lists in
|
||||
the UEFI firmware. A prominent example is the MOK (Machine Owner
|
||||
Key) database used by some versions of the <code class=
|
||||
"filename">shim</code> bootloader, and the associated management
|
||||
utilities, <code class="filename">mokutil</code> and <code class=
|
||||
"filename">MokManager</code>.</p>
|
||||
<p>Such a system allows users to enroll additional keys without the
|
||||
need to build a new kernel or manage the UEFI Secure Boot keys.
|
||||
Please consult your distribution's documentation for details on
|
||||
whether such a supplementary key database is available, and if so,
|
||||
how to manage its keys.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
</div>
|
||||
<p></p>
|
||||
<h3>Generating Signing Keys in nvidia-installer</h3>
|
||||
<p><code class="filename">nvidia-installer</code> can generate keys
|
||||
that can be used for module signing, if existing keys are not
|
||||
readily available. Note that a module signed by a newly generated
|
||||
key cannot be loaded into a kernel that requires signed modules
|
||||
until its key is trusted, and when such a module is installed on
|
||||
such a system, the installed driver will not be immediately usable,
|
||||
even if the installation was successful.</p>
|
||||
<p>When <code class="filename">nvidia-installer</code> generates a
|
||||
key pair and uses it to sign a kernel module, an X.509 certificate
|
||||
containing the public key will be installed to disk, so that it can
|
||||
be added to one of the kernel's trusted key sources. <code class=
|
||||
"filename">nvidia-installer</code> will report the location of the
|
||||
installed certificate: make a note of this location, and of the
|
||||
certificate's SHA1 fingerprint, so that you will be able to enroll
|
||||
the certificate and verify that it is correct, after the
|
||||
installation is finished.</p>
|
||||
<p>By default, <code class="filename">nvidia-installer</code> will
|
||||
attempt to securely delete the generated private key with
|
||||
<code class="filename">shred -u</code> after the module is signed.
|
||||
This is to prevent the key from being exploited to sign a malicious
|
||||
kernel module, but it also means that the same key can't be used
|
||||
again to install a different driver, or even to install the same
|
||||
driver on a different kernel. <code class=
|
||||
"filename">nvidia-installer</code> can optionally install the
|
||||
private signing key to disk, as it does with the public
|
||||
certificate, so that the key pair can be reused in the future.</p>
|
||||
<p>If you elect to install the private key, please make sure that
|
||||
appropriate precautions are taken to ensure that it cannot be
|
||||
stolen. Some examples of precautions you may wish to take:</p>
|
||||
<div class="variablelist">
|
||||
<dl>
|
||||
<dt><span class="term">Prevent the key from being read by anybody
|
||||
without physical access to the computer</span></dt>
|
||||
<dd>
|
||||
<p>In general, physical access is required to install Secure Boot
|
||||
keys, including keys managed outside of the standard UEFI key
|
||||
databases, to prevent attackers who have remotely compromised the
|
||||
security of the operating system from installing malicious boot
|
||||
code. If a trusted key is available to remote users, even root,
|
||||
then it will be possible for an attacker to sign arbitrary kernel
|
||||
modules without first having physical access, making the system
|
||||
less secure.</p>
|
||||
<p>One way to ensure that the key is not available to remote users
|
||||
is to keep it on a removable storage medium, which is disconnected
|
||||
from the computer except when signing modules.</p>
|
||||
</dd>
|
||||
<dt><span class="term">Do not store the unencrypted private
|
||||
key</span></dt>
|
||||
<dd>
|
||||
<p>Encrypting the private key can add an extra layer of security:
|
||||
the key will not be useful for signing modules unless it can be
|
||||
successfully decrypted, first. Make sure not to store unencrypted
|
||||
copies of the key on persistent storage: either use volatile
|
||||
storage (e.g. a RAM disk), or securely delete any unencrypted
|
||||
copies of the key when not in use (e.g. using <code class=
|
||||
"filename">shred</code> instead of <code class=
|
||||
"filename">rm</code>). Note that using <code class=
|
||||
"filename">shred</code> may not be sufficient to fully purge data
|
||||
from some storage devices, in particular, some types of solid state
|
||||
storage.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
</div>
|
||||
<p></p>
|
||||
<h3>Alternatives to the Installer's Module Signing Support</h3>
|
||||
<p>It is possible to load the NVIDIA kernel module on a system that
|
||||
requires signed modules, without using the installer's module
|
||||
signing support. Depending on your particular use case, you may
|
||||
find one of these alternatives more suitable than signing the
|
||||
module with <code class="filename">nvidia-installer</code>:</p>
|
||||
<div class="variablelist">
|
||||
<dl>
|
||||
<dt><span class="term">Disable UEFI Secure Boot, if
|
||||
applicable</span></dt>
|
||||
<dd>
|
||||
<p>On some kernels, a requirement for signed modules is only
|
||||
enforced when booted on a UEFI system with Secure Boot enabled.
|
||||
Some users of such kernels may find it more convenient to disable
|
||||
Secure Boot; however, note that this will reduce the security of
|
||||
your system by making it easier for malicious users to install
|
||||
potentially harmful boot code, kernels, or kernel modules.</p>
|
||||
</dd>
|
||||
<dt><span class="term">Use a kernel that doesn't require signed
|
||||
modules</span></dt>
|
||||
<dd>
|
||||
<p>The kernel can be configured not to check module signatures, or
|
||||
to check module signatures, but allow modules without a trusted
|
||||
signature to be loaded, anyway. Installing a kernel configured in
|
||||
such a way will allow the installation of unsigned modules. Note
|
||||
that on Secure Boot systems, you will still need to ensure that the
|
||||
kernel be signed with a key trusted by the bootloader and/or boot
|
||||
firmware, and that a kernel that doesn't enforce module signature
|
||||
verification may be slightly less secure than one that does.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
</div>
|
||||
<p></p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"AddingPrecompil0c783" id="AddingPrecompil0c783"></a>Adding
|
||||
Precompiled Kernel Interfaces to the Installer Package</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>When <code class="filename">nvidia-installer</code> runs, it
|
||||
searches for a pre-compiled kernel interface layer for the target
|
||||
kernel: if one is found, then the complete kernel module can be
|
||||
produced by linking the precompiled interface with <code class=
|
||||
"filename">nv-kernel.o</code>, instead of needing to compile the
|
||||
kernel interface on the target system. <code class=
|
||||
"filename">nvidia-installer</code> includes a feature which allows
|
||||
users to add a precompiled interface to the installer package. This
|
||||
is useful in many use cases; for example, an administrator of a
|
||||
large group of similarly configured computers can prepare an
|
||||
installer package with a precompiled interface for the kernel
|
||||
running on those computers, then deploy the customized installer,
|
||||
which will be able to install the NVIDIA kernel module without
|
||||
needing to have the kernel development headers or a compiler
|
||||
installed on the target systems. (A linker is still required.)</p>
|
||||
<p>To use this feature, simply invoke the <code class=
|
||||
"filename">.run</code> installer package with the <code class=
|
||||
"option">--add-this-kernel</code> option; e.g.</p>
|
||||
<pre class="screen">
|
||||
# sh ./NVIDIA-Linux-x86_64-535.161.07.run --add-this-kernel
|
||||
</pre>
|
||||
<p>This will unpack <code class=
|
||||
"filename">NVIDIA-Linux-x86_64-535.161.07.run</code>, compile a
|
||||
kernel interface layer for the currently running kernel (use the
|
||||
<code class="option">--kernel-source-path</code> and <code class=
|
||||
"option">--kernel-output-path</code> options to specify a target
|
||||
kernel other than the currently running one), and create a new
|
||||
installer package with the kernel interface layer added.</p>
|
||||
<p>Administrators of large groups of similarly configured computers
|
||||
that are configured to require trusted signatures in order to load
|
||||
kernel modules may find this feature especially useful when
|
||||
combined with the built-in support for module signing in
|
||||
<code class="filename">nvidia-installer</code>. To package a .run
|
||||
file with a precompiled kernel interface layer, plus a detached
|
||||
module signature for the linked module, just use the <code class=
|
||||
"option">--module-signing-secret-key</code> and <code class=
|
||||
"option">--module-signing-public-key</code> options alongside the
|
||||
<code class="option">--add-this-kernel</code> option. The resulting
|
||||
package, besides being installable without kernel headers or a
|
||||
compiler on the target system, has the added benefit of being able
|
||||
to produce a signed module without needing access to the private
|
||||
key on the install target system. Note that the detached signature
|
||||
will only be valid if the result of linking the precompiled
|
||||
interface with <code class="filename">nv-kernel.o</code> on the
|
||||
target system is exactly the same as the result of linking those
|
||||
two files on the system that was used to create the custom
|
||||
installer. To ensure optimal compatibility, the linker used on both
|
||||
the package preparation system and the install target system should
|
||||
be the same.</p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"OtherFeaturesOfd7638" id="OtherFeaturesOfd7638"></a>Other Features
|
||||
of the Installer</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>Without options, the <code class="filename">.run</code> file
|
||||
executes the installer after unpacking it. The installer can be run
|
||||
as a separate step in the process, or can be run at a later time to
|
||||
get updates, etc. Some of the more important commandline options of
|
||||
<code class="filename">nvidia-installer</code> are:</p>
|
||||
<div class="variablelist">
|
||||
<p class="title"><b><code class="filename">nvidia-installer</code>
|
||||
options</b></p>
|
||||
<dl>
|
||||
<dt><span class="term"><code class=
|
||||
"option">--uninstall</code></span></dt>
|
||||
<dd>
|
||||
<p>During installation, the installer will make backups of any
|
||||
conflicting files and record the installation of new files. The
|
||||
uninstall option undoes an install, restoring the system to its
|
||||
pre-install state.</p>
|
||||
</dd>
|
||||
<dt><span class="term"><code class=
|
||||
"option">--ui=none</code></span></dt>
|
||||
<dd>
|
||||
<p>The installer uses an ncurses-based user interface if it is able
|
||||
to locate the correct ncurses library. Otherwise, it will fall back
|
||||
to a simple commandline user interface. This option disables the
|
||||
use of the ncurses library.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
</div>
|
||||
<p></p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"selectdriver.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"installedcomponents.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 3. Selecting and Downloading the NVIDIA Packages
|
||||
for Your System </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 5. Listing of Installed Components</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,574 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 5. Listing of Installed Components</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="installdriver.html" title=
|
||||
"Chapter 4. Installing the NVIDIA Driver">
|
||||
<link rel="next" href="editxconfig.html" title=
|
||||
"Chapter 6. Configuring X for the NVIDIA Driver">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 5. Listing of
|
||||
Installed Components</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"installdriver.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"editxconfig.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="installedcomponents" id=
|
||||
"installedcomponents"></a>Chapter 5. Listing of Installed
|
||||
Components</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>The NVIDIA Accelerated Linux Graphics Driver consists of the
|
||||
following components (filenames in parentheses are the full names
|
||||
of the components after installation). Some paths may be different
|
||||
on different systems (e.g., X modules may be installed in
|
||||
/usr/X11R6/ rather than /usr/lib/xorg/).</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>An X driver (<code class=
|
||||
"filename">/usr/lib/xorg/modules/drivers/nvidia_drv.so</code>);
|
||||
this driver is needed by the X server to use your NVIDIA
|
||||
hardware.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>A GLX extension module for X (<code class=
|
||||
"filename">/usr/lib/xorg/modules/extensions/libglxserver_nvidia.so.535.161.07</code>);
|
||||
this module is used by the X server to provide server-side GLX
|
||||
support.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>EGL and OpenGL ES libraries ( <code class=
|
||||
"filename">/usr/lib/libEGL.so.1</code>, <code class=
|
||||
"filename">/usr/lib/libGLESv1_CM.so.535.161.07</code>, and
|
||||
<code class="filename">/usr/lib/libGLESv2.so.535.161.07</code> );
|
||||
these libraries provide the API entry points for all OpenGL ES and
|
||||
EGL function calls. They are loaded at run-time by
|
||||
applications.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>A Wayland EGL external platform library (<code class=
|
||||
"filename">/usr/lib/libnvidia-egl-wayland.so.1</code>) and its
|
||||
corresponding configuration file ( <code class=
|
||||
"filename">/usr/share/egl/egl_external_platform.d/10_nvidia_wayland.json</code>
|
||||
); this library provides client-side Wayland EGL application
|
||||
support using either dmabuf or EGLStream buffer sharing protocols,
|
||||
as well as server-side protocol extensions enabling the client-side
|
||||
EGLStream-based buffer sharing path. The EGLStream path can only be
|
||||
used in combination with an EGLStream-enabled Wayland compositor,
|
||||
e.g: <a href="https://gitlab.freedesktop.org/ekurzinger/weston"
|
||||
target=
|
||||
"_top">https://gitlab.freedesktop.org/ekurzinger/weston</a>.</p>
|
||||
<p>More information can be found along with the EGL external
|
||||
interface and Wayland library source code at <a href=
|
||||
"https://github.com/NVIDIA/eglexternalplatform" target=
|
||||
"_top">https://github.com/NVIDIA/eglexternalplatform</a> and
|
||||
<a href="https://github.com/NVIDIA/egl-wayland" target=
|
||||
"_top">https://github.com/NVIDIA/egl-wayland</a>.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>A GBM EGL external platform library (<code class=
|
||||
"filename">/usr/lib/libnvidia-egl-gbm.so.1</code>) and its
|
||||
corresponding configuration file ( <code class=
|
||||
"filename">/usr/share/egl/egl_external_platform.d/15_nvidia_gbm.json</code>
|
||||
); this library provides GBM EGL application support.</p>
|
||||
<p>The source code for the GBM EGL external platform library can be
|
||||
found at <a href="https://github.com/NVIDIA/egl-gbm" target=
|
||||
"_top">https://github.com/NVIDIA/egl-gbm</a>. See <a href=
|
||||
"gbm.html" title=
|
||||
"Chapter 40. GBM and GBM-based Wayland Compositors">Chapter 40,
|
||||
<i>GBM and GBM-based Wayland Compositors</i></a> for more details
|
||||
on GBM support in the NVIDIA driver.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Vendor neutral graphics libraries provided by libglvnd
|
||||
(<code class="filename">/usr/lib/libOpenGL.so.0</code>,
|
||||
<code class="filename">/usr/lib/libGLX.so.0</code>, and
|
||||
<code class="filename">/usr/lib/libGLdispatch.so.0</code>); these
|
||||
libraries are currently used to provide full OpenGL dispatching
|
||||
support to NVIDIA's implementation of EGL.</p>
|
||||
<p>Source code for libglvnd is available at <a href=
|
||||
"https://github.com/NVIDIA/libglvnd" target=
|
||||
"_top">https://github.com/NVIDIA/libglvnd</a></p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GLVND vendor implementation libraries for GLX (<code class=
|
||||
"filename">/usr/lib/libGLX_nvidia.so.0</code>) and EGL
|
||||
(<code class="filename">/usr/lib/libEGL_nvidia.so.0</code>); these
|
||||
libraries provide NVIDIA implementations of OpenGL functionality
|
||||
which may be accessed using the GLVND client-facing libraries.</p>
|
||||
<p><code class="filename">libGLX_nvidia.so.0</code> and
|
||||
<code class="filename">libEGL_nvidia.so.0</code> can be used as
|
||||
Vulkan ICDs. The Vulkan ICD configuration file included with the
|
||||
driver references <code class="filename">libGLX_nvidia.so.0</code>,
|
||||
however in environments where X11 client libraries are not
|
||||
available, <code class="filename">libEGL_nvidia.so.0</code> should
|
||||
be used.</p>
|
||||
<p>The Vulkan ICD configuration file is installed as <code class=
|
||||
"filename">/etc/vulkan/icd.d/nvidia_icd.json</code>.</p>
|
||||
<p>An additional Vulkan layer configuration file is installed as
|
||||
<code class=
|
||||
"filename">/etc/vulkan/implicit_layer.d/nvidia_layers.json</code>.
|
||||
These layers add functionality to the Vulkan loader.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>A GLVND GLX client ICD loader library (<code class=
|
||||
"filename">/usr/lib/libGL.so.1</code>), This library provides API
|
||||
entry points for all GLX function calls, and is loaded at run-time
|
||||
by applications.</p>
|
||||
<p>This library is included as a convenience to support systems
|
||||
that do not already have an existing libglvnd installation. On
|
||||
systems with libglvnd libraries already installed, the existing
|
||||
libraries should be used instead.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Various libraries that are used internally by other driver
|
||||
components. These include <code class=
|
||||
"filename">/usr/lib/libnvidia-cfg.so.535.161.07</code>,
|
||||
<code class=
|
||||
"filename">/usr/lib/libnvidia-eglcore.so.535.161.07</code>,
|
||||
<code class=
|
||||
"filename">/usr/lib/libnvidia-glcore.so.535.161.07</code>,
|
||||
<code class=
|
||||
"filename">/usr/lib/libnvidia-glsi.so.535.161.07</code>,
|
||||
<code class=
|
||||
"filename">/usr/lib/libnvidia-glvkspirv.so.535.161.07</code>,
|
||||
<code class=
|
||||
"filename">/usr/lib/libnvidia-rtcore.so.535.161.07</code>, and
|
||||
<code class=
|
||||
"filename">/usr/lib/libnvidia-allocator.so.535.161.07</code>.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>A VDPAU (Video Decode and Presentation API for Unix-like
|
||||
systems) library for the NVIDIA vendor implementation,
|
||||
(<code class="filename">/usr/lib/vdpau/libvdpau_nvidia.so.535.161.07</code>);
|
||||
see <a href="vdpausupport.html" title=
|
||||
"Appendix G. VDPAU Support">Appendix G, <i>VDPAU
|
||||
Support</i></a> for details.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The CUDA library (<code class=
|
||||
"filename">/usr/lib/libcuda.so.535.161.07</code>) which provides
|
||||
runtime support for CUDA (high-performance computing on the GPU)
|
||||
applications.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The CUDA Debugger library (<code class=
|
||||
"filename">/usr/lib/libcudadebugger.so.535.161.07</code>) which
|
||||
provides support for debugging CUDA applications.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Cryptography library wrappers, (<code class=
|
||||
"filename">/usr/lib/libnvidia-pkcs11.so.535.161.07</code>) and
|
||||
(<code class=
|
||||
"filename">/usr/lib/libnvidia-pkcs11.openssl3.so.535.161.07</code>),
|
||||
which dynamically link to the system's OpenSSL libraries and
|
||||
provide cryptography operations when the GPU and driver are
|
||||
operating in Confidential Compute mode. The driver attempts to use
|
||||
OpenSSL 3 first and if OpenSSL 3 is not available then it will
|
||||
attempt to use OpenSSL 1.1.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The PTX JIT Compiler library (<code class=
|
||||
"filename">/usr/lib/libnvidia-ptxjitcompiler.so.535.161.07</code>)
|
||||
is a JIT compiler which compiles PTX into GPU machine code and is
|
||||
used by the CUDA driver.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The NVVM Compiler library (<code class=
|
||||
"filename">/usr/lib/libnvidia-nvvm.so.4.0.0</code>) is loaded by
|
||||
the CUDA driver to do JIT link-time-optimization.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Two OpenCL libraries (<code class=
|
||||
"filename">/usr/lib/libOpenCL.so.1.0.0</code>, <code class=
|
||||
"filename">/usr/lib/libnvidia-opencl.so.535.161.07</code>); the
|
||||
former is a vendor-independent Installable Client Driver (ICD)
|
||||
loader, and the latter is the NVIDIA Vendor ICD. A config file
|
||||
<code class="filename">/etc/OpenCL/vendors/nvidia.icd</code> is
|
||||
also installed, to advertise the NVIDIA Vendor ICD to the ICD
|
||||
Loader.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The <code class="filename">nvidia-cuda-mps-control</code> and
|
||||
<code class="filename">nvidia-cuda-mps-server</code> applications,
|
||||
which allow MPI processes to run concurrently on a single GPU.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>A kernel module (<code class="filename">/lib/modules/`uname
|
||||
-r`/kernel/drivers/video/nvidia-modeset.ko</code>); this kernel
|
||||
module is responsible for programming the display engine of the
|
||||
GPU. User-mode NVIDIA driver components such as the NVIDIA X
|
||||
driver, OpenGL driver, and VDPAU driver communicate with
|
||||
nvidia-modeset.ko through the /dev/nvidia-modeset device file.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>A kernel module (<code class="filename">/lib/modules/`uname
|
||||
-r`/kernel/drivers/video/nvidia.ko</code>); this kernel module
|
||||
provides low-level access to your NVIDIA hardware for all of the
|
||||
above components. It is generally loaded into the kernel when the X
|
||||
server is started, and is used by the X driver and OpenGL.
|
||||
nvidia.ko consists of two pieces: the binary-only core, and a
|
||||
kernel interface that must be compiled specifically for your kernel
|
||||
version. Note that the Linux kernel does not have a consistent
|
||||
binary interface like the X server, so it is important that this
|
||||
kernel interface be matched with the version of the kernel that you
|
||||
are using. This can either be accomplished by compiling yourself,
|
||||
or using precompiled binaries provided for the kernels shipped with
|
||||
some of the more common Linux distributions.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>NVIDIA Unified Memory kernel module (<code class=
|
||||
"filename">/lib/modules/`uname
|
||||
-r`/kernel/drivers/video/nvidia-uvm.ko</code>); this kernel module
|
||||
provides functionality for sharing memory between the CPU and GPU
|
||||
in CUDA programs. It is generally loaded into the kernel when a
|
||||
CUDA program is started, and is used by the CUDA driver on
|
||||
supported platforms.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The nvidia-tls library (<code class=
|
||||
"filename">/usr/lib/libnvidia-tls.so.535.161.07</code>); this file
|
||||
provides thread local storage support for the NVIDIA OpenGL
|
||||
libraries (libGLX_nvidia, libnvidia-glcore, and
|
||||
libglxserver_nvidia).</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The nvidia-ml library (<code class=
|
||||
"filename">/usr/lib/libnvidia-ml.so.535.161.07</code>); The NVIDIA
|
||||
Management Library provides a monitoring and management API. See
|
||||
<a href="nvidia-ml.html" title=
|
||||
"Chapter 28. The NVIDIA Management Library">Chapter 28,
|
||||
<i>The NVIDIA Management Library</i></a> for more information.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The application nvidia-installer (<code class=
|
||||
"filename">/usr/bin/nvidia-installer</code>) is NVIDIA's tool for
|
||||
installing and updating NVIDIA drivers. See <a href=
|
||||
"installdriver.html" title=
|
||||
"Chapter 4. Installing the NVIDIA Driver">Chapter 4,
|
||||
<i>Installing the NVIDIA Driver</i></a> for a more thorough
|
||||
description.</p>
|
||||
<p>Source code is available at <a href=
|
||||
"https://download.nvidia.com/XFree86/nvidia-installer/" target=
|
||||
"_top">https://download.nvidia.com/XFree86/nvidia-installer/</a>.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The application nvidia-modprobe (<code class=
|
||||
"filename">/usr/bin/nvidia-modprobe</code>) is installed as setuid
|
||||
root and is used to load the NVIDIA kernel module, create the
|
||||
<code class="filename">/dev/nvidia*</code> device nodes and
|
||||
configure certain runtime settings in the kernel by processes (such
|
||||
as CUDA applications) that don't run with sufficient privileges to
|
||||
do those things themselves.</p>
|
||||
<p>Source code is available at <a href=
|
||||
"https://download.nvidia.com/XFree86/nvidia-modprobe/" target=
|
||||
"_top">https://download.nvidia.com/XFree86/nvidia-modprobe/</a>.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The application nvidia-xconfig (<code class=
|
||||
"filename">/usr/bin/nvidia-xconfig</code>) is NVIDIA's tool for
|
||||
manipulating X server configuration files. See <a href=
|
||||
"editxconfig.html" title=
|
||||
"Chapter 6. Configuring X for the NVIDIA Driver">Chapter 6,
|
||||
<i>Configuring X for the NVIDIA Driver</i></a> for more
|
||||
information.</p>
|
||||
<p>Source code is available at <a href=
|
||||
"https://download.nvidia.com/XFree86/nvidia-xconfig/" target=
|
||||
"_top">https://download.nvidia.com/XFree86/nvidia-xconfig/</a>.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The application nvidia-settings (<code class=
|
||||
"filename">/usr/bin/nvidia-settings</code>) is NVIDIA's tool for
|
||||
dynamic configuration while the X server is running. See <a href=
|
||||
"nvidiasettings.html" title=
|
||||
"Chapter 25. Using the nvidia-settings Utility">Chapter 25,
|
||||
<i>Using the nvidia-settings Utility</i></a> for more
|
||||
information.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The libnvidia-gtk libraries (<code class=
|
||||
"filename">/usr/lib/libnvidia-gtk2.so.535.161.07</code> and
|
||||
<code class=
|
||||
"filename">/usr/lib/libnvidia-gtk3.so.535.161.07</code>); these
|
||||
libraries are required to provide the nvidia-settings user
|
||||
interface.</p>
|
||||
<p>Source code is available at <a href=
|
||||
"https://download.nvidia.com/XFree86/nvidia-settings/" target=
|
||||
"_top">https://download.nvidia.com/XFree86/nvidia-settings/</a>.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The application nvidia-smi (<code class=
|
||||
"filename">/usr/bin/nvidia-smi</code>) is the NVIDIA System
|
||||
Management Interface for management and monitoring functionality.
|
||||
See <a href="nvidia-smi.html" title=
|
||||
"Chapter 27. Using the nvidia-smi Utility">Chapter 27,
|
||||
<i>Using the nvidia-smi Utility</i></a> for more information.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The application nvidia-debugdump (<code class=
|
||||
"filename">/usr/bin/nvidia-debugdump</code>) is NVIDIA's tool for
|
||||
collecting internal GPU state. It is normally invoked by the
|
||||
nvidia-bug-report.sh (<code class=
|
||||
"filename">/usr/bin/nvidia-bug-report.sh</code>) script. See
|
||||
<a href="nvidia-debugdump.html" title=
|
||||
"Chapter 29. Using the nvidia-debugdump Utility">Chapter 29,
|
||||
<i>Using the nvidia-debugdump Utility</i></a> for more
|
||||
information.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The daemon nvidia-persistenced (<code class=
|
||||
"filename">/usr/bin/nvidia-persistenced</code>) is the NVIDIA
|
||||
Persistence Daemon for allowing the NVIDIA kernel module to
|
||||
maintain persistent state when no other NVIDIA driver components
|
||||
are running. See <a href="nvidia-persistenced.html" title=
|
||||
"Chapter 30. Using the nvidia-persistenced Utility">Chapter 30,
|
||||
<i>Using the nvidia-persistenced Utility</i></a> for more
|
||||
information.</p>
|
||||
<p>Source code is available at <a href=
|
||||
"https://download.nvidia.com/XFree86/nvidia-persistenced/" target=
|
||||
"_top">https://download.nvidia.com/XFree86/nvidia-persistenced/</a>.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The NVCUVID library (<code class=
|
||||
"filename">/usr/lib/libnvcuvid.so.535.161.07</code>); The NVIDIA
|
||||
CUDA Video Decoder (NVCUVID) library provides an interface to
|
||||
hardware video decoding capabilities on NVIDIA GPUs with CUDA.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The NvEncodeAPI library (<code class=
|
||||
"filename">/usr/lib/libnvidia-encode.so.535.161.07</code>); The
|
||||
NVENC Video Encoding library provides an interface to video encoder
|
||||
hardware on supported NVIDIA GPUs.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The NVAPI library (<code class=
|
||||
"filename">/usr/lib/libnvidia-api.so.1;</code>); NVAPI provides an
|
||||
interface for managing properties of GPUs. The NVAPI library
|
||||
provides runtime support for NVAPI applications.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The NvFBC library (<code class=
|
||||
"filename">/usr/lib/libnvidia-fbc.so.535.161.07</code>); The
|
||||
NVIDIA Framebuffer Capture library provides an interface to capture
|
||||
and optionally encode the framebuffer of an X server screen.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>An X driver configuration file (<code class=
|
||||
"filename">/usr/share/X11/xorg.conf.d/nvidia-drm-outputclass.conf</code>);
|
||||
If the X server is sufficiently new, this file will be installed to
|
||||
configure the X server to load the <code class=
|
||||
"filename">nvidia_drv.so</code> driver automatically if it is
|
||||
started after the NVIDIA DRM kernel module (<code class=
|
||||
"filename">nvidia-drm.ko</code>) is loaded. This feature is
|
||||
supported in X.Org xserver 1.16 and higher when running on Linux
|
||||
kernel 3.13 or higher with CONFIG_DRM enabled.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Predefined application profile keys and documentation for those
|
||||
keys can be found in the following files in the directory
|
||||
<code class="filename">/usr/share/nvidia/</code>: <code class=
|
||||
"filename">nvidia-application-profiles-535.161.07-rc</code>,
|
||||
<code class=
|
||||
"filename">nvidia-application-profiles-535.161.07-key-documentation</code>.</p>
|
||||
<p>See <a href="profiles.html" title=
|
||||
"Appendix J. Application Profiles">Appendix J,
|
||||
<i>Application Profiles</i></a> for more information.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The OptiX library (<code class=
|
||||
"filename">/usr/lib/libnvoptix.so.1</code>); This library
|
||||
implements the OptiX ray tracing engine. It is loaded by the
|
||||
<code class="filename">liboptix.so.*</code> library bundled with
|
||||
applications that use the OptiX API.</p>
|
||||
<p>OptiX also includes a data file <code class=
|
||||
"filename">/usr/share/nvidia/nvoptix.bin</code>.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The NVIDIA Optical Flow library (<code class=
|
||||
"filename">/usr/lib/libnvidia-opticalflow.so.535.161.07</code>);
|
||||
The NVIDIA Optical Flow library can be used for
|
||||
hardware-accelerated computation of optical flow vectors and stereo
|
||||
disparity values on Turing and later NVIDIA GPUs. This is useful
|
||||
for some forms of computer vision and image analysis. The Optical
|
||||
Flow library depends on the NVCUVID library, which in turn depends
|
||||
on the CUDA library.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>NGX (<code class=
|
||||
"filename">/usr/lib/libnvidia-ngx.so.535.161.07</code>); and the
|
||||
NVIDIA NGX Updater (<code class=
|
||||
"filename">/usr/bin/nvidia-ngx-updater</code>); NGX is a collection
|
||||
of software which provides AI features to applications. On Linux
|
||||
this is supported only with x86_64 applications. Developers
|
||||
interested in using NGX in their applications should visit the
|
||||
following resources:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="circle">
|
||||
<li>
|
||||
<p><a href="https://developer.nvidia.com/rtx/ngx" target=
|
||||
"_top">https://developer.nvidia.com/rtx/ngx</a></p>
|
||||
</li>
|
||||
<li>
|
||||
<p><a href="https://developer.nvidia.com/dlss" target=
|
||||
"_top">https://developer.nvidia.com/dlss</a></p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p>NGX comes with nvidia-ngx-updater, a binary which updates NGX
|
||||
features without requiring a full application update. By default
|
||||
this functionality is disabled on Linux and needs to be enabled via
|
||||
a configuration file; see <a href="ngx.html" title=
|
||||
"Chapter 38. NGX">Chapter 38, <i>NGX</i></a> for
|
||||
details.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>A kernel module (<code class="filename">/lib/modules/`uname
|
||||
-r`/kernel/drivers/video/nvidia-peermem.ko</code>); this kernel
|
||||
module allows Mellanox HCAs access to NVIDIA GPU memory read/write
|
||||
buffers without needing to copy data to host memory. See <a href=
|
||||
"nvidia-peermem.html" title=
|
||||
"Chapter 42. GPUDirect RDMA Peer Memory Client">Chapter 42,
|
||||
<i>GPUDirect RDMA Peer Memory Client</i></a> for more
|
||||
information.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>NGX for Proton and Wine (<code class=
|
||||
"filename">/usr/lib/nvidia/wine/nvngx.dll</code>); (<code class=
|
||||
"filename">/usr/lib/nvidia/wine/_nvngx.dll</code>);</p>
|
||||
<p>NGX for Proton and Wine is a Microsoft Windows dynamic-link
|
||||
library used by Microsoft Windows applications which support NVIDIA
|
||||
DLSS.</p>
|
||||
<p>In addition to driver-side support, changes to third-party
|
||||
software are required in order to support DLSS within Proton and
|
||||
Wine.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Firmware (<code class=
|
||||
"filename">/lib/firmware/nvidia/535.161.07/gsp_*.bin</code>) which
|
||||
offloads tasks from the CPU to the GPU. See <a href="gsp.html"
|
||||
title="Chapter 43. GSP Firmware">Chapter 43, <i>GSP
|
||||
Firmware</i></a> for more information.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
<p>Problems will arise if applications use the wrong version of a
|
||||
library. This can be the case if there are either old libGL
|
||||
libraries or stale symlinks left lying around. If you think there
|
||||
may be something awry in your installation, check that the
|
||||
following files are in place (these are all the files of the NVIDIA
|
||||
Accelerated Linux Graphics Driver, as well as their symlinks):</p>
|
||||
<pre class="screen">
|
||||
/usr/lib/xorg/modules/drivers/nvidia_drv.so
|
||||
|
||||
/usr/lib/xorg/modules/extensions/libglxserver_nvidia.so.535.161.07
|
||||
/usr/lib/xorg/modules/extensions/libglxserver_nvidia.so -> libglxserver_nvidia.so.535.161.07
|
||||
|
||||
/usr/lib/libGL.so.1.0.0;
|
||||
/usr/lib/libGL.so.1 -> libGL.so.1.0.0;
|
||||
/usr/lib/libGL.so -> libGL.so.1
|
||||
|
||||
(libGL.so.1.0.0 is the name of the libglvnd client-side GLX ICD loader
|
||||
library included with the NVIDIA Linux driver. A compatible ICD loader
|
||||
provided by your distribution may have a slightly different filename.)
|
||||
|
||||
/usr/lib/libnvidia-glcore.so.535.161.07
|
||||
|
||||
/usr/lib/libcuda.so.535.161.07
|
||||
/usr/lib/libcuda.so -> libcuda.so.535.161.07
|
||||
|
||||
/lib/modules/`uname -r`/video/nvidia.{o,ko}, or
|
||||
/lib/modules/`uname -r`/kernel/drivers/video/nvidia.{o,ko}
|
||||
</pre>
|
||||
<p>If there are other libraries whose "soname" conflicts with that
|
||||
of the NVIDIA libraries, ldconfig may create the wrong symlinks. It
|
||||
is recommended that you manually remove or rename conflicting
|
||||
libraries (be sure to rename clashing libraries to something that
|
||||
ldconfig will not look at -- we have found that prepending "XXX" to
|
||||
a library name generally does the trick), rerun 'ldconfig', and
|
||||
check that the correct symlinks were made. An example of a library
|
||||
that often creates conflicts is "/usr/lib/mesa/libGL.so*".</p>
|
||||
<p>If the libraries appear to be correct, then verify that the
|
||||
application is using the correct libraries. For example, to check
|
||||
that the application /usr/bin/glxgears is using the libglvnd GLX
|
||||
libraries, run:</p>
|
||||
<pre class="screen">
|
||||
% ldd /usr/bin/glxgears
|
||||
linux-vdso.so.1 (0x00007ffc8a5d4000)
|
||||
libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007f6593896000)
|
||||
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f65934f8000)
|
||||
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f65931c0000)
|
||||
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6592dcf000)
|
||||
libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f6592b9e000)
|
||||
libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f65928e8000)
|
||||
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f65926c9000)
|
||||
/lib64/ld-linux-x86-64.so.2 (0x00007f6593d28000)
|
||||
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f65924a1000)
|
||||
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f659229d000)
|
||||
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f6592099000)
|
||||
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f6591e93000)
|
||||
libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f6591c7e000)
|
||||
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f6591a76000)
|
||||
</pre>
|
||||
<p>In the example above, the list of libraries reported by
|
||||
<span><strong class="command">ldd</strong></span> includes
|
||||
<code class="filename">libGLX.so.0</code> and <code class=
|
||||
"filename">libGLdispatch.so.0</code>. If the GLX client library is
|
||||
something other than the GLVND <code class=
|
||||
"filename">libGL.so.1</code>, then you will need to either remove
|
||||
the library that is getting in the way or adjust your dynamic
|
||||
loader search path using the <code class=
|
||||
"envar">LD_LIBRARY_PATH</code> environment variable. You may want
|
||||
to consult the man pages for <span><strong class=
|
||||
"command">ldconfig</strong></span> and <span><strong class=
|
||||
"command">ldd</strong></span>.</p>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"installdriver.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"editxconfig.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 4. Installing the NVIDIA Driver </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 6. Configuring X for the NVIDIA Driver</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,121 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 1. Introduction</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="next" href="minimumrequirements.html" title=
|
||||
"Chapter 2. Minimum Requirements">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">
|
||||
Chapter 1. Introduction</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"installationandconfiguration.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"minimumrequirements.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="introduction" id=
|
||||
"introduction"></a>Chapter 1. Introduction</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<h3>About the NVIDIA Accelerated Linux Graphics Driver</h3>
|
||||
<p>The NVIDIA Accelerated Linux Graphics Driver brings accelerated
|
||||
2D functionality and high-performance OpenGL support to Linux
|
||||
x86_64 with the use of NVIDIA graphics processing units (GPUs).</p>
|
||||
<p>These drivers provide optimized hardware acceleration for OpenGL
|
||||
and X applications and support nearly all recent NVIDIA GPU
|
||||
products (see <a href="supportedchips.html" title=
|
||||
"Appendix A. Supported NVIDIA GPU Products">Appendix A,
|
||||
<i>Supported NVIDIA GPU Products</i></a> for a complete list of
|
||||
supported GPUs).</p>
|
||||
<h3>About this Document</h3>
|
||||
<p>This document provides instructions for the installation and use
|
||||
of the NVIDIA Accelerated Linux Graphics Driver. <a href=
|
||||
"selectdriver.html" title=
|
||||
"Chapter 3. Selecting and Downloading the NVIDIA Packages for Your System">
|
||||
Chapter 3, <i>Selecting and Downloading the NVIDIA Packages
|
||||
for Your System</i></a>, <a href="installdriver.html" title=
|
||||
"Chapter 4. Installing the NVIDIA Driver">Chapter 4,
|
||||
<i>Installing the NVIDIA Driver</i></a> and <a href=
|
||||
"editxconfig.html" title=
|
||||
"Chapter 6. Configuring X for the NVIDIA Driver">Chapter 6,
|
||||
<i>Configuring X for the NVIDIA Driver</i></a> walk the user
|
||||
through the process of downloading, installing and configuring the
|
||||
driver. <a href="faq.html" title=
|
||||
"Chapter 7. Frequently Asked Questions">Chapter 7,
|
||||
<i>Frequently Asked Questions</i></a> addresses frequently asked
|
||||
questions about the installation process, and <a href=
|
||||
"commonproblems.html" title=
|
||||
"Chapter 8. Common Problems">Chapter 8, <i>Common
|
||||
Problems</i></a> provides solutions to common problems. The
|
||||
remaining chapters include details on different features of the
|
||||
NVIDIA Linux Driver. Frequently asked questions about specific
|
||||
tasks are included in the relevant chapters. These pages are posted
|
||||
on NVIDIA's web site (<a href="http://www.nvidia.com" target=
|
||||
"_top">http://www.nvidia.com</a>), and are installed in
|
||||
<code class="filename">/usr/share/doc/NVIDIA_GLX-1.0/</code>.</p>
|
||||
<h3>About the Audience</h3>
|
||||
<p>It is assumed that the user and reader of this document has at
|
||||
least a basic understanding of Linux techniques and terminology.
|
||||
However, new Linux users can refer to <a href="newusertips.html"
|
||||
title=
|
||||
"Appendix I. Tips for New Linux Users">Appendix I,
|
||||
<i>Tips for New Linux Users</i></a> for details on parts of the
|
||||
installation process.</p>
|
||||
<h3>Additional Information</h3>
|
||||
<p>In case additional information is required, <a href=
|
||||
"addtlresources.html" title=
|
||||
"Chapter 45. NVIDIA Contact Info and Additional Resources">
|
||||
Chapter 45, <i>NVIDIA Contact Info and Additional
|
||||
Resources</i></a> provides contact information for NVIDIA Linux
|
||||
driver resources, as well as a brief listing of external
|
||||
resources.</p>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"installationandconfiguration.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"minimumrequirements.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Part I. Installation and Configuration
|
||||
Instructions </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 2. Minimum Requirements</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,198 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 44. Open Linux Kernel Modules</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="gsp.html" title=
|
||||
"Chapter 43. GSP Firmware">
|
||||
<link rel="next" href="addtlresources.html" title=
|
||||
"Chapter 45. NVIDIA Contact Info and Additional Resources">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 44. Open Linux
|
||||
Kernel Modules</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"gsp.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"addtlresources.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="kernel_open" id=
|
||||
"kernel_open"></a>Chapter 44. Open Linux Kernel
|
||||
Modules</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<h3>Introduction</h3>
|
||||
<p>The NVIDIA Linux GPU Driver contains several kernel modules:
|
||||
nvidia.ko, nvidia-modeset.ko, nvidia-uvm.ko, nvidia-drm.ko, and
|
||||
nvidia-peermem.ko.</p>
|
||||
<p>Two "flavors" of these kernel modules are provided:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>Proprietary. This is the flavor that NVIDIA has historically
|
||||
shipped.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Open, i.e. source-published, kernel modules that are dual
|
||||
licensed MIT/GPLv2. With every driver release, the source code to
|
||||
the open kernel modules is published on <a href=
|
||||
"https://github.com/NVIDIA/open-gpu-kernel-modules" target=
|
||||
"_top">https://github.com/NVIDIA/open-gpu-kernel-modules</a> and a
|
||||
tarball is provided on <a href=
|
||||
"https://download.nvidia.com/XFree86/" target=
|
||||
"_top">https://download.nvidia.com/XFree86/</a>.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<h3>Supported Features</h3>
|
||||
<p>The proprietary flavor supports the GPU architectures Maxwell,
|
||||
Pascal, Volta, Turing, and later GPUs.</p>
|
||||
<p>The open flavor of kernel modules supports Turing and later
|
||||
GPUs. The open kernel modules cannot support GPUs before Turing,
|
||||
because the open kernel modules depend on the GPU System Processor
|
||||
(GSP) first introduced in Turing.</p>
|
||||
<p>Most features of the Linux GPU driver are supported with the
|
||||
open flavor of kernel modules, including CUDA, Vulkan, OpenGL,
|
||||
OptiX, and X11. G-Sync with desktop GPUs is supported. Suspend,
|
||||
Hibernate, and Resume power management is supported, as is Run Time
|
||||
D3 (RTD3) on Ampere and later GPUs.</p>
|
||||
<p>However, in the current release, some display and graphics
|
||||
features (notably: SLI, G-Sync on notebooks, preserving video
|
||||
memory across power management events with
|
||||
NVreg_PreserveVideoMemoryAllocations set) and NVIDIA virtual GPU
|
||||
(vGPU), are not yet supported. These features will be added in
|
||||
upcoming driver releases.</p>
|
||||
<p>Use of the open kernel modules on GeForce and Workstation GPUs
|
||||
should be considered alpha-quality in this release due to the
|
||||
missing features listed above. To enable use of the open kernel
|
||||
modules on GeForce and Workstation GPUs, set the
|
||||
"NVreg_OpenRmEnableUnsupportedGpus" nvidia.ko kernel module
|
||||
parameter to <code class="computeroutput">1</code>. E.g.,</p>
|
||||
<pre class="screen">
|
||||
modprobe nvidia NVreg_OpenRmEnableUnsupportedGpus=1
|
||||
</pre>
|
||||
<p>or, in an /etc/modprobe.d/ configuration file:</p>
|
||||
<pre class="screen">
|
||||
options nvidia NVreg_OpenRmEnableUnsupportedGpus=1
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>The need for this kernel module parameter will be removed in a
|
||||
future release once performance and functionality in the open
|
||||
kernel modules matures and meets or exceeds that of the proprietary
|
||||
kernel modules.</p>
|
||||
<p>Though the kernel modules in the two flavors are different, they
|
||||
are based on the same underlying source code. The two flavors are
|
||||
mutually exclusive: they cannot be used within the kernel at the
|
||||
same time, and they should not be installed on the filesystem at
|
||||
the same time.</p>
|
||||
<p>The user-space components of the NVIDIA Linux GPU driver are
|
||||
identical and behave in the same way, regardless of which flavor of
|
||||
kernel module is used.</p>
|
||||
<h3>Installation</h3>
|
||||
<p>Because the two flavors of kernel modules are mutually
|
||||
exclusive, you need to choose which to use at install time. This
|
||||
can be selected with the "--kernel-module-build-directory" .run
|
||||
file option, or its short form "-m". Use "-m=kernel" to install the
|
||||
proprietary flavor of kernel modules (the default). Use
|
||||
"-m=kernel-open" to install the open flavor of kernel modules.</p>
|
||||
<p>E.g.,</p>
|
||||
<pre class="screen">
|
||||
sh ./NVIDIA-Linux-[...].run -m=kernel-open
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>As a convenience, the open kernel modules distributed in the
|
||||
.run file are pre-compiled.</p>
|
||||
<p>Advanced users, who want to instead build the open kernel
|
||||
modules from source, should do the following:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>Uninstall any existing driver with `nvidia-uninstall`.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Install from the .run file with "--no-kernel-modules" option, to
|
||||
install everything except the kernel modules.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Fetch, build, and install the open kernel module source from
|
||||
<a href="https://github.com/NVIDIA/open-gpu-kernel-modules" target=
|
||||
"_top">https://github.com/NVIDIA/open-gpu-kernel-modules</a>. See
|
||||
<a href=
|
||||
"https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/README.md"
|
||||
target=
|
||||
"_top">https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/README.md</a>
|
||||
for details on building.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p>Note that you must use the same version of the .run file and the
|
||||
open kernel module source from <a href=
|
||||
"https://github.com/NVIDIA/open-gpu-kernel-modules" target=
|
||||
"_top">https://github.com/NVIDIA/open-gpu-kernel-modules</a></p>
|
||||
<p>You can determine which flavor of kernel modules is installed
|
||||
using either `modinfo` or looking at
|
||||
/proc/driver/nvidia/version.</p>
|
||||
<p>E.g., the proprietary flavor will report:</p>
|
||||
<pre class="screen">
|
||||
# modinfo nvidia | grep license
|
||||
license: NVIDIA
|
||||
|
||||
# cat /proc/driver/nvidia/version
|
||||
NVRM version: NVIDIA UNIX x86_64 Kernel Module [...]
|
||||
</pre>
|
||||
<p>The open flavor will report:</p>
|
||||
<pre class="screen">
|
||||
# modinfo nvidia | grep license
|
||||
license: Dual MIT/GPL
|
||||
|
||||
# cat /proc/driver/nvidia/version
|
||||
NVRM version: NVIDIA UNIX Open Kernel Module for x86_64 [...]
|
||||
</pre>
|
||||
<p></p>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"gsp.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"addtlresources.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">Chapter 43. GSP
|
||||
Firmware </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 45. NVIDIA Contact Info and Additional
|
||||
Resources</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,150 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 36. Direct Rendering Manager Kernel
|
||||
Modesetting (DRM KMS)</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="primerenderoffload.html" title=
|
||||
"Chapter 35. PRIME Render Offload">
|
||||
<link rel="next" href="egpu.html" title=
|
||||
"Chapter 37. Configuring External and Removable GPUs">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 36. Direct
|
||||
Rendering Manager Kernel Modesetting (DRM KMS)</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"primerenderoffload.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"egpu.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="kms" id=
|
||||
"kms"></a>Chapter 36. Direct Rendering Manager Kernel
|
||||
Modesetting (DRM KMS)</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="toc">
|
||||
<p><b>Table of Contents</b></p>
|
||||
<dl>
|
||||
<dt><span class="section"><a href=
|
||||
"kms.html#drm-kms-known-issues">Known Issues</a></span></dt>
|
||||
</dl>
|
||||
</div>
|
||||
<p>The NVIDIA GPU driver package provides a kernel module,
|
||||
<code class="filename">nvidia-drm.ko</code>, which registers a DRM
|
||||
driver with the DRM subsystem of the Linux kernel. The capabilities
|
||||
advertised by this DRM driver depend on the Linux kernel version
|
||||
and configuration:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>PRIME: This is needed to support graphics display offload in
|
||||
RandR 1.4. Linux kernel version 3.13 or higher is required, with
|
||||
CONFIG_DRM enabled.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Atomic Modeset: This is used for display of non-X11 based
|
||||
desktop environments, such as Wayland and Mir. Linux kernel version
|
||||
4.1 or higher is required, with CONFIG_DRM and
|
||||
CONFIG_DRM_KMS_HELPER enabled.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p>NVIDIA's DRM KMS support is still considered experimental. It is
|
||||
disabled by default, but can be enabled on suitable kernels with
|
||||
the 'modeset' kernel module parameter. E.g.,</p>
|
||||
<pre class="screen">
|
||||
modprobe -r nvidia_drm ; modprobe nvidia_drm modeset=1
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>Applications can present through NVIDIA's DRM KMS implementation
|
||||
using any of the following:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>The DRM KMS "dumb buffer" mechanism to create and map
|
||||
CPU-accessible buffers: DRM_IOCTL_MODE_CREATE_DUMB,
|
||||
DRM_IOCTL_MODE_MAP_DUMB, and DRM_IOCTL_MODE_DESTROY_DUMB.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Using the EGL_EXT_device_drm, EGL_EXT_output_drm, and
|
||||
EGL_EXT_stream_consumer_egloutput EGL extensions to associate
|
||||
EGLStream producers with specific DRM KMS planes.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"drm-kms-known-issues" id="drm-kms-known-issues"></a>Known
|
||||
Issues</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>The NVIDIA DRM KMS implementation is currently incompatible with
|
||||
SLI Mosaic. The X server will fail to initialize SLI Mosaic if DRM
|
||||
KMS is enabled.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The NVIDIA DRM KMS implementation does not yet register an
|
||||
overlay plane: only primary and cursor planes are currently
|
||||
provided.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Buffer allocation and submission to DRM KMS using gbm is not
|
||||
currently supported.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"primerenderoffload.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"egpu.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 35. PRIME Render Offload </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 37. Configuring External and Removable
|
||||
GPUs</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,407 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 9. Known Issues</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="commonproblems.html" title=
|
||||
"Chapter 8. Common Problems">
|
||||
<link rel="next" href="dma_issues.html" title=
|
||||
"Chapter 10. Allocating DMA Buffers on 64-bit Platforms">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 9. Known
|
||||
Issues</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"commonproblems.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"dma_issues.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="knownissues" id=
|
||||
"knownissues"></a>Chapter 9. Known Issues</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>The following problems still exist in this release and are in
|
||||
the process of being resolved.</p>
|
||||
<div class="variablelist">
|
||||
<p class="title"><b>Known Issues</b></p>
|
||||
<dl>
|
||||
<dt><span class="term">Cache Aliasing</span></dt>
|
||||
<dd>
|
||||
<p>Cache aliasing occurs when multiple mappings to a physical page
|
||||
of memory have conflicting caching states, such as cached and
|
||||
uncached. Due to these conflicting states, data in that physical
|
||||
page may become corrupted when the processor's cache is flushed. If
|
||||
that page is being used for DMA by a driver such as NVIDIA's
|
||||
graphics driver, this can lead to hardware stability problems and
|
||||
system lockups.</p>
|
||||
<p>NVIDIA has encountered bugs with some Linux kernel versions that
|
||||
lead to cache aliasing. Although some systems will run perfectly
|
||||
fine when cache aliasing occurs, other systems will experience
|
||||
severe stability problems, including random lockups. Users
|
||||
experiencing stability problems due to cache aliasing will benefit
|
||||
from updating to a kernel that does not cause cache aliasing to
|
||||
occur.</p>
|
||||
</dd>
|
||||
<dt><span class="term">Valgrind</span></dt>
|
||||
<dd>
|
||||
<p>The NVIDIA OpenGL implementation makes use of self modifying
|
||||
code. To force Valgrind to retranslate this code after a
|
||||
modification you must run using the Valgrind command line
|
||||
option:</p>
|
||||
<pre class="screen">
|
||||
--smc-check=all
|
||||
</pre>
|
||||
<p>Without this option Valgrind may execute incorrect code causing
|
||||
incorrect behavior and reports of the form:</p>
|
||||
<pre class="screen">
|
||||
==30313== Invalid write of size 4
|
||||
</pre>
|
||||
<p></p>
|
||||
</dd>
|
||||
<dt><a name="msi_interrupts" id="msi_interrupts"></a><span class=
|
||||
"term">Driver fails to initialize when MSI interrupts are
|
||||
enabled</span></dt>
|
||||
<dd>
|
||||
<p>The Linux NVIDIA driver uses Message Signaled Interrupts (MSI)
|
||||
by default. This provides compatibility and scalability benefits,
|
||||
mainly due to the avoidance of IRQ sharing.</p>
|
||||
<p>Some systems have been seen to have problems supporting MSI,
|
||||
while working fine with virtual wire interrupts. These problems
|
||||
manifest as an inability to start X with the NVIDIA driver, or CUDA
|
||||
initialization failures. The NVIDIA driver will then report an
|
||||
error indicating that the NVIDIA kernel module does not appear to
|
||||
be receiving interrupts generated by the GPU.</p>
|
||||
<p>Problems have also been seen with suspend/resume while MSI is
|
||||
enabled. All known problems have been fixed, but if you observe
|
||||
problems with suspend/resume that you did not see with previous
|
||||
drivers, disabling MSI may help you.</p>
|
||||
<p>NVIDIA is working on a long-term solution to improve the
|
||||
driver's out of the box compatibility with system configurations
|
||||
that do not fully support MSI.</p>
|
||||
<p>MSI interrupts can be disabled via the NVIDIA kernel module
|
||||
parameter "NVreg_EnableMSI=0". This can be set on the command line
|
||||
when loading the module, or more appropriately via your
|
||||
distribution's kernel module configuration files (such as those
|
||||
under /etc/modprobe.d/).</p>
|
||||
</dd>
|
||||
<dt><a name="console_restore" id="console_restore"></a><span class=
|
||||
"term">Console restore behavior</span></dt>
|
||||
<dd>
|
||||
<p>The Linux NVIDIA driver uses the nvidia-modeset module for
|
||||
console restore whenever it can. Currently, the improved console
|
||||
restore mechanism is used on systems that boot with the UEFI
|
||||
Graphics Output Protocol driver, and on systems that use supported
|
||||
VESA linear graphical modes. Note that VGA text, color index,
|
||||
planar, banked, and some linear modes cannot be supported, and will
|
||||
use the older console restore method instead.</p>
|
||||
<p>When the new console restore mechanism is in use and the
|
||||
nvidia-modeset module is initialized (e.g. because an X server is
|
||||
running on a different VT, nvidia-persistenced is running, or the
|
||||
nvidia_drm module is loaded with the <code class=
|
||||
"computeroutput">modeset=1</code> parameter), then nvidia-modeset
|
||||
will respond to hot plug events by displaying the console on as
|
||||
many displays as it can. Note that to save power, it may not
|
||||
display the console on all connected displays.</p>
|
||||
</dd>
|
||||
<dt><a name="vulkan_devices" id="vulkan_devices"></a><span class=
|
||||
"term">Vulkan and device enumeration</span></dt>
|
||||
<dd>
|
||||
<p>Starting with the X.Org X server version 1.20.7, it is possible
|
||||
to enumerate all the NVIDIA devices in the system if the
|
||||
application is able to open a connection to the X server. However,
|
||||
such applications will only be able to create an Xlib or XCB
|
||||
swapchain on the device driving the X screen. Such a device can be
|
||||
identified by using the vkGetPhysicalDeviceSurfaceSupportKHR()
|
||||
API.</p>
|
||||
<p>Prior to the X.Org X server version 1.20.7, it is not possible
|
||||
to enumerate multiple devices if one of them will be used to
|
||||
present to an X11 swapchain. It is still possible to enumerate
|
||||
multiple devices even if one of them is driving an X screen, if the
|
||||
devices will be used for Vulkan offscreen rendering or presenting
|
||||
to a display swapchain. For that, make sure that the application
|
||||
cannot open a display connection to an X server by, for example,
|
||||
unsetting the DISPLAY environment variable.</p>
|
||||
</dd>
|
||||
<dt><a name="profiling" id="profiling"></a><span class=
|
||||
"term">Restricting access to GPU performance counters</span></dt>
|
||||
<dd>
|
||||
<p>NVIDIA Developer Tools allow developers to debug, profile, and
|
||||
develop software for NVIDIA GPUs. GPU performance counters are
|
||||
integral to these tools. By default, access to the GPU performance
|
||||
counters is restricted to root, and other users with the
|
||||
CAP_SYS_ADMIN capability, for security reasons. If developers
|
||||
require access to the NVIDIA Developer Tools, a system
|
||||
administrator can accept the security risk and allow access to
|
||||
users without the CAP_SYS_ADMIN capability.</p>
|
||||
<p>Wider access to GPU performance counters can be granted by
|
||||
setting the kernel module parameter
|
||||
"NVreg_RestrictProfilingToAdminUsers=0" in the nvidia.ko kernel
|
||||
module. This can be set on the command line when loading the
|
||||
module, or more appropriately via your distribution's kernel module
|
||||
configuration files (such as those under /etc/modprobe.d/).</p>
|
||||
</dd>
|
||||
<dt><a name="RedHat" id="RedHat"></a><span class="term">Driver
|
||||
fails to initialize with some versions of RHEL 8</span></dt>
|
||||
<dd>
|
||||
<p>Some versions of Red Hat Enterprise Linux 8 kernels have a bug
|
||||
that causes driver initialization to fail with an error such
|
||||
as:</p>
|
||||
<pre class="screen">
|
||||
NVRM: Xid (PCI:0000:09:00): 79, pid=2172, GPU has fallen off the bus.
|
||||
NVRM: GPU 0000:09:00.0: GPU has fallen off the bus.
|
||||
NVRM: GPU 0000:09:00.0: RmInitAdapter failed! (0x26:0x65:1239)
|
||||
NVRM: GPU 0000:09:00.0: rm_init_adapter failed, device minor number 0
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>See the Red Hat knowledge base article <a href=
|
||||
"https://access.redhat.com/solutions/5825061" target=
|
||||
"_top">https://access.redhat.com/solutions/5825061</a> to find the
|
||||
specific affected and fixed kernel versions.</p>
|
||||
</dd>
|
||||
<dt><a name="IBT" id="IBT"></a><span class="term">Driver fails to
|
||||
load on Linux kernel versions 5.18 through 5.18.19 with
|
||||
CONFIG_X86_KERNEL_IBT enabled</span></dt>
|
||||
<dd>
|
||||
<p>The NVIDIA driver fails to load on IBT (Indirect Branch
|
||||
Tracking) supported CPUs running Linux kernel versions 5.18 to
|
||||
5.18.19, when IBT is enabled, with the following error:</p>
|
||||
<pre class="screen">
|
||||
error "traps: Missing ENDBR:"
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>This issue is not seen with Linux kernels having the following
|
||||
commit:</p>
|
||||
<pre class="screen">
|
||||
commit 3c6f9f77e618 (objtool: Rework ibt and extricate from stack validation)
|
||||
</pre>
|
||||
<p>The aforementioned commit is available in Linux kernel versions
|
||||
5.19 and later. The NVIDIA driver's IBT support works with Linux
|
||||
kernels containing commit 3c6f9f77e618 (5.19 and later). Please use
|
||||
the kernel boot parameter "ibt=off" as a workaround on kernels
|
||||
without that commit.</p>
|
||||
</dd>
|
||||
<dt><span class="term">Notebooks</span></dt>
|
||||
<dd>
|
||||
<p>If you are using a notebook see the "Known Notebook Issues" in
|
||||
<a href="configlaptop.html" title=
|
||||
"Chapter 16. Configuring a Notebook">Chapter 16,
|
||||
<i>Configuring a Notebook</i></a>.</p>
|
||||
</dd>
|
||||
<dt><a name="texture_clamping" id=
|
||||
"texture_clamping"></a><span class="term">Texture seams in Quake 3
|
||||
engine</span></dt>
|
||||
<dd>
|
||||
<p>Many games based on the Quake 3 engine set their textures to use
|
||||
the <code class="computeroutput">GL_CLAMP</code> clamping mode when
|
||||
they should be using <code class=
|
||||
"computeroutput">GL_CLAMP_TO_EDGE</code>. This was an oversight
|
||||
made by the developers because some legacy NVIDIA GPUs treat the
|
||||
two modes as equivalent. The result is seams at the edges of
|
||||
textures in these games. To mitigate this, older versions of the
|
||||
NVIDIA display driver remap <code class=
|
||||
"computeroutput">GL_CLAMP</code> to <code class=
|
||||
"computeroutput">GL_CLAMP_TO_EDGE</code> internally to emulate the
|
||||
behavior of the older GPUs, but this workaround has been disabled
|
||||
by default. To re-enable it, uncheck the "Use Conformant Texture
|
||||
Clamping" checkbox in nvidia-settings before starting any affected
|
||||
applications.</p>
|
||||
</dd>
|
||||
<dt><span class="term">FSAA</span></dt>
|
||||
<dd>
|
||||
<p>When FSAA is enabled (the __GL_FSAA_MODE environment variable is
|
||||
set to a value that enables FSAA and a multisample visual is
|
||||
chosen), the rendering may be corrupted when resizing the
|
||||
window.</p>
|
||||
</dd>
|
||||
<dt><span class="term">libGL DSO finalizer and pthreads</span></dt>
|
||||
<dd>
|
||||
<p>When a multithreaded OpenGL application exits, it is possible
|
||||
for libGL's DSO finalizer (also known as the destructor, or
|
||||
"_fini") to be called while other threads are executing OpenGL
|
||||
code. The finalizer needs to free resources allocated by libGL.
|
||||
This can cause problems for threads that are still using these
|
||||
resources. Setting the environment variable "__GL_NO_DSO_FINALIZER"
|
||||
to "1" will work around this problem by forcing libGL's finalizer
|
||||
to leave its resources in place. These resources will still be
|
||||
reclaimed by the operating system when the process exits. Note that
|
||||
the finalizer is also executed as part of dlclose(3), so if you
|
||||
have an application that dlopens(3) and dlcloses(3) libGL
|
||||
repeatedly, "__GL_NO_DSO_FINALIZER" will cause libGL to leak
|
||||
resources until the process exits. Using this option can improve
|
||||
stability in some multithreaded applications, including Java3D
|
||||
applications.</p>
|
||||
</dd>
|
||||
<dt><span class="term">Thread cancellation</span></dt>
|
||||
<dd>
|
||||
<p>Canceling a thread (see pthread_cancel(3)) while it is executing
|
||||
in the OpenGL driver causes undefined behavior. For applications
|
||||
that wish to use thread cancellation, it is recommended that
|
||||
threads disable cancellation using pthread_setcancelstate(3) while
|
||||
executing OpenGL or GLX commands.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
</div>
|
||||
<p>This section describes problems that will not be fixed. Usually,
|
||||
the source of the problem is beyond the control of NVIDIA.
|
||||
Following is the list of problems:</p>
|
||||
<div class="variablelist">
|
||||
<p class="title"><b>Problems that Will Not Be Fixed</b></p>
|
||||
<dl>
|
||||
<dt><span class="term">NV-CONTROL versions 1.8 and 1.9</span></dt>
|
||||
<dd>
|
||||
<p>Version 1.8 of the NV-CONTROL X Extension introduced target
|
||||
types for setting and querying attributes as well as receiving
|
||||
event notification on targets. Targets are objects like X Screens,
|
||||
GPUs and Quadro Sync devices. Previously, all attributes were
|
||||
described relative to an X Screen. These new bits of information
|
||||
(target type and target id) were packed in a non-compatible way in
|
||||
the protocol stream such that addressing X Screen 1 or higher would
|
||||
generate an X protocol error when mixing NV-CONTROL client and
|
||||
server versions.</p>
|
||||
<p>This packing problem has been fixed in the NV-CONTROL 1.10
|
||||
protocol, making it possible for the older (1.7 and prior) clients
|
||||
to communicate with NV-CONTROL 1.10 servers. Furthermore, the
|
||||
NV-CONTROL 1.10 client library has been updated to accommodate the
|
||||
target protocol packing bug when communicating with a 1.8 or 1.9
|
||||
NV-CONTROL server. This means that the NV-CONTROL 1.10 client
|
||||
library should be able to communicate with any version of the
|
||||
NV-CONTROL server.</p>
|
||||
<p>NVIDIA recommends that NV-CONTROL client applications relink
|
||||
with version 1.10 or later of the NV-CONTROL client library
|
||||
(libXNVCtrl.a, in the nvidia-settings-535.161.07.tar.bz2 tarball).
|
||||
The version of the client library can be determined by checking the
|
||||
NV_CONTROL_MAJOR and NV_CONTROL_MINOR definitions in the
|
||||
accompanying nv_control.h.</p>
|
||||
<p>The only web released NVIDIA Linux driver that is affected by
|
||||
this problem (i.e., the only driver to use either version 1.8 or
|
||||
1.9 of the NV-CONTROL X extension) is 1.0-8756.</p>
|
||||
</dd>
|
||||
<dt><span class="term">CPU throttling reducing memory bandwidth on
|
||||
IGP systems</span></dt>
|
||||
<dd>
|
||||
<p>For some models of CPU, the CPU throttling technology may affect
|
||||
not only CPU core frequency, but also memory frequency/bandwidth.
|
||||
On systems using integrated graphics, any reduction in memory
|
||||
bandwidth will affect the GPU as well as the CPU. This can
|
||||
negatively affect applications that use significant memory
|
||||
bandwidth, such as video decoding using VDPAU, or certain OpenGL
|
||||
operations. This may cause such applications to run with lower
|
||||
performance than desired.</p>
|
||||
<p>To work around this problem, NVIDIA recommends configuring your
|
||||
CPU throttling implementation to avoid reducing memory bandwidth.
|
||||
This may be as simple as setting a certain minimum frequency for
|
||||
the CPU.</p>
|
||||
<p>Depending on your operating system and/or distribution, this may
|
||||
be as simple as writing to a configuration file in the /sys or
|
||||
/proc filesystems, or other system configuration file. Please read,
|
||||
or search the Internet for, documentation regarding CPU throttling
|
||||
on your operating system.</p>
|
||||
</dd>
|
||||
<dt><span class="term">VDPAU initialization failures on supported
|
||||
GPUs</span></dt>
|
||||
<dd>
|
||||
<p>If VDPAU gives the VDP_STATUS_NO_IMPLEMENTATION error message on
|
||||
a GPU which was labeled or specified as supporting PureVideo or
|
||||
PureVideo HD, one possible reason is a hardware defect. After
|
||||
ruling out any other software problems, NVIDIA recommends returning
|
||||
the GPU to the manufacturer for a replacement.</p>
|
||||
</dd>
|
||||
<dt><a name="extension_string_size" id=
|
||||
"extension_string_size"></a><span class="term">Some applications,
|
||||
such as Quake 3, crash after querying the OpenGL extension
|
||||
string</span></dt>
|
||||
<dd>
|
||||
<p>Some applications have bugs that are triggered when the
|
||||
extension string is longer than a certain size. As more features
|
||||
are added to the driver, the length of this string increases and
|
||||
can trigger these sorts of bugs.</p>
|
||||
<p>You can limit the extensions listed in the OpenGL extension
|
||||
string to the ones that appeared in a particular version of the
|
||||
driver by setting the <code class=
|
||||
"computeroutput">__GL_ExtensionStringVersion</code> environment
|
||||
variable to a particular version number. For example,</p>
|
||||
<pre class="screen">
|
||||
__GL_ExtensionStringVersion=17700 quake3
|
||||
</pre>
|
||||
<p>will run Quake 3 with the extension string that appeared in the
|
||||
177.* driver series. Limiting the size of the extension string can
|
||||
work around this sort of application bug.</p>
|
||||
</dd>
|
||||
<dt><a name="gnome_shell_doesnt_update" id=
|
||||
"gnome_shell_doesnt_update"></a><span class="term">gnome-shell
|
||||
doesn't update until a window is moved</span></dt>
|
||||
<dd>
|
||||
<p>Versions of libcogl prior to 1.10.x have a bug which causes
|
||||
glBlitFramebuffer() calls used to update the window to be clipped
|
||||
by a 0x0 scissor (see <a href=
|
||||
"https://bugzilla.gnome.org/show_bug.cgi?id=690451" target=
|
||||
"_top">GNOME bug #690451</a> for more details). To work around this
|
||||
bug, the scissor test can be disabled by setting the <code class=
|
||||
"computeroutput">__GL_ConformantBlitFramebufferScissor</code>
|
||||
environment variable to 0. Note this version of the NVIDIA driver
|
||||
comes with an application profile which automatically disables this
|
||||
test if libcogl is detected in the process.</p>
|
||||
</dd>
|
||||
<dt><a name="Xserver_compares_only_the_matrix_part_of_a_transform"
|
||||
id=
|
||||
"Xserver_compares_only_the_matrix_part_of_a_transform"></a><span class="term">Some
|
||||
X servers ignore the RandR transform filter during a modeset
|
||||
request</span></dt>
|
||||
<dd>
|
||||
<p>The RandR layer of the X server attempts to ignore redundant
|
||||
RRSetCrtcConfig requests. If the only property changed by an
|
||||
RRSetCrtcConfig request is the transform filter, some X servers
|
||||
will ignore the request as redundant. This can be worked around by
|
||||
also changing other properties, such as the mode, transformation
|
||||
matrix, etc.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
</div>
|
||||
<p></p>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"commonproblems.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"dma_issues.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 8. Common Problems </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 10. Allocating DMA Buffers on 64-bit
|
||||
Platforms</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,209 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 2. Minimum Requirements</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="introduction.html" title=
|
||||
"Chapter 1. Introduction">
|
||||
<link rel="next" href="selectdriver.html" title=
|
||||
"Chapter 3. Selecting and Downloading the NVIDIA Packages for Your System">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 2. Minimum
|
||||
Requirements</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"introduction.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"selectdriver.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="minimumrequirements" id=
|
||||
"minimumrequirements"></a>Chapter 2. Minimum
|
||||
Requirements</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="toc">
|
||||
<p><b>Table of Contents</b></p>
|
||||
<dl>
|
||||
<dt><span class="section"><a href=
|
||||
"minimumrequirements.html#MinimumSoftware2486a">Minimum Software
|
||||
Requirements</a></span></dt>
|
||||
</dl>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"MinimumSoftware2486a" id="MinimumSoftware2486a"></a>Minimum
|
||||
Software Requirements</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p></p>
|
||||
<div class="informaltable">
|
||||
<table summary="(no summary available)" border="0">
|
||||
<colgroup>
|
||||
<col>
|
||||
<col>
|
||||
<col></colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Software Element</th>
|
||||
<th>Supported versions</th>
|
||||
<th>Check With...</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Linux kernel</td>
|
||||
<td>3.10 and newer</td>
|
||||
<td><strong class="userinput"><code>cat
|
||||
/proc/version</code></strong></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>X.Org xserver</td>
|
||||
<td>1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.17,
|
||||
1.18, 1.19, 1.20, 21.1</td>
|
||||
<td><strong class="userinput"><code>Xorg
|
||||
-version</code></strong></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Kernel modutils</td>
|
||||
<td>2.1.121 and newer</td>
|
||||
<td><strong class="userinput"><code>insmod
|
||||
--version</code></strong></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>glibc</td>
|
||||
<td><a name="glibc" id="glibc"></a> 2.11</td>
|
||||
<td><strong class=
|
||||
"userinput"><code>/lib/libc.so.6</code></strong></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>libvdpau *</td>
|
||||
<td>0.2</td>
|
||||
<td><strong class="userinput"><code>pkg-config --modversion
|
||||
vdpau</code></strong></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>libvulkan **</td>
|
||||
<td>1.0.61</td>
|
||||
<td><strong class="userinput"><code>pkg-config --modversion
|
||||
vulkan</code></strong></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<p></p>
|
||||
<p>* Required for hardware-accelerated video playback. See <a href=
|
||||
"vdpausupport.html" title=
|
||||
"Appendix G. VDPAU Support">Appendix G, <i>VDPAU
|
||||
Support</i></a> for more information.</p>
|
||||
<p>** Required for applications which use the Vulkan API.</p>
|
||||
<p>If you need to build the NVIDIA kernel module:</p>
|
||||
<div class="informaltable">
|
||||
<table summary="(no summary available)" border="0">
|
||||
<colgroup>
|
||||
<col>
|
||||
<col>
|
||||
<col></colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Software Element</th>
|
||||
<th>Min Requirement</th>
|
||||
<th>Check With...</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>binutils</td>
|
||||
<td>2.9.5</td>
|
||||
<td><strong class="userinput"><code>size
|
||||
--version</code></strong></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>GNU make</td>
|
||||
<td>3.77</td>
|
||||
<td><strong class="userinput"><code>make
|
||||
--version</code></strong></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>gcc</td>
|
||||
<td>2.91.66</td>
|
||||
<td><strong class="userinput"><code>gcc
|
||||
--version</code></strong></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<p></p>
|
||||
<p>All official stable kernel releases from 3.10 and up are
|
||||
supported; pre-release versions, such as 4.19-rc1, are not
|
||||
supported. The Linux kernel can be downloaded from <a href=
|
||||
"http://www.kernel.org" target="_top">http://www.kernel.org</a> or
|
||||
one of its mirrors.</p>
|
||||
<p>binutils and gcc can be retrieved from <a href=
|
||||
"http://www.gnu.org" target="_top">http://www.gnu.org</a> or one of
|
||||
its mirrors.</p>
|
||||
<p>Sometimes very recent X server versions are not supported
|
||||
immediately following release, but we aim to support all new
|
||||
versions as soon as possible. Support is not added for new X server
|
||||
versions until after the video driver ABI is frozen, which usually
|
||||
happens at the release candidate stage. Prerelease versions that
|
||||
are not release candidates, such as "1.10.99.1", are not
|
||||
supported.</p>
|
||||
<p>If you are setting up the X Window System for the first time, it
|
||||
is often easier to begin with one of the open source drivers that
|
||||
ships with X.Org (either "vga", "vesa", or "fbdev"). Once your
|
||||
system is operating properly with the open source driver, you may
|
||||
then switch to the NVIDIA driver.</p>
|
||||
<p>These software packages may also be available through your Linux
|
||||
distributor.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"introduction.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"selectdriver.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 1. Introduction </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 3. Selecting and Downloading the NVIDIA
|
||||
Packages for Your System</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,428 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Appendix I. Tips for New Linux Users</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="appendices.html" title=
|
||||
"Part II. Appendices">
|
||||
<link rel="prev" href="audiosupport.html" title=
|
||||
"Appendix H. Audio Support">
|
||||
<link rel="next" href="profiles.html" title=
|
||||
"Appendix J. Application Profiles">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Appendix I. Tips for New
|
||||
Linux Users</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"audiosupport.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part II. Appendices</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"profiles.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="appendix" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="newusertips" id=
|
||||
"newusertips"></a>Appendix I. Tips for New Linux
|
||||
Users</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>This installation guide assumes that the user has at least a
|
||||
basic understanding of Linux 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 Linux Driver, it is by no means a
|
||||
tutorial on the use or administration of the Linux operating
|
||||
system. Unlike many desktop operating systems, it is relatively
|
||||
easy to cause irreparable damage to your Linux system. If you are
|
||||
unfamiliar with the use of Linux, we strongly recommend that you
|
||||
seek a tutorial through your distributor before proceeding.</p>
|
||||
<h3>The command prompt</h3>
|
||||
<p>While newer releases of Linux bring new desktop interfaces to
|
||||
the user, much of the work in Linux takes place at the command
|
||||
prompt. If you are familiar with the Windows operating system, the
|
||||
Linux 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 <code class="prompt">#</code>, <code class=
|
||||
"prompt">$</code>, or <code class="prompt">%</code>, and a cursor
|
||||
(possibly flashing) that indicates where the user's input will be
|
||||
displayed.</p>
|
||||
<h3>Navigating the directory structure</h3>
|
||||
<p>Linux has a hierarchical directory structure. From anywhere in
|
||||
the directory structure, the <span><strong class=
|
||||
"command">ls</strong></span> command will list the contents of that
|
||||
directory. The <span><strong class="command">file</strong></span>
|
||||
command will print the type of files in a directory. For
|
||||
example,</p>
|
||||
<pre class="screen">
|
||||
% file filename
|
||||
</pre>
|
||||
<p>will print the type of the file <code class=
|
||||
"filename">filename</code>. Changing directories is done with the
|
||||
<span><strong class="command">cd</strong></span> command.</p>
|
||||
<pre class="screen">
|
||||
% cd dirname
|
||||
</pre>
|
||||
<p>will change the current directory to <code class=
|
||||
"filename">dirname</code>. From anywhere in the directory
|
||||
structure, the command <span><strong class=
|
||||
"command">pwd</strong></span> will print the name of the current
|
||||
directory. There are two special directories, <code class=
|
||||
"filename">.</code> and <code class="filename">..</code>, 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 <code class=
|
||||
"filename">.</code> or <code class="filename">..</code>. Elements
|
||||
of a path are separated with the "/" character. As an example, if
|
||||
the current directory is <code class="filename">/home/jesse</code>
|
||||
and the user wants to change to the <code class=
|
||||
"filename">/usr/local</code> directory, he can use either of the
|
||||
following commands to do so:</p>
|
||||
<pre class="screen">
|
||||
% cd /usr/local
|
||||
</pre>
|
||||
<p>or</p>
|
||||
<pre class="screen">
|
||||
% cd ../../usr/local
|
||||
</pre>
|
||||
<p></p>
|
||||
<h3>File permissions and ownership</h3>
|
||||
<p>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 <code class=
|
||||
"option">-l</code> option to the <span><strong class=
|
||||
"command">ls</strong></span> command. For example:</p>
|
||||
<pre class="screen">
|
||||
% 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
|
||||
%
|
||||
</pre>
|
||||
<p>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.</p>
|
||||
<p>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 (<code class="systemitem">jesse</code> 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 <code class=
|
||||
"systemitem">r</code>, <code class="systemitem">w</code>, and
|
||||
<code class="systemitem">x</code> indicate read, write and execute
|
||||
permissions, respectively, for each of these associations. For
|
||||
example, user <code class="systemitem">jesse</code> has read and
|
||||
write permissions for <code class="filename">testfile</code>, users
|
||||
in the group <code class="systemitem">users</code> have read
|
||||
permission only, and the rest of the world also has read
|
||||
permissions only. However, for the file <code class=
|
||||
"filename">myprogram</code>, user <code class=
|
||||
"systemitem">jesse</code> has read, write and execute permissions
|
||||
(suggesting that <code class="filename">myprogram</code> is a
|
||||
program that can be executed), while the group <code class=
|
||||
"systemitem">users</code> 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
|
||||
<span><strong class="command">chmod</strong></span>,
|
||||
<span><strong class="command">chown</strong></span> and
|
||||
<span><strong class="command">chgrp</strong></span>, respectively.
|
||||
If a user with the appropriate permissions wanted to change the
|
||||
user/group ownership of <code class="filename">README</code> from
|
||||
jesse/users to joe/admin, he would do the following:</p>
|
||||
<pre class="screen">
|
||||
# chown joe README
|
||||
# chgrp admin README
|
||||
</pre>
|
||||
<p>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:</p>
|
||||
<pre class="screen">
|
||||
% chmod 750 myprogram
|
||||
</pre>
|
||||
<p></p>
|
||||
<h3>The shell</h3>
|
||||
<p>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 Linux stem from the
|
||||
Bourne shell (<span><strong class="command">sh</strong></span>) and
|
||||
the C-shell (<span><strong class="command">csh</strong></span>)
|
||||
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 <code class=
|
||||
"envar">SHELL</code> environment variable from the command prompt
|
||||
with</p>
|
||||
<pre class="screen">
|
||||
% echo $SHELL
|
||||
</pre>
|
||||
<p>You can start a new shell simply by entering the name of the
|
||||
shell from the command prompt:</p>
|
||||
<pre class="screen">
|
||||
% csh
|
||||
</pre>
|
||||
<p>or</p>
|
||||
<pre class="screen">
|
||||
% sh
|
||||
</pre>
|
||||
<p>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:</p>
|
||||
<pre class="screen">
|
||||
% sh myprogram
|
||||
</pre>
|
||||
<p>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.</p>
|
||||
<h3>Setting environment variables</h3>
|
||||
<p>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 <code class="envar">PATH</code>
|
||||
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 <code class="envar">PATH</code>
|
||||
variable. Environment variables are set differently depending on
|
||||
the shell being used. For the Bourne shell (<span><strong class=
|
||||
"command">sh</strong></span>), it is done as:</p>
|
||||
<pre class="screen">
|
||||
% export MYVARIABLE="avalue"
|
||||
</pre>
|
||||
<p>for the C-shell, it is done as:</p>
|
||||
<pre class="screen">
|
||||
% setenv MYVARIABLE "avalue"
|
||||
</pre>
|
||||
<p>In both cases the quotation marks are only necessary if the
|
||||
value contains spaces. The <span><strong class=
|
||||
"command">echo</strong></span> command can be used to examine the
|
||||
value of an environment variable:</p>
|
||||
<pre class="screen">
|
||||
% echo $MYVARIABLE
|
||||
</pre>
|
||||
<p>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
|
||||
<code class="filename">/usr/local/bin</code> to the beginning of
|
||||
the search path, and the current directory <code class=
|
||||
"filename">.</code> to the end of the search path, a user would
|
||||
enter</p>
|
||||
<pre class="screen">
|
||||
% export PATH=/usr/local/bin:$PATH:.
|
||||
</pre>
|
||||
<p>in the Bourne shell, and</p>
|
||||
<pre class="screen">
|
||||
% setenv PATH /usr/local/bin:${PATH}:.
|
||||
</pre>
|
||||
<p>in C-shell. Note the curly braces are required to protect the
|
||||
variable name in C-shell.</p>
|
||||
<h3>Editing text files</h3>
|
||||
<p>There are several text editors available for the Linux 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
|
||||
<span><strong class="command">vi</strong></span>,
|
||||
<span><strong class="command">pico</strong></span> and
|
||||
<span><strong class="command">emacs</strong></span>, each of which
|
||||
can be started from the command line, optionally supplying the name
|
||||
of a file to be edited. <span><strong class=
|
||||
"command">vi</strong></span> is arguably the most ubiquitous as
|
||||
well as the least intuitive of the three. <span><strong class=
|
||||
"command">pico</strong></span> is relatively straightforward for a
|
||||
new user, though not as often installed on systems. If you don't
|
||||
have <span><strong class="command">pico</strong></span>, you may
|
||||
have a similar editor called <span><strong class=
|
||||
"command">nano</strong></span>. <span><strong class=
|
||||
"command">emacs</strong></span> 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 Linux Manual and Info pages). Many programs use
|
||||
the <code class="envar">EDITOR</code> environment variable to
|
||||
determine which text editor to start when editing is required.</p>
|
||||
<h3>Root user</h3>
|
||||
<p>Upon installation, almost all distributions set up the default
|
||||
administrative user with the username <code class=
|
||||
"systemitem">root</code>. There are many things on the system that
|
||||
only <code class="systemitem">root</code> (or a similarly
|
||||
privileged user) can do, one of which is installing the NVIDIA
|
||||
Linux Driver. <span class="emphasis"><em>We must emphasize that
|
||||
assuming the identity of <code class="systemitem">root</code> is
|
||||
inherently risky and as <code class="systemitem">root</code> it is
|
||||
relatively easy to corrupt your system or otherwise render it
|
||||
unusable.</em></span> There are three ways to become <code class=
|
||||
"systemitem">root</code>. You may log in as <code class=
|
||||
"systemitem">root</code> as you would any other user, you may use
|
||||
the switch user command (<span><strong class=
|
||||
"command">su</strong></span>) at the command prompt, or, on some
|
||||
systems, use the <span><strong class="command">sudo</strong></span>
|
||||
utility, which allows users to run programs as <code class=
|
||||
"systemitem">root</code> 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
|
||||
<code class="systemitem">root</code> only as long as is necessary
|
||||
to accomplish the task requiring <code class=
|
||||
"systemitem">root</code> privileges (another useful feature of the
|
||||
<span><strong class="command">sudo</strong></span> utility).</p>
|
||||
<h3>Booting to a different runlevel</h3>
|
||||
<p>Runlevels in Linux dictate which services are started and
|
||||
stopped automatically when the system boots or shuts down. The
|
||||
runlevels typically range from 0 to 6, with runlevel 5 typically
|
||||
starting the X window system as part of the services (runlevel 0 is
|
||||
actually a system halt, and 6 is a system reboot). It is good
|
||||
practice to install the NVIDIA Linux Driver while X is not running,
|
||||
and it is a good idea to prevent X from starting on reboot in case
|
||||
there are problems with the installation (otherwise you may find
|
||||
yourself with a broken system that automatically tries to start X,
|
||||
but then hangs during the startup, preventing you from doing the
|
||||
repairs necessary to fix X). Depending on your network setup,
|
||||
runlevels 1, 2 or 3 should be sufficient for installing the Driver.
|
||||
Level 3 typically includes networking services, so if utilities
|
||||
used by the system during installation depend on a remote
|
||||
filesystem, Levels 1 and 2 will be insufficient. If your system
|
||||
typically boots to a console with a command prompt, you should not
|
||||
need to change anything. If your system typically boots to the X
|
||||
window system with a graphical login and desktop, you must both
|
||||
exit X and change your default runlevel.</p>
|
||||
<p>On most distributions, the default runlevel is stored in the
|
||||
file <code class="filename">/etc/inittab</code>, although you may
|
||||
have to consult the guide for your own distribution. The line that
|
||||
indicates the default runlevel appears as</p>
|
||||
<pre class="screen">
|
||||
id:n:initdefault:
|
||||
</pre>
|
||||
<p>or similar, where <code class="computeroutput">n</code>
|
||||
indicates the number of the runlevel. <code class=
|
||||
"filename">/etc/inittab</code> must be edited as root. Please read
|
||||
the sections on editing files and root user if you are unfamiliar
|
||||
with this concept. Also, it is recommended that you create a copy
|
||||
of the file prior to editing it, particularly if you are new to
|
||||
Linux text editors, in case you accidentally corrupt the file:</p>
|
||||
<pre class="screen">
|
||||
# cp /etc/inittab /etc/inittab.original
|
||||
</pre>
|
||||
<p>The line should be edited such that an appropriate runlevel is
|
||||
the default (1, 2, or 3 on most systems):</p>
|
||||
<pre class="screen">
|
||||
id:3:initdefault:
|
||||
</pre>
|
||||
<p>After saving the changes, exit X. After the Driver installation
|
||||
is complete, you may revert the default runlevel to its original
|
||||
state, either by editing the <code class=
|
||||
"filename">/etc/inittab</code> again or by moving your backup copy
|
||||
back to its original name.</p>
|
||||
<p>Different distributions provide different ways to exit X. On
|
||||
many systems, the <span><strong class=
|
||||
"command">init</strong></span> utility will change the current
|
||||
runlevel. This can be used to change to a runlevel in which X is
|
||||
not running.</p>
|
||||
<pre class="screen">
|
||||
# init 3
|
||||
</pre>
|
||||
<p>There are other methods by which to exit X. Please consult your
|
||||
distribution.</p>
|
||||
<h3>Linux Manual and Info pages</h3>
|
||||
<p>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
|
||||
<code class="option">--help</code> option, which usually prints a
|
||||
list of common options for that program. To view the manual page
|
||||
for a command, enter</p>
|
||||
<pre class="screen">
|
||||
% man commandname
|
||||
</pre>
|
||||
<p>at the command prompt, where <code class=
|
||||
"option">commandname</code> refers to the command in which you are
|
||||
interested. Similarly, entering</p>
|
||||
<pre class="screen">
|
||||
% info commandname
|
||||
</pre>
|
||||
<p>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 <code class=
|
||||
"envar">MANPATH</code> environment variable. See the section on
|
||||
environment variables.</p>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"audiosupport.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"appendices.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"profiles.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Appendix H. Audio Support </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Appendix J. Application Profiles</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,178 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 38. NGX</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="egpu.html" title=
|
||||
"Chapter 37. Configuring External and Removable GPUs">
|
||||
<link rel="next" href="xwayland.html" title=
|
||||
"Chapter 39. OpenGL and Vulkan on Xwayland">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 38. NGX</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"egpu.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"xwayland.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="ngx" id=
|
||||
"ngx"></a>Chapter 38. NGX</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>NGX is a framework allowing for easy and consistent integration
|
||||
of Deep Learning features into applications. There are three
|
||||
components shipped with the driver that comprise NGX:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>NGX Core: The interface used by applications to communicate with
|
||||
NGX features.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>NGX Updater: A program optionally launched by NGX Core which
|
||||
downloads updated versions of NGX features.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>NGX Core for Proton: A copy of NGX Core built as a DLL for use
|
||||
with Proton.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
<h3>Configuring the NGX Updater:</h3>
|
||||
<p>NGX Configuration file search order:</p>
|
||||
<div class="orderedlist">
|
||||
<ol type="1">
|
||||
<li>
|
||||
<p>Path supplied via <code class=
|
||||
"computeroutput">__NGX_CONF_FILE</code> environment variable. Note:
|
||||
if the application's effective UID/GID does not match its actual
|
||||
UID/GID (if the SETUID sticky bit is set), the location specified
|
||||
here will not be searched.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p><code class=
|
||||
"computeroutput">${XDG_CONFIG_HOME}/nvidia-ngx-conf.json</code>.
|
||||
Note: if the application's effective UID/GID does not match its
|
||||
actual UID/GID (if the SETUID sticky bit is set), the location
|
||||
specified here will not be searched.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p><code class=
|
||||
"computeroutput">/usr/share/nvidia/nvidia-ngx-conf.json</code></p>
|
||||
</li>
|
||||
</ol>
|
||||
</div>
|
||||
<p></p>
|
||||
<p>JSON Config Options:</p>
|
||||
<div class="informaltable">
|
||||
<table summary="(no summary available)" border="1">
|
||||
<colgroup>
|
||||
<col>
|
||||
<col>
|
||||
<col></colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Key</th>
|
||||
<th>Description</th>
|
||||
<th>Example</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><code class="computeroutput">file_format_version</code></td>
|
||||
<td>The version of the config file in the following format
|
||||
"major.minor.patch". Values should be of type <code class=
|
||||
"computeroutput">string</code>.</td>
|
||||
<td><code class="computeroutput">1.0.0</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code class="computeroutput">ngx_models_path</code></td>
|
||||
<td>The absolute path to the NGX models directory. The NGX Updater
|
||||
will save files here to later be read by applications which make
|
||||
use of NGX functionality. Values should be of type <code class=
|
||||
"computeroutput">string</code>.</td>
|
||||
<td><code class="computeroutput">/usr/share/nvidia/ngx</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code class="computeroutput">allow_ngx_updater</code></td>
|
||||
<td>A boolean value which enables the NGX Updater functionality on
|
||||
a system, defaulting to false if non-existent. Values should be of
|
||||
type <code class="computeroutput">boolean</code>.</td>
|
||||
<td><code class="computeroutput">false</code></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<p></p>
|
||||
<p>For systems that have multiple user accounts who may run
|
||||
applications which make use of NGX, it may be preferable to choose
|
||||
a ngx_models_path which is in a shared directory. If a shared
|
||||
directory is chosen it is important that the NGX Updater has
|
||||
permissions to write into it, this can be attained either through
|
||||
use of setuid/setgid sticky bit, or by altering the directories
|
||||
permissions accordingly.</p>
|
||||
<h3>Configuring the NGX Signed Load Mechanism:</h3>
|
||||
<p>The NGX Core component of the driver performs a signature check
|
||||
when loading NGX features. This check can be disabled by setting
|
||||
the <code class="computeroutput">__NV_SIGNED_LOAD_CHECK</code>
|
||||
environment variable to a value of <code class=
|
||||
"computeroutput">none</code>. Values other than <code class=
|
||||
"computeroutput">none</code> will be ignored. By default this check
|
||||
is enabled to prevent loading of potentially malicious non-NVIDIA
|
||||
provided NGX features. This check should only be disabled when
|
||||
there is confidence that only authentic NGX features are available
|
||||
on the current system.</p>
|
||||
<h3>Configuring the NGX Updater for Wine/Proton:</h3>
|
||||
<p>The NGX Updater for Wine/Proton can be enabled by setting the
|
||||
<code class="computeroutput">PROTON_ENABLE_NGX_UPDATER</code>
|
||||
environment variable to a value of <code class=
|
||||
"computeroutput">1</code>. Values other than <code class=
|
||||
"computeroutput">1</code> will be ignored.</p>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"egpu.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"xwayland.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 37. Configuring External and Removable
|
||||
GPUs </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 39. OpenGL and Vulkan on Xwayland</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,89 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 29. Using the nvidia-debugdump
|
||||
Utility</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="nvidia-ml.html" title=
|
||||
"Chapter 28. The NVIDIA Management Library">
|
||||
<link rel="next" href="nvidia-persistenced.html" title=
|
||||
"Chapter 30. Using the nvidia-persistenced Utility">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 29. Using the
|
||||
nvidia-debugdump Utility</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"nvidia-ml.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"nvidia-persistenced.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="nvidia-debugdump" id=
|
||||
"nvidia-debugdump"></a>Chapter 29. Using the
|
||||
nvidia-debugdump Utility</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>A utility for collecting internal GPU state,
|
||||
<span><strong class="command">nvidia-debugdump</strong></span>, is
|
||||
included with the NVIDIA Linux graphics driver. After installing
|
||||
the driver, you can run this utility by running:</p>
|
||||
<pre class="screen">
|
||||
% nvidia-debugdump
|
||||
</pre>
|
||||
<p>in a terminal window.</p>
|
||||
<p>Detailed help information is available via the --help command
|
||||
line option, or when no parameters are supplied.</p>
|
||||
<p>In most cases, this utility is invoked by the
|
||||
<span><strong class="command">nvidia-bug-report.sh</strong></span>
|
||||
(/usr/bin/nvidia-bug-report.sh) script. In rare cases, typically
|
||||
when directed by an NVIDIA technical support representative,
|
||||
nvidia-debugdump may also be invoked as a stand-alone diagnostics
|
||||
program. The "dump" output of nvidia-debugdump is a binary blob
|
||||
that requires internal NVIDIA engineering tools in order to be
|
||||
interpreted.</p>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"nvidia-ml.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"nvidia-persistenced.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">Chapter 28. The
|
||||
NVIDIA Management Library </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 30. Using the nvidia-persistenced
|
||||
Utility</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,84 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 28. The NVIDIA Management Library</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="nvidia-smi.html" title=
|
||||
"Chapter 27. Using the nvidia-smi Utility">
|
||||
<link rel="next" href="nvidia-debugdump.html" title=
|
||||
"Chapter 29. Using the nvidia-debugdump Utility">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 28. The NVIDIA
|
||||
Management Library</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"nvidia-smi.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"nvidia-debugdump.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="nvidia-ml" id=
|
||||
"nvidia-ml"></a>Chapter 28. The NVIDIA Management
|
||||
Library</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>A C-based API for monitoring and managing various states of the
|
||||
NVIDIA GPU devices. NVIDIA Management Library (NVML) provides a
|
||||
direct access to the queries and commands exposed via nvidia-smi.
|
||||
NVML is included with the NVIDIA Linux graphics driver.</p>
|
||||
<p>To write applications against this library see the NVML
|
||||
developer page: <a href=
|
||||
"http://developer.nvidia.com/nvidia-management-library-NVML"
|
||||
target="_top">http://developer.nvidia.com/nvidia-management-library-NVML</a></p>
|
||||
<p>To include NVML functionality in scripting languages see:
|
||||
<a href=
|
||||
"http://search.cpan.org/~nvbinding/nvidia-ml-pl/lib/nvidia/ml.pm"
|
||||
target=
|
||||
"_top">http://search.cpan.org/~nvbinding/nvidia-ml-pl/lib/nvidia/ml.pm</a>
|
||||
and <a href="http://pypi.python.org/pypi/nvidia-ml-py/" target=
|
||||
"_top">http://pypi.python.org/pypi/nvidia-ml-py/</a></p>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"nvidia-smi.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"nvidia-debugdump.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 27. Using the nvidia-smi Utility </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 29. Using the nvidia-debugdump Utility</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,272 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 42. GPUDirect RDMA Peer Memory
|
||||
Client</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="addressingcapabilities.html" title=
|
||||
"Chapter 41. Addressing Capabilities">
|
||||
<link rel="next" href="gsp.html" title=
|
||||
"Chapter 43. GSP Firmware">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 42. GPUDirect RDMA
|
||||
Peer Memory Client</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"addressingcapabilities.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"gsp.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="nvidia-peermem" id=
|
||||
"nvidia-peermem"></a>Chapter 42. GPUDirect RDMA Peer
|
||||
Memory Client</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="toc">
|
||||
<p><b>Table of Contents</b></p>
|
||||
<dl>
|
||||
<dt><span class="section"><a href=
|
||||
"nvidia-peermem.html#Background03f8e">Background</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"nvidia-peermem.html#Usaged9d8e">Usage</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"nvidia-peermem.html#ModuleParameterb2f08">Module
|
||||
Parameters</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"nvidia-peermem.html#KnownIssues57784">Known Issues</a></span></dt>
|
||||
</dl>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name="Background03f8e" id=
|
||||
"Background03f8e"></a>Background</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>GPUDirect RDMA (Remote Direct Memory Access) is a technology
|
||||
that enables a direct path for data exchange between the GPU and a
|
||||
third-party peer device using standard features of PCI Express.</p>
|
||||
<p>The NVIDIA GPU driver package provides a kernel module,
|
||||
<code class="filename">nvidia-peermem.ko</code>, which provides
|
||||
Mellanox InfiniBand based HCAs (Host Channel Adapters) direct
|
||||
peer-to-peer read and write access to the NVIDIA GPU's video
|
||||
memory. It allows GPUDirect RDMA-based applications to use GPU
|
||||
computing power with the RDMA interconnect without needing to copy
|
||||
data to host memory.</p>
|
||||
<p>This capability is supported with Mellanox ConnectX-3 VPI or
|
||||
newer adapters. It works with both InfiniBand and RoCE (RDMA over
|
||||
Converged Ethernet) technologies.</p>
|
||||
<p>Mellanox OFED (Open Fabrics Enterprise Distribution) or MOFED,
|
||||
introduces an API between the InfiniBand Core and peer memory
|
||||
clients such as NVIDIA GPUs, called PeerDirect, see <a href=
|
||||
"https://community.mellanox.com/s/article/howto-implement-peerdirect-client-using-mlnx-ofed"
|
||||
target=
|
||||
"_top">https://community.mellanox.com/s/article/howto-implement-peerdirect-client-using-mlnx-ofed</a>.</p>
|
||||
<p>The <code class="filename">nvidia-peermem.ko</code> module
|
||||
registers the NVIDIA GPU with the InfiniBand subsystem by using
|
||||
peer-to-peer APIs provided by the NVIDIA GPU driver.</p>
|
||||
<p>This module, originally maintained by Mellanox on GitHub, is now
|
||||
included with the NVIDIA Linux GPU driver. The original GitHub
|
||||
project at <a href="https://github.com/Mellanox/nv_peer_memory"
|
||||
target="_top">https://github.com/Mellanox/nv_peer_memory</a> should
|
||||
be considered deprecated and only critical bugs will be addressed
|
||||
for existing installations.</p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name="Usaged9d8e" id=
|
||||
"Usaged9d8e"></a>Usage</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>The kernel must have the required support for RDMA peer memory
|
||||
either through additional patches to the kernel or via Mellanox
|
||||
OFED package (MOFED) as a prerequisite for loading and using
|
||||
<code class="filename">nvidia-peermem.ko</code>.</p>
|
||||
<p>It is possible that the <span><strong class=
|
||||
"command">nv_peer_mem</strong></span> module from the GitHub
|
||||
project may be installed and loaded on the system. Installation of
|
||||
<code class="filename">nvidia-peermem.ko</code> will not affect the
|
||||
functionality of the existing <code class=
|
||||
"filename">nv_peer_mem</code> module. But, to load and use
|
||||
<code class="filename">nvidia-peermem.ko</code>, users must disable
|
||||
the <span><strong class="command">nv_peer_mem</strong></span>
|
||||
service. Additionally, it is encouraged to uninstall the
|
||||
<span><strong class="command">nv_peer_mem</strong></span> package
|
||||
to avoid any conflict with <code class=
|
||||
"filename">nvidia-peermem.ko</code> since only one module can be
|
||||
loaded at any time.</p>
|
||||
<p>Stop the <span><strong class=
|
||||
"command">nv_peer_mem</strong></span> service:</p>
|
||||
<pre class="screen">
|
||||
# service nv_peer_mem stop
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>Check if <code class="filename">nv_peer_mem.ko</code> is still
|
||||
loaded after stopping the service:</p>
|
||||
<pre class="screen">
|
||||
# lsmod | grep nv_peer_mem
|
||||
</pre>
|
||||
<p>If <code class="filename">nv_peer_mem.ko</code> is still loaded,
|
||||
unload it with:</p>
|
||||
<pre class="screen">
|
||||
# rmmod nv_peer_mem
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>Uninstall <span><strong class=
|
||||
"command">nv_peer_mem</strong></span> package:</p>
|
||||
<p>For DEB based OS:</p>
|
||||
<pre class="screen">
|
||||
# dpkg -P nvidia-peer-memory
|
||||
</pre>
|
||||
<p></p>
|
||||
<pre class="screen">
|
||||
# dpkg -P nvidia-peer-memory-dkms
|
||||
</pre>
|
||||
<p>For RPM based OS:</p>
|
||||
<pre class="screen">
|
||||
# rpm -e nvidia_peer_memory
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>After ensuring kernel support and installing the GPU driver,
|
||||
<code class="filename">nvidia-peermem.ko</code> can be loaded with
|
||||
the following command with root privileges in a terminal
|
||||
window:</p>
|
||||
<pre class="screen">
|
||||
# modprobe nvidia-peermem
|
||||
</pre>
|
||||
<p>Note: If the NVIDIA GPU driver is installed before MOFED, the
|
||||
GPU driver must be uninstalled and installed again to make sure
|
||||
<code class="filename">nvidia-peermem.ko</code> is compiled with
|
||||
the RDMA APIs that are provided by MOFED.</p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"ModuleParameterb2f08" id="ModuleParameterb2f08"></a>Module
|
||||
Parameters</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<code class="computeroutput">peerdirect_support</code>: this
|
||||
parameter takes the following integer values:
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>0, which is the default and is appropriate for a kernel that has
|
||||
the PeerDirect APIs roughly corresponding to MOFED 5.1.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>1, which is required in combination with the legacy PeerDirect
|
||||
APIs, as currently shipping in MOFED 5.0 and older releases,
|
||||
notably in MOFED LTS.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p>As a reference, in the legacy PeerDirect APIs, the
|
||||
<span><strong class="command">peer_memory_client</strong></span>
|
||||
structure declared in <span><strong class=
|
||||
"command">peer_mem.h</strong></span> has the two extra function
|
||||
pointers shown below:</p>
|
||||
<pre class="screen">
|
||||
void* (*get_context_private_data)(u64 peer_id);
|
||||
void (*put_context_private_data)(void *context);
|
||||
</pre>
|
||||
<p>Note that MOFED LTS as well as MOFED 5.0 and previous releases
|
||||
ship with legacy PeerDirect APIs. So for example, when using MOFED
|
||||
LTS, GPUDirect RDMA support for the Mellanox HCAs will not work
|
||||
correctly unless <code class=
|
||||
"computeroutput">peerdirect_support</code> is set to one.</p>
|
||||
<p>Instead for MOFED 5.1 or newer, the default value of zero is
|
||||
appropriate, so no special actions are needed.</p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name="KnownIssues57784"
|
||||
id="KnownIssues57784"></a>Known Issues</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>Currently, there is no service to automatically load
|
||||
<code class="filename">nvidia-peermem.ko</code>. Users need to load
|
||||
the module manually.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>When loading <code class="filename">nvidia-peermem.ko</code> on
|
||||
a kernel with legacy PeerDirect APIs, the module parameter
|
||||
<code class="computeroutput">peerdirect_support</code> has to be
|
||||
set to one.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The <code class="computeroutput">PeerDirect</code> APIs shipping
|
||||
in MOFED releases 5.1 and later are affected by a lock inversion
|
||||
bug which may lead to a kernel-side deadlock. This is tracked by
|
||||
the NVIDIA-internal reference number <code class=
|
||||
"computeroutput">2696789</code>. PeerDirect APIs in newer MOFED
|
||||
releases belonging to some branches, like <code class=
|
||||
"computeroutput">5.3-1.0.0.1.43</code>, offer an opt-in feature to
|
||||
mitigate that problem. Starting from this release the <code class=
|
||||
"filename">nvidia-peermem.ko</code> kernel module explicitly
|
||||
enables it, unless <code class=
|
||||
"computeroutput">peerdirect_support</code> is set to one.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"addressingcapabilities.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"gsp.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 41. Addressing Capabilities </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 43. GSP Firmware</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,236 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 30. Using the nvidia-persistenced
|
||||
Utility</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="nvidia-debugdump.html" title=
|
||||
"Chapter 29. Using the nvidia-debugdump Utility">
|
||||
<link rel="next" href="sli.html" title=
|
||||
"Chapter 31. Configuring SLI and Multi-GPU Mosaic">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 30. Using the
|
||||
nvidia-persistenced Utility</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"nvidia-debugdump.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"sli.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="nvidia-persistenced" id=
|
||||
"nvidia-persistenced"></a>Chapter 30. Using the
|
||||
nvidia-persistenced Utility</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="toc">
|
||||
<p><b>Table of Contents</b></p>
|
||||
<dl>
|
||||
<dt><span class="section"><a href=
|
||||
"nvidia-persistenced.html#Background46f43">Background</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"nvidia-persistenced.html#Usage01b5d">Usage</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"nvidia-persistenced.html#Troubleshootingc8305">Troubleshooting</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"nvidia-persistenced.html#NotesForPackage3f7a9">Notes for Package
|
||||
Maintainers</a></span></dt>
|
||||
</dl>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name="Background46f43" id=
|
||||
"Background46f43"></a>Background</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>A Linux daemon utility, <span><strong class=
|
||||
"command">nvidia-persistenced</strong></span>, addresses an
|
||||
undesirable side effect of the NVIDIA kernel driver behavior in
|
||||
certain computing environments. Whenever the NVIDIA device
|
||||
resources are no longer in use, the NVIDIA kernel driver will tear
|
||||
down the device state. Normally, this is the intended behavior of
|
||||
the device driver, but for some applications, the latencies
|
||||
incurred by repetitive device initialization can significantly
|
||||
impact performance.</p>
|
||||
<p>To avoid this behavior, <span><strong class=
|
||||
"command">nvidia-persistenced</strong></span> provides a
|
||||
configuration option called "persistence mode" that can be set by
|
||||
NVIDIA management software, such as <span><strong class=
|
||||
"command">nvidia-smi</strong></span>. When persistence mode is
|
||||
enabled, the daemon holds the NVIDIA character device files open,
|
||||
preventing the NVIDIA kernel driver from tearing down device state
|
||||
when no other process is using the device. This utility does not
|
||||
actually use any device resources itself - it will simply sleep
|
||||
while maintaining a reference to the NVIDIA device state.</p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name="Usage01b5d" id=
|
||||
"Usage01b5d"></a>Usage</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p><span><strong class=
|
||||
"command">nvidia-persistenced</strong></span> is included with the
|
||||
NVIDIA Linux GPU driver. After installing the driver, this utility
|
||||
may be installed to run on system startup or manually with the
|
||||
command:</p>
|
||||
<pre class="screen">
|
||||
# nvidia-persistenced
|
||||
</pre>
|
||||
<p>in a terminal window. Note that the daemon may require root
|
||||
privileges to create its runtime data directory,
|
||||
/var/run/nvidia-persistenced/, or it may otherwise need to be run
|
||||
as a user that has access to that directory.</p>
|
||||
<p>Detailed help and usage information is available primarily via
|
||||
the <span><strong class=
|
||||
"command">nvidia-persistenced</strong></span> man page, as well as
|
||||
the <span><strong class="command">--help</strong></span> command
|
||||
line option.</p>
|
||||
<p>The source code to nvidia-persistenced is released under the MIT
|
||||
license and is available at: <a href=
|
||||
"https://download.nvidia.com/XFree86/nvidia-persistenced/" target=
|
||||
"_top">https://download.nvidia.com/XFree86/nvidia-persistenced/</a>.</p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"Troubleshootingc8305" id=
|
||||
"Troubleshootingc8305"></a>Troubleshooting</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>If you have difficulty getting <span><strong class=
|
||||
"command">nvidia-persistenced</strong></span> to work as expected,
|
||||
the best way to gather information as to what is happening is to
|
||||
run the daemon with the <span><strong class=
|
||||
"command">--verbose</strong></span> option.</p>
|
||||
<p><span><strong class=
|
||||
"command">nvidia-persistenced</strong></span> detaches from its
|
||||
parent process very early on, and as such only invalid command line
|
||||
argument errors will be printed in the terminal window. All other
|
||||
output, including verbose informational messages, are sent to the
|
||||
syslog interface instead. Consult your distribution's documentation
|
||||
for accessing syslog output.</p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"NotesForPackage3f7a9" id="NotesForPackage3f7a9"></a>Notes for
|
||||
Package Maintainers</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>The daemon utility <span><strong class=
|
||||
"command">nvidia-persistenced</strong></span> is installed by the
|
||||
NVIDIA Linux GPU driver installer, but it is not installed to run
|
||||
on system startup. Due to the wide variety of init systems used by
|
||||
the various Linux distributions that the NVIDIA Linux GPU driver
|
||||
supports, we request that package maintainers for those
|
||||
distributions provide the packaging necessary to integrate well
|
||||
with their platform.</p>
|
||||
<p>NVIDIA provides sample init scripts for some common init systems
|
||||
in
|
||||
/usr/share/doc/NVIDIA_GLX-1.0/sample/nvidia-persistenced-init.tar.bz2
|
||||
to aid in installation of the utility.</p>
|
||||
<p><span><strong class=
|
||||
"command">nvidia-persistenced</strong></span> is intended to be run
|
||||
as a daemon from system initialization, and is generally designed
|
||||
as a tool for compute-only platforms where the NVIDIA device is not
|
||||
used to display a graphical user interface. As such, depending on
|
||||
how your package is typically used, it may not be necessary to
|
||||
install the daemon to run on system initialization.</p>
|
||||
<p>If <span><strong class=
|
||||
"command">nvidia-persistenced</strong></span> is packaged to run on
|
||||
system initialization, the package installation, init script or
|
||||
system management utility that runs the daemon should provide the
|
||||
following:</p>
|
||||
<div class="variablelist">
|
||||
<dl>
|
||||
<dt><span class="term">A non-root user to run as</span></dt>
|
||||
<dd>
|
||||
<p>It is strongly recommended, though not required, that the daemon
|
||||
be run as a non-root user for security purposes.</p>
|
||||
<p>The daemon may either be started with root privileges and the
|
||||
<span><strong class="command">--user</strong></span> option, or it
|
||||
may be run directly as the non-root user.</p>
|
||||
</dd>
|
||||
<dt><span class="term">Runtime access to
|
||||
/var/run/nvidia-persistenced/</span></dt>
|
||||
<dd>
|
||||
<p>The daemon must be able to create its socket and PID file in
|
||||
this directory.</p>
|
||||
<p>If the daemon is run as root, it will create this directory
|
||||
itself and remove it when it shuts down cleanly.</p>
|
||||
<p>If the daemon is run as a non-root user, this directory must
|
||||
already exist, and the daemon will not attempt to remove it when it
|
||||
shuts down cleanly.</p>
|
||||
<p>If the daemon is started as root, but provided a non-root user
|
||||
to run as via the <span><strong class=
|
||||
"command">--user</strong></span> option, the daemon will create
|
||||
this directory itself, <span><strong class=
|
||||
"command">chown</strong></span> it to the provided user, and
|
||||
<span><strong class="command">setuid</strong></span> to the
|
||||
provided user to drop root privileges. The daemon may be unable to
|
||||
remove this directory when it shuts down cleanly, depending on the
|
||||
privileges of the provided user.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
</div>
|
||||
<p></p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"nvidia-debugdump.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"sli.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 29. Using the nvidia-debugdump Utility </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 31. Configuring SLI and Multi-GPU
|
||||
Mosaic</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,83 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 27. Using the nvidia-smi Utility</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="retpoline.html" title=
|
||||
"Chapter 26. NVIDIA Spectre V2 Mitigation">
|
||||
<link rel="next" href="nvidia-ml.html" title=
|
||||
"Chapter 28. The NVIDIA Management Library">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 27. Using the
|
||||
nvidia-smi Utility</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"retpoline.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"nvidia-ml.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="nvidia-smi" id=
|
||||
"nvidia-smi"></a>Chapter 27. Using the nvidia-smi
|
||||
Utility</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>A monitoring and management command line utility,
|
||||
<span><strong class="command">nvidia-smi</strong></span>, is
|
||||
included with the NVIDIA Linux graphics driver. After installing
|
||||
the driver, you can run this utility by running:</p>
|
||||
<pre class="screen">
|
||||
% nvidia-smi
|
||||
</pre>
|
||||
<p>in a terminal window.</p>
|
||||
<p>Detailed help information is available via the --help command
|
||||
line option and via the nvidia-smi man page.</p>
|
||||
<p>To include nvidia-smi information in other applications see
|
||||
<a href="nvidia-ml.html" title=
|
||||
"Chapter 28. The NVIDIA Management Library">Chapter 28,
|
||||
<i>The NVIDIA Management Library</i></a></p>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"retpoline.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"nvidia-ml.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 26. NVIDIA Spectre V2 Mitigation </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 28. The NVIDIA Management Library</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,88 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 25. Using the nvidia-settings
|
||||
Utility</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="xcompositeextension.html" title=
|
||||
"Chapter 24. Using the X Composite Extension">
|
||||
<link rel="next" href="retpoline.html" title=
|
||||
"Chapter 26. NVIDIA Spectre V2 Mitigation">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 25. Using the
|
||||
nvidia-settings Utility</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"xcompositeextension.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"retpoline.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="nvidiasettings" id=
|
||||
"nvidiasettings"></a>Chapter 25. Using the
|
||||
nvidia-settings Utility</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>A graphical configuration utility, <span><strong class=
|
||||
"command">nvidia-settings</strong></span>, is included with the
|
||||
NVIDIA Linux graphics driver. After installing the driver and
|
||||
starting X, you can run this configuration utility by running:</p>
|
||||
<pre class="screen">
|
||||
% nvidia-settings
|
||||
</pre>
|
||||
<p>in a terminal window. nvidia-settings requires version 2.4 or
|
||||
later of the GTK+ 2 library.</p>
|
||||
<p>Some architectures of Linux support the GTK+ 3 library and would
|
||||
require version 3.0 or later if available.</p>
|
||||
<p>Detailed information about the configuration options available
|
||||
are documented in the help window in the utility.</p>
|
||||
<p>For more information, see the nvidia-settings man page.</p>
|
||||
<p>The source code to nvidia-settings is released as GPL and is
|
||||
available here: <a href=
|
||||
"https://download.nvidia.com/XFree86/nvidia-settings/" target=
|
||||
"_top">https://download.nvidia.com/XFree86/nvidia-settings/</a></p>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"xcompositeextension.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"retpoline.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 24. Using the X Composite Extension </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 26. NVIDIA Spectre V2 Mitigation</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,545 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 11. Specifying OpenGL Environment Variable
|
||||
Settings</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="dma_issues.html" title=
|
||||
"Chapter 10. Allocating DMA Buffers on 64-bit Platforms">
|
||||
<link rel="next" href="configtwinview.html" title=
|
||||
"Chapter 12. Configuring Multiple Display Devices on One X Screen">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 11. Specifying
|
||||
OpenGL Environment Variable Settings</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"dma_issues.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"configtwinview.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="openglenvvariables" id=
|
||||
"openglenvvariables"></a>Chapter 11. Specifying OpenGL
|
||||
Environment Variable Settings</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<h3>Full scene antialiasing</h3>
|
||||
<p>Antialiasing is a technique used to smooth the edges of objects
|
||||
in a scene to reduce the jagged "stairstep" effect that sometimes
|
||||
appears. By setting the appropriate environment variable, you can
|
||||
enable full-scene antialiasing in any OpenGL application on these
|
||||
GPUs.</p>
|
||||
<p>Several antialiasing methods are available and you can select
|
||||
between them by setting the __GL_FSAA_MODE environment variable
|
||||
appropriately. Note that increasing the number of samples taken
|
||||
during FSAA rendering may decrease performance.</p>
|
||||
<p>To see the available values for __GL_FSAA_MODE along with their
|
||||
descriptions, run:</p>
|
||||
<pre class="screen">
|
||||
nvidia-settings --query=fsaa --verbose
|
||||
</pre>
|
||||
<p>The __GL_FSAA_MODE environment variable uses the same integer
|
||||
values that are used to configure FSAA through nvidia-settings and
|
||||
the NV-CONTROL X extension. In other words, these two commands are
|
||||
equivalent:</p>
|
||||
<pre class="screen">
|
||||
export __GL_FSAA_MODE=5
|
||||
|
||||
nvidia-settings --assign FSAA=5
|
||||
</pre>
|
||||
<p>Note that there are three FSAA related configuration attributes
|
||||
(FSAA, FSAAAppControlled and FSAAAppEnhanced) which together
|
||||
determine how a GL application will behave. If FSAAAppControlled is
|
||||
1, the FSAA specified through nvidia-settings will be ignored, in
|
||||
favor of what the application requests through FBConfig selection.
|
||||
If FSAAAppControlled is 0 but FSAAAppEnhanced is 1, then the FSAA
|
||||
value specified through nvidia-settings will only be applied if the
|
||||
application selected a multisample FBConfig.</p>
|
||||
<p>Therefore, to be completely correct, the nvidia-settings command
|
||||
line to unconditionally assign FSAA should be:</p>
|
||||
<pre class="screen">
|
||||
nvidia-settings --assign FSAA=5 --assign FSAAAppControlled=0 --assign FSAAAppEnhanced=0
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>The driver may not be able to support a particular FSAA mode for
|
||||
a given application due to video or system memory limitations. In
|
||||
that case, the driver will silently fall back to a less demanding
|
||||
FSAA mode.</p>
|
||||
<h3>Fast approximate antialiasing (FXAA)</h3>
|
||||
<p>Fast approximate antialiasing is an antialiasing mode supported
|
||||
by the NVIDIA graphics driver that offers advantages over
|
||||
traditional multisampling and supersampling methods. This mode is
|
||||
incompatible with UBB, triple buffering, and other antialiasing
|
||||
methods. To enable this mode, run:</p>
|
||||
<pre class="screen">
|
||||
nvidia-settings --assign FXAA=1
|
||||
</pre>
|
||||
<p>nvidia-settings will automatically disable incompatible features
|
||||
when this command is run. Users may wish to disable use of FXAA for
|
||||
individual applications when FXAA is globally enabled. This can be
|
||||
done by setting the environment variable __GL_ALLOW_FXAA_USAGE to
|
||||
0. __GL_ALLOW_FXAA_USAGE has no effect when FXAA is globally
|
||||
disabled.</p>
|
||||
<h3>Anisotropic texture filtering</h3>
|
||||
<p>Automatic anisotropic texture filtering can be enabled by
|
||||
setting the environment variable __GL_LOG_MAX_ANISO. The possible
|
||||
values are:</p>
|
||||
<div class="informaltable">
|
||||
<table summary="(no summary available)" border="0">
|
||||
<colgroup>
|
||||
<col>
|
||||
<col></colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>__GL_LOG_MAX_ANISO</th>
|
||||
<th>Filtering Type</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>0</td>
|
||||
<td>No anisotropic filtering</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>1</td>
|
||||
<td>2x anisotropic filtering</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>2</td>
|
||||
<td>4x anisotropic filtering</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>3</td>
|
||||
<td>8x anisotropic filtering</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>4</td>
|
||||
<td>16x anisotropic filtering</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<p></p>
|
||||
<p><a name="vblanksyncing" id="vblanksyncing"></a></p>
|
||||
<h3>Vblank syncing</h3>
|
||||
<p>The __GL_SYNC_TO_VBLANK (boolean) environment variable can be
|
||||
used to control whether swaps are synchronized to a display
|
||||
device's vertical refresh.</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>Setting __GL_SYNC_TO_VBLANK=0 allows glXSwapBuffers to swap
|
||||
without waiting for vblank.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Setting __GL_SYNC_TO_VBLANK=1 forces glXSwapBuffers to
|
||||
synchronize with the vertical blanking period. This is the default
|
||||
behavior.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
<p>When sync to vblank is enabled with TwinView, OpenGL can only
|
||||
sync to one of the display devices; this may cause tearing
|
||||
corruption on the display device to which OpenGL is not syncing.
|
||||
You can use the environment variable __GL_SYNC_DISPLAY_DEVICE to
|
||||
specify which display device should be synchronized to for OpenGL
|
||||
or Vulkan. 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 <a href="configtwinview.html" title=
|
||||
"Chapter 12. Configuring Multiple Display Devices on One X Screen">
|
||||
Chapter 12, <i>Configuring Multiple Display Devices on One X
|
||||
Screen</i></a> "Configuring Twinview" and the section on Ensuring
|
||||
Identical Mode Timings in <a href="programmingmodes.html" title=
|
||||
"Chapter 18. Programming Modes">Chapter 18,
|
||||
<i>Programming Modes</i></a>. This environment variable is only
|
||||
applicable to Vulkan while using either VK_PRESENT_MODE_FIFO_KHR or
|
||||
VK_PRESENT_MODE_FIFO_RELAXED_KHR.</p>
|
||||
<p>If a display device is being provided by a synchronized RandR
|
||||
1.4 Output Sink, it will not be listed under "Connected display
|
||||
device(s):", but can still be used with __GL_SYNC_DISPLAY_DEVICE.
|
||||
The names of these display devices can be found using the
|
||||
<code class="computeroutput">xrandr</code> command line tool. See
|
||||
<a href="randr14.html#randr14sync" title=
|
||||
"Synchronized RandR 1.4 Outputs">Synchronized RandR 1.4 Outputs</a>
|
||||
for information on synchronized RandR 1.4 Output Sinks.</p>
|
||||
<h3>Controlling the sorting of OpenGL FBConfigs</h3>
|
||||
<p>The NVIDIA GLX implementation sorts FBConfigs returned by
|
||||
glXChooseFBConfig() as described in the GLX specification. To
|
||||
disable this behavior set __GL_SORT_FBCONFIGS to 0 (zero), then
|
||||
FBConfigs will be returned in the order they were received from the
|
||||
X server. To examine the order in which FBConfigs are returned by
|
||||
the X server run:</p>
|
||||
<pre class="screen">
|
||||
nvidia-settings --glxinfo
|
||||
</pre>
|
||||
<p>This option may be be useful to work around problems in which
|
||||
applications pick an unexpected FBConfig.</p>
|
||||
<h3>OpenGL yield behavior</h3>
|
||||
<p>There are several cases where the NVIDIA OpenGL driver needs to
|
||||
wait for external state to change before continuing. To avoid
|
||||
consuming too much CPU time in these cases, the driver will
|
||||
sometimes yield so the kernel can schedule other processes to run
|
||||
while the driver waits. For example, when waiting for free space in
|
||||
a command buffer, if the free space has not become available after
|
||||
a certain number of iterations, the driver will yield before it
|
||||
continues to loop.</p>
|
||||
<p>By default, the driver calls sched_yield() to do this. However,
|
||||
this can cause the calling process to be scheduled out for a
|
||||
relatively long period of time if there are other, same-priority
|
||||
processes competing for time on the CPU. One example of this is
|
||||
when an OpenGL-based composite manager is moving and repainting a
|
||||
window and the X server is trying to update the window as it moves,
|
||||
which are both CPU-intensive operations.</p>
|
||||
<p>You can use the __GL_YIELD environment variable to work around
|
||||
these scheduling problems. This variable allows the user to specify
|
||||
what the driver should do when it wants to yield. The possible
|
||||
values are:</p>
|
||||
<div class="informaltable">
|
||||
<table summary="(no summary available)" border="0">
|
||||
<colgroup>
|
||||
<col>
|
||||
<col></colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>__GL_YIELD</th>
|
||||
<th>Behavior</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><unset></td>
|
||||
<td>By default, OpenGL will call sched_yield() to yield.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>"NOTHING"</td>
|
||||
<td>OpenGL will never yield.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>"USLEEP"</td>
|
||||
<td>OpenGL will call usleep(0) to yield.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<p></p>
|
||||
<h3>Controlling which OpenGL FBConfigs are available</h3>
|
||||
<p>The NVIDIA GLX implementation will hide FBConfigs that are
|
||||
associated with a 32-bit ARGB visual when the
|
||||
XLIB_SKIP_ARGB_VISUALS environment variable is defined. This
|
||||
matches the behavior of libX11, which will hide those visuals from
|
||||
XGetVisualInfo and XMatchVisualInfo. This environment variable is
|
||||
useful when applications are confused by the presence of these
|
||||
FBConfigs.</p>
|
||||
<p><a name="unofficialprotoenv" id="unofficialprotoenv"></a></p>
|
||||
<h3>Using Unofficial GLX protocol</h3>
|
||||
<p>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 client-side portion of such protocol when using indirect
|
||||
rendering, they can set the __GL_ALLOW_UNOFFICIAL_PROTOCOL
|
||||
environment variable to a non-zero value before starting their GLX
|
||||
application. When an NVIDIA GLX server is used, the related X
|
||||
Config option <a href=
|
||||
"xconfigoptions.html#AllowUnofficialGLXProtocol">AllowUnofficialGLXProtocol</a>
|
||||
will need to be set as well to enable support in the server.</p>
|
||||
<h3>Overriding driver detection of SELinux policy booleans</h3>
|
||||
<p>On Linux, the NVIDIA GLX implementation will attempt to detect
|
||||
whether SELinux is enabled and modify its behavior to respect
|
||||
SELinux policy. By default, the driver adheres to SELinux policy
|
||||
boolean settings at the beginning of a client process's execution;
|
||||
due to shared library limitations, these settings remain fixed
|
||||
throughout the lifetime of the driver instance. Additionally, the
|
||||
driver will adhere to policy boolean settings regardless of whether
|
||||
SELinux is running in permissive mode or enforcing mode. The
|
||||
__GL_SELINUX_BOOLEANS environment variable allows the user to
|
||||
override driver detection of specified SELinux booleans so the
|
||||
driver acts as if these booleans were set or unset. This allows the
|
||||
user, for example, to run the driver under a more restrictive
|
||||
policy than specified by SELinux, or to work around problems when
|
||||
running the driver under SELinux while operating in permissive
|
||||
mode.</p>
|
||||
<p>__GL_SELINUX_BOOLEANS should be set to a comma-separated list of
|
||||
key/value pairs:</p>
|
||||
<pre class="screen">
|
||||
__GL_SELINUX_BOOLEANS="key1=val1,key2=val2,key3=val3,..."
|
||||
</pre>
|
||||
<p>Valid keys are any SELinux booleans specified by "getsebool -a",
|
||||
and valid values are 1, true, yes, or on to enable the boolean, and
|
||||
0, false, no, or off to disable it. There should be no whitespace
|
||||
between any key, value, or delimiter. If this environment variable
|
||||
is set, the driver assumes that SELinux is enabled on the system.
|
||||
Currently, the driver only uses the "allow_execmem" and
|
||||
"deny_execmem" booleans to determine whether it can apply
|
||||
optimizations that use writable, executable memory. Users can
|
||||
explicitly request that these optimizations be turned off by using
|
||||
the __GL_WRITE_TEXT_SECTION environment variable (see <a href=
|
||||
"openglenvvariables.html#disableexecmem" title=
|
||||
"Disabling executable memory optimizations">Disabling executable
|
||||
memory optimizations</a> below). By default, if the driver cannot
|
||||
detect the value of one or both of these booleans, it assumes the
|
||||
most permissive setting (i.e. executable memory is allowed).</p>
|
||||
<h3>Limiting heap allocations in the OpenGL driver</h3>
|
||||
<p>The NVIDIA OpenGL implementation normally does not enforce
|
||||
limits on dynamic system memory allocations (i.e., memory allocated
|
||||
by the driver from the C library via the malloc(3) memory
|
||||
allocation package). The __GL_HEAP_ALLOC_LIMIT environment variable
|
||||
enables the user to specify a per-process heap allocation limit for
|
||||
as long as libGL is loaded in the application.</p>
|
||||
<p>__GL_HEAP_ALLOC_LIMIT is specified in the form BYTES SUFFIX,
|
||||
where BYTES is a nonnegative integer and SUFFIX is an optional
|
||||
multiplicative suffix: kB = 1000, k = 1024, MB = 1000*1000, M =
|
||||
1024*1024, GB = 1000*1000*1000, and G = 1024*1024*1024. SUFFIX is
|
||||
not case-sensitive. For example, to specify a heap allocation limit
|
||||
of 20 megabytes:</p>
|
||||
<pre class="screen">
|
||||
__GL_HEAP_ALLOC_LIMIT="20 MB"
|
||||
</pre>
|
||||
<p>If SUFFIX is not specified, the limit is assumed to be given in
|
||||
bytes. The minimum heap allocation limit is 12 MB. If a lower limit
|
||||
is specified, the limit is clamped to the minimum.</p>
|
||||
<p>The GNU C library provides several hooks that may be used by
|
||||
applications to modify the behavior of malloc(3), realloc(3), and
|
||||
free(3). In addition, an application or library may specify
|
||||
allocation symbols that the driver will use in place of those
|
||||
exported by libc. Heap allocation tracking is incompatible with
|
||||
these features, and the driver will disable the heap allocation
|
||||
limit if it detects that they are in use.</p>
|
||||
<p>WARNING: Enforcing a limit on heap allocations may cause
|
||||
unintended behavior and lead to application crashes, data
|
||||
corruption, and system instability. ENABLE AT YOUR OWN RISK.</p>
|
||||
<h3>OpenGL Shader Disk Cache</h3>
|
||||
<p>The NVIDIA OpenGL driver utilizes a shader disk cache. This
|
||||
optimization benefits some applications, by reusing shader binaries
|
||||
instead of compiling them repeatedly. The related environment
|
||||
variables __GL_SHADER_DISK_CACHE, __GL_SHADER_DISK_CACHE_PATH, and
|
||||
__GL_SHADER_DISK_CACHE_SIZE as well as the GLShaderDiskCache X
|
||||
configuration option, allow fine-grained configuration of the
|
||||
shader cache behavior. The shader disk cache:</p>
|
||||
<div class="orderedlist">
|
||||
<ol type="1">
|
||||
<li>
|
||||
<p>is always disabled for indirect rendering</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>is always disabled for setuid and setgid binaries</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>by default, is disabled for direct rendering when the OpenGL
|
||||
application is run as the root user</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>by default, is enabled for direct rendering when the OpenGL
|
||||
application is run as a non-root user</p>
|
||||
</li>
|
||||
</ol>
|
||||
</div>
|
||||
<p>The GLShaderDiskCache X configuration option forcibly enables or
|
||||
disables the shader disk cache, for direct rendering as a non-root
|
||||
user.</p>
|
||||
<p>The following environment variables configure shader disk cache
|
||||
behavior, and override the GLShaderDiskCache configuration
|
||||
option:</p>
|
||||
<div class="informaltable">
|
||||
<table summary="(no summary available)" border="0">
|
||||
<colgroup>
|
||||
<col>
|
||||
<col></colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Environment Variable</th>
|
||||
<th>Description</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>__GL_SHADER_DISK_CACHE (boolean)</td>
|
||||
<td>Enables or disables the shader cache for direct rendering.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>__GL_SHADER_DISK_CACHE_PATH (string)</td>
|
||||
<td>Enables configuration of where shader caches are stored on
|
||||
disk.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>__GL_SHADER_DISK_CACHE_SIZE (integer)</td>
|
||||
<td class="auto-generated"> </td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<p></p>
|
||||
<p>If __GL_SHADER_DISK_CACHE_PATH is unset, caches will be stored
|
||||
in $XDG_CACHE_HOME/nvidia/GLCache/ if XDG_CACHE_HOME is set, or in
|
||||
$HOME/.cache/nvidia/GLCache/ if HOME is set. If none of the
|
||||
environment variables __GL_SHADER_DISK_CACHE_PATH, XDG_CACHE_HOME,
|
||||
or HOME is set, the shader cache will be disabled. Caches are
|
||||
persistent across runs of an application. Cached shader binaries
|
||||
are specific to each driver version; changing driver versions will
|
||||
cause binaries to be recompiled.</p>
|
||||
<p>Note that earlier driver versions kept the default caches in
|
||||
$XDG_CACHE_HOME/.nv/GLCache/ or $HOME/.nv/GLCache/ instead of
|
||||
$XDG_CACHE_HOME/nvidia/GLCache/ or $HOME/.cache/nvidia/GLCache/,
|
||||
respectively. If these earlier locations exist they will be reused
|
||||
instead. It is safe to remove any .nv/GLCache/ directory, after
|
||||
which the driver will populate a fresh cache in the new locations
|
||||
as described in the previous paragraph.</p>
|
||||
<p>If the default cache is used and __GL_SHADER_DISK_CACHE_SIZE is
|
||||
set locally: any applications that subsequently run without setting
|
||||
it will revert the cache to the default size and cause the cache to
|
||||
be wiped if it now goes over. To increase the cache size globally,
|
||||
__GL_SHADER_DISK_CACHE_SIZE can be set in e.g. ~/.bashrc or
|
||||
~/.profile.</p>
|
||||
<h3>Threaded Optimizations</h3>
|
||||
<p>The NVIDIA OpenGL driver supports offloading its CPU computation
|
||||
to a worker thread. These optimizations typically benefit
|
||||
CPU-intensive applications, but might cause a decrease of
|
||||
performance in applications that heavily rely on synchronous OpenGL
|
||||
calls such as glGet*. Because of this, they are currently disabled
|
||||
by default.</p>
|
||||
<p>Setting the __GL_THREADED_OPTIMIZATIONS environment variable to
|
||||
"1" before loading the NVIDIA OpenGL driver library will enable
|
||||
these optimizations for the lifetime of the application.</p>
|
||||
<p>Please note that these optimizations will only work if the
|
||||
target application dynamically links against pthreads. If this
|
||||
isn't the case, the dynamic loader can be instructed to do so at
|
||||
runtime by setting the LD_PRELOAD environment variable to include
|
||||
the pthreads library.</p>
|
||||
<p>Additionally, these optimizations require Xlib to function in
|
||||
thread-safe mode. The NVIDIA OpenGL driver cannot reliably enable
|
||||
Xlib thread-safe mode itself, therefore the application needs to
|
||||
call XInitThreads() before making any other Xlib call. Otherwise,
|
||||
the threaded optimizations in the NVIDIA driver will not be
|
||||
enabled.</p>
|
||||
<h3>Conformant glBlitFramebuffer() scissor test behavior</h3>
|
||||
<p>This option enables the glBlitFramebuffer() scissor test, which
|
||||
must be enabled for glBlitFramebuffer() to behave in a conformant
|
||||
manner. Setting the __GL_ConformantBlitFramebufferScissor
|
||||
environment variable to 0 disables the glBlitFramebuffer() scissor
|
||||
test, and setting it to 1 enables it. By default, the
|
||||
glBlitFramebuffer() scissor test is enabled.</p>
|
||||
<p>Some applications have bugs which cause them to not display
|
||||
properly with a conformant glBlitFramebuffer(). See <a href=
|
||||
"knownissues.html" title=
|
||||
"Chapter 9. Known Issues">Chapter 9, <i>Known
|
||||
Issues</i></a> for more details.</p>
|
||||
<h3>G-SYNC</h3>
|
||||
<p>When a G-SYNC or G-SYNC Compatible monitor is attached, and
|
||||
G-SYNC or G-SYNC Compatible mode was allowed when the mode was set,
|
||||
this option controls whether these “<span class=
|
||||
"quote">variable refresh rate</span>”, or VRR, features can
|
||||
be used. Setting the __GL_VRR_ALLOWED environment variable to 0
|
||||
disables VRR flipping for the application on any G-SYNC or G-SYNC
|
||||
Compatible monitors. Setting the __GL_VRR_ALLOWED environment
|
||||
variable to 1 has no effect on non-VRR monitors, or monitors that
|
||||
disallowed G-SYNC or G-SYNC Compatible mode when the mode was
|
||||
set.</p>
|
||||
<p>When G-SYNC is active on a G-SYNC or G-SYNC Compatible display
|
||||
and __GL_SYNC_TO_VBLANK is disabled, applications rendering faster
|
||||
than the maximum refresh rate will tear. This eliminates tearing
|
||||
for frame rates below the monitor's maximum refresh rate while
|
||||
minimizing latency for frame rates above it. When
|
||||
__GL_SYNC_TO_VBLANK is enabled, the frame rate is limited to the
|
||||
monitor's maximum refresh rate to eliminate tearing completely.
|
||||
When a G-SYNC Compatible display is in use, applications rendering
|
||||
slower than the minimum refresh rate may tear when
|
||||
__GL_SYNC_TO_VBLANK is disabled, and their swaps may not complete
|
||||
until the next vblank when __GL_SYNC_TO_VBLANK is enabled.</p>
|
||||
<p>G-SYNC and G-SYNC Compatible mode cannot be used when
|
||||
workstation stereo or workstation overlays are enabled, or when
|
||||
there is more than one X screen.</p>
|
||||
<p><a name="disableexecmem" id="disableexecmem"></a></p>
|
||||
<h3>Disabling executable memory optimizations</h3>
|
||||
<p>By default, the NVIDIA driver will attempt to use optimizations
|
||||
which rely on being able to write to executable memory. This may
|
||||
cause problems in certain system configurations (e.g., on SELinux
|
||||
when the "allow_execmem" boolean is disabled or "deny_execmem"
|
||||
boolean is enabled, and on grsecurity kernels configured with
|
||||
CONFIG_PAX_MPROTECT). When possible, the driver will attempt to
|
||||
detect when it is running on an unsupported configuration and
|
||||
disable these optimizations automatically. If the
|
||||
__GL_WRITE_TEXT_SECTION environment variable is set to 0, the
|
||||
driver will unconditionally disable these optimizations.</p>
|
||||
<h3>Ignoring GLSL (OpenGL Shading Language) extension checks</h3>
|
||||
<p>Some applications may use GLSL shaders that reference global
|
||||
variables defined only in an OpenGL extension without including a
|
||||
corresponding #extension directive in their source code.
|
||||
Additionally, some applications may use GLSL shaders version 150 or
|
||||
greater that reference global variables defined in a compatibility
|
||||
profile, without specifying that a compatibility profile should be
|
||||
used in their #version directive. Setting the
|
||||
__GL_IGNORE_GLSL_EXT_REQS environment variable to 1 will cause the
|
||||
driver to ignore this class of errors, which may allow these
|
||||
shaders to successfully compile.</p>
|
||||
<h3>Showing the Graphics API Visual Indicator</h3>
|
||||
<p>The __GL_SHOW_GRAPHICS_OSD (boolean) environment variable can be
|
||||
used to control whether the graphics API visual indicator is
|
||||
rendered on top of OpenGL and Vulkan applications.</p>
|
||||
<p>This indicator displays various information such as the graphics
|
||||
API in use, instantaneous frame rate, whether the application is
|
||||
synced to vblank, and whether the application is blitting or
|
||||
flipping.</p>
|
||||
<h3>Image Sharpening</h3>
|
||||
<p>The __GL_SHARPEN_ENABLE environment variable can be used to
|
||||
enable image sharpening for OpenGL and Vulkan applications. Setting
|
||||
__GL_SHARPEN_ENABLE=1 enables image sharpening, while setting
|
||||
__GL_SHARPEN_ENABLE=0 (default) disables image sharpening. The
|
||||
amount of sharpening can be controlled by setting the
|
||||
__GL_SHARPEN_VALUE environment variable to a value between 0 and
|
||||
100, with 0 being no sharpening, 100 being maximum sharpening, and
|
||||
50 being the default. The amount of denoising done on the sharpened
|
||||
image can be controlled with the __GL_SHARPEN_IGNORE_FILM_GRAIN
|
||||
environment variable, with 0 being no denoising, 100 being maximum
|
||||
denoising, and 17 being the default.</p>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"dma_issues.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"configtwinview.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 10. Allocating DMA Buffers on 64-bit
|
||||
Platforms </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 12. Configuring Multiple Display Devices on
|
||||
One X Screen</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,130 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 17. Using the NVIDIA Driver with Optimus
|
||||
Laptops</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="configlaptop.html" title=
|
||||
"Chapter 16. Configuring a Notebook">
|
||||
<link rel="next" href="programmingmodes.html" title=
|
||||
"Chapter 18. Programming Modes">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 17. Using the
|
||||
NVIDIA Driver with Optimus Laptops</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"configlaptop.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"programmingmodes.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="optimus" id=
|
||||
"optimus"></a>Chapter 17. Using the NVIDIA Driver with
|
||||
Optimus Laptops</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>Some laptops with NVIDIA GPUs make use of Optimus technology to
|
||||
allow switching between an integrated GPU and a discrete NVIDIA
|
||||
GPU. The NVIDIA Linux driver can be used on these systems.</p>
|
||||
<h3>Installing the NVIDIA Driver on an Optimus Laptop</h3>
|
||||
<p>The driver may be installed normally on Optimus systems, but the
|
||||
NVIDIA X driver and the NVIDIA OpenGL driver may not be able to
|
||||
display to the laptop's internal display panel unless a means to
|
||||
connect the panel to the NVIDIA GPU (for example, a hardware
|
||||
multiplexer, or "mux", often controllable by a BIOS setting) is
|
||||
available. On systems without a mux, the NVIDIA GPU can still be
|
||||
useful for offscreen rendering, PRIME render offload, running CUDA
|
||||
applications, and other uses that don't require driving a
|
||||
display.</p>
|
||||
<p>On muxless Optimus laptops, or on laptops where a mux is
|
||||
present, but not set to drive the internal display from the NVIDIA
|
||||
GPU, the internal display is driven by the integrated GPU. On these
|
||||
systems, it's important that the X server not be configured to use
|
||||
the NVIDIA X driver after the driver is installed. Instead, the
|
||||
correct driver for the integrated GPU should be used. Often, this
|
||||
can be determined automatically by the X server, and no explicit
|
||||
configuration is required, especially on newer X server versions.
|
||||
If your X server autoselects the NVIDIA X driver after
|
||||
installation, you may need to explicitly select the driver for your
|
||||
integrated GPU.</p>
|
||||
<p>As an alternative to using only the integrated graphics device,
|
||||
support for the display output source functionality provided by the
|
||||
X Resize and Rotate extension version 1.4 is available. This
|
||||
functionality allows for graphics to be rendered on the NVIDIA GPU
|
||||
and displayed on the integrated graphics device. For information on
|
||||
how to use this functionality, see <a href="randr14.html" title=
|
||||
"Chapter 34. Offloading Graphics Display with RandR 1.4">Chapter 34,
|
||||
<i>Offloading Graphics Display with RandR 1.4</i></a>.</p>
|
||||
<p>A second alternative is to use PRIME render offload, such that
|
||||
the integrated graphics device is used to drive the X screen, but
|
||||
the NVIDIA GPU is used on a per-application basis to accelerate
|
||||
rendering of specific applications. For details, see <a href=
|
||||
"primerenderoffload.html" title=
|
||||
"Chapter 35. PRIME Render Offload">Chapter 35,
|
||||
<i>PRIME Render Offload</i></a>.</p>
|
||||
<h3>Loading the Kernel Module and Creating the Device Files without
|
||||
X</h3>
|
||||
<p>In order for programs that use the NVIDIA driver to work
|
||||
correctly (e.g.: X, OpenGL, and CUDA applications), the kernel
|
||||
module must be loaded, and the device files <code class=
|
||||
"filename">/dev/nvidiactl</code> and <code class=
|
||||
"filename">/dev/nvidia[0-9]+</code> must exist with read and write
|
||||
permissions for any users of such applications. If the setuid root
|
||||
nvidia-modprobe(1) utility is installed (the default when the
|
||||
driver is installed from .run file), this should be handled
|
||||
automatically. Otherwise, the kernel module will need to be loaded,
|
||||
and the device files created, through your Linux distribution's
|
||||
mechanisms.</p>
|
||||
<p>See <a href="faq.html#devicenodes">“How and when are the
|
||||
NVIDIA device files created?”</a> for more information.</p>
|
||||
<p>Note that on some Optimus notebooks the driver may fail to
|
||||
initialize the GPU due to system-specific ACPI interaction
|
||||
problems: see <a href=
|
||||
"commonproblems.html#optimusacpivbios">“Why does the VBIOS
|
||||
fail to load on my Optimus system?”</a> for more
|
||||
information.</p>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"configlaptop.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"programmingmodes.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 16. Configuring a Notebook </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 18. Programming Modes</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,479 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 21. Configuring Power Management
|
||||
Support</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="procinterface.html" title=
|
||||
"Chapter 20. Using the /proc File System Interface">
|
||||
<link rel="next" href="dynamicpowermanagement.html" title=
|
||||
"Chapter 22. PCI-Express Runtime D3 (RTD3) Power Management">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 21. Configuring
|
||||
Power Management Support</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"procinterface.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"dynamicpowermanagement.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="powermanagement" id=
|
||||
"powermanagement"></a>Chapter 21. Configuring Power
|
||||
Management Support</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="toc">
|
||||
<p><b>Table of Contents</b></p>
|
||||
<dl>
|
||||
<dt><span class="section"><a href=
|
||||
"powermanagement.html#Backgroundc73a7">Background</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"powermanagement.html#Overview21f77">Overview</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"powermanagement.html#PreserveAllVide719f0">Preserve all video
|
||||
memory allocations</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"powermanagement.html#SystemdConfigur74e29"><span><strong class=
|
||||
"command">systemd</strong></span> Configuration</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"powermanagement.html#ExercisingPower89cc2">Exercising power
|
||||
management with <span><strong class=
|
||||
"command">systemd</strong></span></a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"powermanagement.html#KnownIssuesAndWf438e">Known Issues and
|
||||
Workarounds</a></span></dt>
|
||||
</dl>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name="Backgroundc73a7" id=
|
||||
"Backgroundc73a7"></a>Background</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>The NVIDIA Linux driver includes support for the suspend
|
||||
(suspend-to-RAM) and hibernate (suspend-to-disk) system power
|
||||
management operations, such as ACPI S3 and S4 on the x86_64
|
||||
platform. When the system suspends or hibernates, the NVIDIA kernel
|
||||
drivers prepare in-use GPUs for the sleep cycle, saving state
|
||||
required to return these GPUs to normal operation when the system
|
||||
is later resumed. The NVIDIA Linux driver also supports S0ix-based
|
||||
s2idle system suspend (suspend-to-idle), if both the platform and
|
||||
the NVIDIA GPU support it.</p>
|
||||
<p>The GPU state saved by the NVIDIA kernel drivers includes
|
||||
allocations made in video memory. However, these allocations are
|
||||
collectively large, and typically cannot be evicted. Since the
|
||||
amount of system memory available to drivers at suspend time is
|
||||
often insufficient to accommodate large portions of video memory,
|
||||
the NVIDIA kernel drivers are designed to act conservatively, and
|
||||
normally only save essential video memory allocations.</p>
|
||||
<p>The resulting loss of video memory contents is partially
|
||||
compensated for by the user-space NVIDIA drivers, and by some
|
||||
applications, but can lead to failures such as rendering corruption
|
||||
and application crashes upon exit from power management cycles.</p>
|
||||
<p>To better support power management with these types of
|
||||
applications, the NVIDIA Linux driver provides a custom power
|
||||
management interface intended for integration with system
|
||||
management tools like <span><strong class=
|
||||
"command">systemd</strong></span>. This interface is still
|
||||
considered experimental. It is not used by default, but can be
|
||||
taken advantage of by configuring the system as described in this
|
||||
chapter.</p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name="Overview21f77" id=
|
||||
"Overview21f77"></a>Overview</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>The NVIDIA Linux driver supports the suspend and hibernate power
|
||||
management operations via two different mechanisms. In this
|
||||
section, each is summarized briefly with its capabilities and
|
||||
requirements:</p>
|
||||
<div class="variablelist">
|
||||
<dl>
|
||||
<dt><span class="term"><code class="computeroutput">Kernel driver
|
||||
callback</code></span></dt>
|
||||
<dd>
|
||||
<p>When this mechanism is used, the NVIDIA kernel driver receives
|
||||
callbacks from the Linux kernel to suspend, hibernate, and to
|
||||
resume each GPU for which a Linux PCI driver was registered. This
|
||||
is the default mechanism: it is enabled and used without explicit
|
||||
configuration.</p>
|
||||
<p>While this mechanism has no special requirements, yields good
|
||||
results with many workloads, and has been supported by the NVIDIA
|
||||
kernel driver in similar form for years, it suffers from a few
|
||||
limitations. Notably, it can only preserve a relatively small
|
||||
amount of video memory reliably, and it cannot support power
|
||||
management when advanced CUDA features are being used.</p>
|
||||
</dd>
|
||||
<dt><span class="term"><code class=
|
||||
"computeroutput">/proc/driver/nvidia/suspend</code></span></dt>
|
||||
<dd>
|
||||
<p>Instead of callbacks from the Linux kernel, this mechanism, when
|
||||
used, relies on a system management tool, such as
|
||||
<span><strong class="command">systemd</strong></span>, to issue
|
||||
suspend, hibernate, and resume commands to the NVIDIA kernel driver
|
||||
via the <code class=
|
||||
"computeroutput">/proc/driver/nvidia/suspend</code> interface. It
|
||||
is still considered experimental, and requires explicit
|
||||
configuration to use.</p>
|
||||
<p>If configured correctly, this mechanism is designed to remove
|
||||
the limitations of the kernel driver callback mechanism. It
|
||||
supports power management with advanced CUDA features (such as
|
||||
UVM), and it is capable of saving and restoring all video memory
|
||||
allocations.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"PreserveAllVide719f0" id="PreserveAllVide719f0"></a>Preserve all
|
||||
video memory allocations</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>To save potentially large portions of video memory, the NVIDIA
|
||||
driver supports the following two methods:</p>
|
||||
<div class="variablelist">
|
||||
<dl>
|
||||
<dt><span class="term"><code class="computeroutput">Save
|
||||
allocations in an unnamed temporary file</code></span></dt>
|
||||
<dd>
|
||||
<p>The NVIDIA driver uses an unnamed temporary file to save
|
||||
potentially large portions of video memory. By default, this file
|
||||
is created in <code class="filename">/tmp</code> during system
|
||||
suspend. This location can be changed with the <code class=
|
||||
"computeroutput">NVreg_TemporaryFilePath</code> nvidia.ko kernel
|
||||
module parameter, e.g. <code class=
|
||||
"computeroutput">NVreg_TemporaryFilePath=/run</code>. The
|
||||
destination file system needs to support unnamed temporary files,
|
||||
and it needs to be large enough to accommodate all the utilized
|
||||
video memory copies for the duration of the power management
|
||||
cycle.</p>
|
||||
<p>When determining a suitable size for the video memory backing
|
||||
store, it is recommended to start with the overall amount of video
|
||||
memory supported by the GPUs installed in the system. For example:
|
||||
<code class="computeroutput">nvidia-smi -q -d MEMORY |grep 'FB
|
||||
Memory Usage' -A1</code>. Each <code class=
|
||||
"computeroutput">Total</code> line returned by this command
|
||||
reflects one GPU's video memory capacity, in MiB. The sum of these
|
||||
numbers, plus 5% of margin, is a conservative starting point for
|
||||
the size of the video memory backing store.</p>
|
||||
<p>Please note that file systems such as <code class=
|
||||
"filename">/tmp</code> and <code class="filename">/run</code> are
|
||||
often of the type <code class="computeroutput">tmpfs</code>, and
|
||||
potentially relatively small. Most commonly, the size of the type
|
||||
of the file system used is controlled by <span><strong class=
|
||||
"command">systemd</strong></span>. For more information, see
|
||||
<a href=
|
||||
"https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems"
|
||||
target=
|
||||
"_top">https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems</a>.
|
||||
To achieve the best performance, file system types other than
|
||||
<code class="computeroutput">tmpfs</code> are recommended at this
|
||||
time.</p>
|
||||
<p>Additionally, to unlock the full functionality of the interface,
|
||||
the NVIDIA Linux kernel module <code class=
|
||||
"computeroutput">nvidia.ko</code> needs to be loaded with the
|
||||
<code class=
|
||||
"computeroutput">NVreg_PreserveVideoMemoryAllocations=1</code>
|
||||
module parameter. This changes the default video memory
|
||||
save/restore strategy to save and restore all video memory
|
||||
allocations. Also, the <code class=
|
||||
"computeroutput">/proc/driver/nvidia/suspend</code> power
|
||||
management mechanism (with a system management tool, such as
|
||||
<span><strong class="command">systemd</strong></span>) is required
|
||||
for using this interface.</p>
|
||||
</dd>
|
||||
<dt><span class="term"><code class="computeroutput">S0ix-based
|
||||
power management</code></span></dt>
|
||||
<dd>
|
||||
<p>If both the platform and the NVIDIA GPU support S0ix-based power
|
||||
management, then the NVIDIA Linux driver will put the GPU video
|
||||
memory in self refresh mode during <span><strong class=
|
||||
"command">s2idle</strong></span> system suspend. S0ix-based suspend
|
||||
will consume more power than legacy S3 system suspend, but it will
|
||||
enter and exit suspend/resume more quickly. Also, the
|
||||
suspend/resume latency will be constant irrespective of GPU video
|
||||
memory usage.</p>
|
||||
<p>To check the platform S0ix state support and required
|
||||
configuration, follow the steps mentioned in <a href=
|
||||
"https://01.org/blogs/qwang59/2018/how-achieve-s0ix-states-linux"
|
||||
target="_top">how-achieve-s0ix-states-linux</a></p>
|
||||
<p>To check if the NVIDIA GPU has support for S0ix-based power
|
||||
management, install the NVIDIA driver and run the following
|
||||
command:</p>
|
||||
<p><code class="computeroutput">grep 'Video Memory Self Refresh'
|
||||
/proc/driver/nvidia/gpus/<Domain>:<Bus>:<Device>.0/power</code></p>
|
||||
<p>For example:</p>
|
||||
<p><code class="computeroutput">grep 'Video Memory Self Refresh'
|
||||
/proc/driver/nvidia/gpus/0000\:01\:00.0/power</code></p>
|
||||
<p>If both the platform and the GPU support S0ix-based power
|
||||
management, then the S0ix support can be enabled in the NVIDIA
|
||||
Linux driver by setting the <code class=
|
||||
"computeroutput">nvidia.ko</code> kernel module parameter
|
||||
<code class="computeroutput">NVreg_EnableS0ixPowerManagement</code>
|
||||
to "1". With <code class=
|
||||
"computeroutput">NVreg_EnableS0ixPowerManagement</code> set to "1"
|
||||
and system suspend state set to <span><strong class=
|
||||
"command">s2idle</strong></span>, the NVIDIA Linux driver will
|
||||
calculate the video memory usage at system suspend time.</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>During the S0ix suspend, if video memory usage is less than a
|
||||
certain threshold, then the driver will copy video memory contents
|
||||
to system memory and power off the video memory along with the GPU.
|
||||
This will help in saving power.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>During the S0ix suspend, if video memory usage is above a
|
||||
certain threshold, then the video memory will be kept in
|
||||
self-refresh mode while the rest of the GPU is powered down.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p>By default, this threshold is 256 MB and it can be changed with
|
||||
the <code class=
|
||||
"computeroutput">NVreg_S0ixPowerManagementVideoMemoryThreshold</code>
|
||||
module parameter of <code class=
|
||||
"computeroutput">nvidia.ko</code>.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
</div>
|
||||
<p>All the module parameters can be set on the command line when
|
||||
loading the NVIDIA Linux kernel module <code class=
|
||||
"computeroutput">nvidia.ko</code>, or via the distribution's kernel
|
||||
module configuration files (such as those under
|
||||
/etc/modprobe.d).</p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"SystemdConfigur74e29" id=
|
||||
"SystemdConfigur74e29"></a><span><strong class=
|
||||
"command">systemd</strong></span> Configuration</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>This section is specific to the <code class=
|
||||
"filename">/proc/driver/nvidia/suspend</code> interface. This is
|
||||
required if using the <code class=
|
||||
"computeroutput">NVreg_PreserveVideoMemoryAllocations=1</code>
|
||||
kernel module parameter or advanced CUDA features (such as UVM).
|
||||
The NVIDIA Linux kernel driver requires no configuration if the
|
||||
default power management mechanism is used.</p>
|
||||
<p>In order to take advantage of the <code class=
|
||||
"filename">/proc</code> interface, a system management tool like
|
||||
<span><strong class="command">systemd</strong></span> needs to be
|
||||
configured to access it at appropriate times in the power
|
||||
management sequence. Specifically, the interface needs to be used
|
||||
to suspend or hibernate the NVIDIA kernel drivers just before
|
||||
writing to the Linux kernel's <code class=
|
||||
"filename">/sys/power/state</code> interface to request entry into
|
||||
the desired sleep state. The interface also needs to be used to
|
||||
resume the NVIDIA kernel drivers immediately after the return from
|
||||
a sleep state, as well as immediately after any unsuccessful
|
||||
attempts to suspend or hibernate.</p>
|
||||
<p>The following example configuration documents integration with
|
||||
the <span><strong class="command">systemd</strong></span> system
|
||||
and service manager, which is commonly used in modern GNU/Linux
|
||||
distributions to manage system start-up and various aspects of its
|
||||
operation. For systems not using <span><strong class=
|
||||
"command">systemd</strong></span>, the configuration files provided
|
||||
serve as a reference.</p>
|
||||
<p>The <span><strong class="command">systemd</strong></span>
|
||||
configuration uses the following files:</p>
|
||||
<div class="variablelist">
|
||||
<dl>
|
||||
<dt><span class="term"><code class=
|
||||
"computeroutput">/usr/lib/systemd/system/nvidia-suspend.service</code></span></dt>
|
||||
<dd>
|
||||
<p>A <span><strong class="command">systemd</strong></span> service
|
||||
description file used to instruct the system manager to write
|
||||
<code class="computeroutput">suspend</code> to the <code class=
|
||||
"filename">/proc/driver/nvidia/suspend</code> interface immediately
|
||||
before accessing <code class="filename">/sys/power/state</code> to
|
||||
suspend the system.</p>
|
||||
</dd>
|
||||
<dt><span class="term"><code class=
|
||||
"computeroutput">/usr/lib/systemd/system/nvidia-hibernate.service</code></span></dt>
|
||||
<dd>
|
||||
<p>A <span><strong class="command">systemd</strong></span> service
|
||||
description file used to instruct the system manager to write
|
||||
<code class="computeroutput">hibernate</code> to the <code class=
|
||||
"filename">/proc/driver/nvidia/suspend</code> interface immediately
|
||||
before accessing <code class="filename">/sys/power/state</code> to
|
||||
hibernate the system.</p>
|
||||
</dd>
|
||||
<dt><span class="term"><code class=
|
||||
"computeroutput">/usr/lib/systemd/system/nvidia-resume.service</code></span></dt>
|
||||
<dd>
|
||||
<p>A <span><strong class="command">systemd</strong></span> service
|
||||
description file used to instruct the system manager to write
|
||||
<code class="computeroutput">resume</code> to the <code class=
|
||||
"filename">/proc/driver/nvidia/suspend</code> interface immediately
|
||||
after returning from a system sleep state.</p>
|
||||
</dd>
|
||||
<dt><span class="term"><code class=
|
||||
"computeroutput">/lib/systemd/system-sleep/nvidia</code></span></dt>
|
||||
<dd>
|
||||
<p>A <span><strong class="command">systemd-sleep</strong></span>
|
||||
script file used to instruct the system manager to write
|
||||
<code class="computeroutput">resume</code> to the <code class=
|
||||
"filename">/proc/driver/nvidia/suspend</code> interface immediately
|
||||
after an unsuccessful attempt to suspend or hibernate the system
|
||||
via the <code class="filename">/proc/driver/nvidia/suspend</code>
|
||||
interface.</p>
|
||||
</dd>
|
||||
<dt><span class="term"><code class=
|
||||
"computeroutput">/usr/bin/nvidia-sleep.sh</code></span></dt>
|
||||
<dd>
|
||||
<p>A shell script used by the <span><strong class=
|
||||
"command">systemd</strong></span> service description files and the
|
||||
<span><strong class="command">systemd-sleep</strong></span> file to
|
||||
interact with the <code class=
|
||||
"filename">/proc/driver/nvidia/suspend</code> interface. The script
|
||||
also manages VT switching for the X server, which is currently
|
||||
needed by the NVIDIA X driver to support power management
|
||||
operations.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
</div>
|
||||
<p>These files are installed and enabled by nvidia-installer
|
||||
automatically if systemd is detected. Installation of systemd units
|
||||
can be disabled by specifying the <span><strong class=
|
||||
"command">--no-systemd</strong></span> installer option.</p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"ExercisingPower89cc2" id="ExercisingPower89cc2"></a>Exercising
|
||||
power management with <span><strong class=
|
||||
"command">systemd</strong></span></h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>This section is specific to the <code class=
|
||||
"filename">/proc/driver/nvidia/suspend</code> interface, when
|
||||
configured as described above. When the default power management
|
||||
mechanism is used instead, or when the <code class=
|
||||
"filename">/proc</code> interface is used without
|
||||
<span><strong class="command">systemd</strong></span>, then the use
|
||||
of <code class="computeroutput">systemctl</code> is not
|
||||
required.</p>
|
||||
<p>To suspend (suspend-to-RAM) or to hibernate (suspend-to-disk),
|
||||
respectively, use the following commands:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p><code class="computeroutput">sudo systemctl suspend</code></p>
|
||||
</li>
|
||||
<li>
|
||||
<p><code class="computeroutput">sudo systemctl hibernate</code></p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p>For the full list of sleep operations supported by
|
||||
<span><strong class="command">systemd</strong></span>, please see
|
||||
the systemd-suspend.service(8) man page.</p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"KnownIssuesAndWf438e" id="KnownIssuesAndWf438e"></a>Known Issues
|
||||
and Workarounds</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>On some systems, where the default suspend mode is <code class=
|
||||
"filename">"s2idle"</code>, the system may not resume properly due
|
||||
to a known timing issue in the kernel. The suspend mode can be
|
||||
verified by reading the contents of the file <code class=
|
||||
"filename">/sys/power/mem_sleep</code>. The following upstream
|
||||
kernel changes have been proposed to fix the issue:</p>
|
||||
<p><a href=
|
||||
"https://lore.kernel.org/linux-pci/20190927090202.1468-1-drake@endlessm.com/"
|
||||
target=
|
||||
"_top">https://lore.kernel.org/linux-pci/20190927090202.1468-1-drake@endlessm.com/</a></p>
|
||||
<p><a href=
|
||||
"https://lore.kernel.org/linux-pci/20190821124519.71594-1-mika.westerberg@linux.intel.com/"
|
||||
target=
|
||||
"_top">https://lore.kernel.org/linux-pci/20190821124519.71594-1-mika.westerberg@linux.intel.com/</a></p>
|
||||
<p>In the interim, the default suspend mode on the affected systems
|
||||
should be set to <code class="filename">"deep"</code> using the
|
||||
kernel command line parameter <code class=
|
||||
"filename">"mem_sleep_default"</code> -</p>
|
||||
<p><span><strong class=
|
||||
"command">mem_sleep_default=deep</strong></span></p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"procinterface.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"dynamicpowermanagement.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 20. Using the <code class=
|
||||
"computeroutput">/proc</code> File System Interface </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 22. PCI-Express Runtime D3 (RTD3) Power
|
||||
Management</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,232 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 35. PRIME Render Offload</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="randr14.html" title=
|
||||
"Chapter 34. Offloading Graphics Display with RandR 1.4">
|
||||
<link rel="next" href="kms.html" title=
|
||||
"Chapter 36. Direct Rendering Manager Kernel Modesetting (DRM KMS)">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 35. PRIME Render
|
||||
Offload</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"randr14.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"kms.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="primerenderoffload" id=
|
||||
"primerenderoffload"></a>Chapter 35. PRIME Render
|
||||
Offload</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>PRIME render offload is the ability to have an X screen rendered
|
||||
by one GPU, but choose certain applications within that X screen to
|
||||
be rendered on a different GPU. This is particularly useful in
|
||||
combination with dynamic power management to leave an NVIDIA GPU
|
||||
powered off except when it is needed to render select
|
||||
performance-sensitive applications.</p>
|
||||
<p>The GPU rendering the majority of the X screen is known as the
|
||||
"sink", and the GPU to which certain application rendering is
|
||||
"offloaded" is known as the "source". The render offload source
|
||||
produces content that is presented on the render offload sink. The
|
||||
NVIDIA driver can function as a PRIME render offload source, to
|
||||
offload rendering of GLX+OpenGL or Vulkan, presenting to an X
|
||||
screen driven by the xf86-video-modesetting X driver.</p>
|
||||
<p><a name="requirements" id="requirements"></a></p>
|
||||
<h3>X Server Requirements</h3>
|
||||
<p>NVIDIA's PRIME render offload support requires X.Org xserver
|
||||
version 1.20.7 or newer.</p>
|
||||
<p><a name="configurexscreen" id="configurexscreen"></a></p>
|
||||
<h3>Configure the X Server</h3>
|
||||
<p>On systems with both an integrated GPU and an NVIDIA discrete
|
||||
GPU, the X.Org X server version 1.20.7 and newer will automatically
|
||||
use NVIDIA's PRIME render offload support if the system BIOS is
|
||||
configured to boot on the iGPU and no other explicit configuration
|
||||
files are present. Note that some Linux distributions (such as
|
||||
Ubuntu) may configure the X server differently. Please refer to
|
||||
your distribution's documentation for details.</p>
|
||||
<p>If GPU screen creation was successful, the log file <code class=
|
||||
"filename">/var/log/Xorg.0.log</code> should contain lines with
|
||||
"NVIDIA(G0)", and querying the RandR providers with <code class=
|
||||
"computeroutput">xrandr --listproviders</code> should display a
|
||||
provider named "NVIDIA-G0" (for "NVIDIA GPU screen 0"). For
|
||||
example:</p>
|
||||
<pre class="screen">
|
||||
Providers: number : 2
|
||||
Provider 0: id: 0x221 cap: 0x9, Source Output, Sink Offload crtcs: 3 outputs: 6 associated providers: 0 name:modesetting
|
||||
Provider 1: id: 0x1f8 cap: 0x0 crtcs: 0 outputs: 0 associated providers: 0 name:NVIDIA-G0
|
||||
</pre>
|
||||
<p><a name="configureapplications" id=
|
||||
"configureapplications"></a></p>
|
||||
<h3>Configure Graphics Applications to Render Using the GPU
|
||||
Screen</h3>
|
||||
<p>To configure a graphics application to be offloaded to the
|
||||
NVIDIA GPU screen, set the environment variable <code class=
|
||||
"computeroutput">__NV_PRIME_RENDER_OFFLOAD</code> to <code class=
|
||||
"computeroutput">1</code>. If the graphics application uses Vulkan
|
||||
or EGL, that should be all that is needed. If the graphics
|
||||
application uses GLX, then also set the environment variable
|
||||
<code class="computeroutput">__GLX_VENDOR_LIBRARY_NAME</code> to
|
||||
<code class="computeroutput">nvidia</code>, so that GLVND loads the
|
||||
NVIDIA GLX driver.</p>
|
||||
<p>Examples:</p>
|
||||
<pre class="screen">
|
||||
__NV_PRIME_RENDER_OFFLOAD=1 vkcube
|
||||
__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia glxinfo | grep vendor
|
||||
</pre>
|
||||
<p></p>
|
||||
<p><a name="configureapplicationsvulkan" id=
|
||||
"configureapplicationsvulkan"></a></p>
|
||||
<h3>Finer-Grained Control of Vulkan</h3>
|
||||
<p>The <code class=
|
||||
"computeroutput">__NV_PRIME_RENDER_OFFLOAD</code> environment
|
||||
variable causes the special Vulkan layer <code class=
|
||||
"computeroutput">VK_LAYER_NV_optimus</code> to be loaded. Vulkan
|
||||
applications use the Vulkan API to enumerate the GPUs in the system
|
||||
and select which GPU to use; most Vulkan applications will use the
|
||||
first GPU reported by Vulkan. The <code class=
|
||||
"computeroutput">VK_LAYER_NV_optimus</code> layer causes the GPUs
|
||||
to be sorted such that the NVIDIA GPUs are enumerated first. For
|
||||
finer-grained control, the <code class=
|
||||
"computeroutput">VK_LAYER_NV_optimus</code> layer looks at the
|
||||
<code class="computeroutput">__VK_LAYER_NV_optimus</code>
|
||||
environment variable. The value <code class=
|
||||
"computeroutput">NVIDIA_only</code> causes <code class=
|
||||
"computeroutput">VK_LAYER_NV_optimus</code> to only report NVIDIA
|
||||
GPUs to the Vulkan application. The value <code class=
|
||||
"computeroutput">non_NVIDIA_only</code> causes <code class=
|
||||
"computeroutput">VK_LAYER_NV_optimus</code> to only report
|
||||
non-NVIDIA GPUs to the Vulkan application.</p>
|
||||
<p>Examples:</p>
|
||||
<pre class="screen">
|
||||
__NV_PRIME_RENDER_OFFLOAD=1 __VK_LAYER_NV_optimus=NVIDIA_only vkcube
|
||||
__NV_PRIME_RENDER_OFFLOAD=1 __VK_LAYER_NV_optimus=non_NVIDIA_only vkcube
|
||||
</pre>
|
||||
<p></p>
|
||||
<p><a name="configureapplicationsgl" id=
|
||||
"configureapplicationsgl"></a></p>
|
||||
<h3>Finer-Grained Control of OpenGL</h3>
|
||||
<p>For OpenGL with either GLX or EGL, the environment variable
|
||||
<code class=
|
||||
"computeroutput">__NV_PRIME_RENDER_OFFLOAD_PROVIDER</code> provides
|
||||
finer-grained control. While <code class=
|
||||
"computeroutput">__NV_PRIME_RENDER_OFFLOAD=1</code> tells GLX or
|
||||
EGL to use the first NVIDIA GPU screen, <code class=
|
||||
"computeroutput">__NV_PRIME_RENDER_OFFLOAD_PROVIDER</code> can use
|
||||
an RandR provider name to pick a specific NVIDIA GPU screen, using
|
||||
the NVIDIA GPU screen names reported by <code class=
|
||||
"computeroutput">`xrandr --listproviders`</code>.</p>
|
||||
<p>Examples:</p>
|
||||
<pre class="screen">
|
||||
__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia glxgears
|
||||
__NV_PRIME_RENDER_OFFLOAD_PROVIDER=NVIDIA-G0 __GLX_VENDOR_LIBRARY_NAME=nvidia glxgears
|
||||
__NV_PRIME_RENDER_OFFLOAD=1 eglinfo
|
||||
__NV_PRIME_RENDER_OFFLOAD_PROVIDER=NVIDIA-G0 eglinfo
|
||||
</pre>
|
||||
<p></p>
|
||||
<p><a name="renderoffloadtroubleshooting" id=
|
||||
"renderoffloadtroubleshooting"></a></p>
|
||||
<h3>Troubleshooting</h3>
|
||||
<p>After starting the X server, verify that the
|
||||
xf86-video-modesetting X driver is using "glamoregl". The log file
|
||||
<code class="filename">/var/log/Xorg.0.log</code> should contain
|
||||
something like this:</p>
|
||||
<pre class="screen">
|
||||
[1272173.618] (II) Loading sub module "glamoregl"
|
||||
[1272173.618] (II) LoadModule: "glamoregl"
|
||||
[1272173.618] (II) Loading /usr/lib/xorg/modules/libglamoregl.so
|
||||
[1272173.622] (II) Module glamoregl: vendor="X.Org Foundation"
|
||||
[1272173.622] compiled for 1.20.4, module version = 1.0.1
|
||||
[1272173.622] ABI class: X.Org ANSI C Emulation, version 0.4
|
||||
[1272173.638] (II) modeset(0): glamor X acceleration enabled on Mesa DRI Intel(R) HD Graphics 630 (Kaby Lake GT2)
|
||||
[1272173.638] (II) modeset(0): glamor initialized
|
||||
</pre>
|
||||
<p>If glamoregl could not be loaded, the X log may report something
|
||||
like:</p>
|
||||
<pre class="screen">
|
||||
[1271802.673] (II) Loading sub module "glamoregl"
|
||||
[1271802.673] (II) LoadModule: "glamoregl"
|
||||
[1271802.673] (WW) Warning, couldn't open module glamoregl
|
||||
[1271802.673] (EE) modeset: Failed to load module "glamoregl" (module does not exist, 0)
|
||||
[1271802.673] (EE) modeset(0): Failed to load glamor module.
|
||||
</pre>
|
||||
<p>in which case, consult your distribution's documentation for how
|
||||
to (re-)install the package containing glamoregl.</p>
|
||||
<p>If the server didn't create a GPU screen automatically, ensure
|
||||
that the nvidia_drm kernel module is loaded. This should normally
|
||||
happen by default, but you can confirm by running <code class=
|
||||
"computeroutput">lsmod | grep nvidia_drm</code> to see if the
|
||||
kernel module is loaded. Run <code class="computeroutput">modprobe
|
||||
nvidia_drm</code> to load it.</p>
|
||||
<p>If automatic configuration does not work, it may be necessary to
|
||||
explicitly configure the iGPU and dGPU devices in xorg.conf:</p>
|
||||
<pre class="screen">
|
||||
Section "ServerLayout"
|
||||
Identifier "layout"
|
||||
Screen 0 "iGPU"
|
||||
EndSection
|
||||
|
||||
Section "Device"
|
||||
Identifier "iGPU"
|
||||
Driver "modesetting"
|
||||
EndSection
|
||||
|
||||
Section "Screen"
|
||||
Identifier "iGPU"
|
||||
Device "iGPU"
|
||||
EndSection
|
||||
|
||||
Section "Device"
|
||||
Identifier "dGPU"
|
||||
Driver "nvidia"
|
||||
EndSection
|
||||
</pre></div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"randr14.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"kms.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 34. Offloading Graphics Display with RandR
|
||||
1.4 </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 36. Direct Rendering Manager Kernel
|
||||
Modesetting (DRM KMS)</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,132 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 20. Using the /proc File System
|
||||
Interface</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="flippingubb.html" title=
|
||||
"Chapter 19. Configuring Flipping and UBB">
|
||||
<link rel="next" href="powermanagement.html" title=
|
||||
"Chapter 21. Configuring Power Management Support">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 20. Using the
|
||||
<code class="computeroutput">/proc</code> File System
|
||||
Interface</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"flippingubb.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"powermanagement.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="procinterface" id=
|
||||
"procinterface"></a>Chapter 20. Using the <code class=
|
||||
"computeroutput">/proc</code> File System Interface</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>The NVIDIA <code class="filename">/proc</code> file system
|
||||
interface can be used to obtain run-time information about the
|
||||
NVIDIA kernel driver and about the NVIDIA GPUs present in the
|
||||
system. It can also be used to control some aspects of the NVIDIA
|
||||
driver's operation.</p>
|
||||
<p>This information is contained in several files in <code class=
|
||||
"filename">/proc/driver/nvidia</code>:</p>
|
||||
<div class="variablelist">
|
||||
<dl>
|
||||
<dt><span class="term"><code class=
|
||||
"filename">/proc/driver/nvidia/version</code></span></dt>
|
||||
<dd>
|
||||
<p>Lists the installed driver revision and the version of the GNU C
|
||||
compiler used to build the Linux kernel module.</p>
|
||||
</dd>
|
||||
<dt><span class="term"><code class=
|
||||
"filename">/proc/driver/nvidia/warnings</code></span></dt>
|
||||
<dd>
|
||||
<p>The NVIDIA graphics driver tries to detect potential problems
|
||||
with the host system's kernel and warns about them using the
|
||||
kernel's <code class="computeroutput">printk()</code> mechanism,
|
||||
typically logged by the system to <code class=
|
||||
"filename">/var/log/messages</code>.</p>
|
||||
<p>Important NVIDIA warning messages are also logged to dedicated
|
||||
text files in this <code class="filename">/proc</code>
|
||||
directory.</p>
|
||||
</dd>
|
||||
<dt><span class="term"><code class=
|
||||
"filename">/proc/driver/nvidia/gpus/domain:bus:device.function/information</code></span></dt>
|
||||
<dd>
|
||||
<p>Provide information about each of the installed NVIDIA GPUs
|
||||
(model name, IRQ, BIOS version, etc.). Note that some of the
|
||||
information is only available when the GPUs have been
|
||||
initialized.</p>
|
||||
</dd>
|
||||
<dt><span class="term"><code class=
|
||||
"filename">/proc/driver/nvidia/gpus/domain:bus:device.function/power</code></span></dt>
|
||||
<dd>
|
||||
<p>Provide information about the runtime D3 (RTD3) Power Management
|
||||
status of each of the installed NVIDIA GPUs. Note that some of the
|
||||
information is only available when the GPUs have been initialized.
|
||||
Please see <a href="dynamicpowermanagement.html" title=
|
||||
"Chapter 22. PCI-Express Runtime D3 (RTD3) Power Management">
|
||||
Chapter 22, <i>PCI-Express Runtime D3 (RTD3) Power
|
||||
Management</i></a> for the detailed description of this
|
||||
<code class="filename">/proc</code> interface.</p>
|
||||
</dd>
|
||||
<dt><span class="term"><code class=
|
||||
"filename">/proc/driver/nvidia/suspend</code></span></dt>
|
||||
<dd>
|
||||
<p>Notify the NVIDIA kernel drivers of system power management
|
||||
events, such as suspend and hibernate. Please see <a href=
|
||||
"powermanagement.html" title=
|
||||
"Chapter 21. Configuring Power Management Support">Chapter 21,
|
||||
<i>Configuring Power Management Support</i></a> for a detailed
|
||||
description of this <code class="filename">/proc</code>
|
||||
interface.</p>
|
||||
</dd>
|
||||
</dl>
|
||||
</div>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"flippingubb.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"powermanagement.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 19. Configuring Flipping and UBB </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 21. Configuring Power Management
|
||||
Support</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,793 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Appendix J. Application Profiles</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="appendices.html" title=
|
||||
"Part II. Appendices">
|
||||
<link rel="prev" href="newusertips.html" title=
|
||||
"Appendix I. Tips for New Linux Users">
|
||||
<link rel="next" href="gpunames.html" title=
|
||||
"Appendix K. GPU Names">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Appendix J. Application
|
||||
Profiles</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"newusertips.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part II. Appendices</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"gpunames.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="appendix" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="profiles" id=
|
||||
"profiles"></a>Appendix J. Application Profiles</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="toc">
|
||||
<p><b>Table of Contents</b></p>
|
||||
<dl>
|
||||
<dt><span class="section"><a href=
|
||||
"profiles.html#Introductionec914">Introduction</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"profiles.html#EnablingApplicaba0fc">Enabling Application Profiles
|
||||
in the OpenGL Driver</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"profiles.html#ApplicationProf9ccbe">Application Profile Search
|
||||
Path</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"profiles.html#ConfigurationFi1ec50">Configuration File
|
||||
Syntax</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"profiles.html#ExtendedBackusn4e5af">Extended Backus-Naur Form
|
||||
(EBNF) grammar</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"profiles.html#RulePrecedence6f323">Rule Precedence</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"profiles.html#ConfigurationFie7ae2">Configuration File
|
||||
Example</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"profiles.html#SupportedFeatura8d39">Supported
|
||||
Features</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"profiles.html#ListOfSupportedd38df">List of supported application
|
||||
profile settings</a></span></dt>
|
||||
</dl>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name="Introductionec914"
|
||||
id="Introductionec914"></a>Introduction</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>The NVIDIA Linux driver supports configuring various driver
|
||||
settings on a per-process basis through the use of "application
|
||||
profiles": collections of settings that are only applied if the
|
||||
current process matches attributes detected by the driver when it
|
||||
is loaded into the process. This mechanism allows users to
|
||||
selectively override global driver settings for a particular
|
||||
application without the need to set environment variables on the
|
||||
command line prior to running the application.</p>
|
||||
<p>Application profiles consist of "rules" and "profiles". A
|
||||
"profile" defines what settings to use, and a "rule" identifies an
|
||||
application and defines what profile should be used with that
|
||||
application.</p>
|
||||
<p>A rule identifies an application by describing various features
|
||||
of the application; for example, the name of the application binary
|
||||
(e.g. "glxgears") or a shared library loaded into the application
|
||||
(e.g. "libpthread.so.0"). The particular features supported by this
|
||||
NVIDIA Linux implementation are listed below in the "Supported
|
||||
Features" section.</p>
|
||||
<p>Currently, application profiles are only supported by the NVIDIA
|
||||
Linux GLX implementation, but other NVIDIA driver components may
|
||||
use them in the future.</p>
|
||||
<p>Application profiles can be configured using the nvidia-settings
|
||||
control panel. To learn more, consult the online help text by
|
||||
clicking the "Help" button under the "Application Profiles" page in
|
||||
nvidia-settings.</p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"EnablingApplicaba0fc" id="EnablingApplicaba0fc"></a>Enabling
|
||||
Application Profiles in the OpenGL Driver</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>Note: if HOME is unset, then any configuration files listed
|
||||
below located under $HOME will not be loaded by the driver.</p>
|
||||
<p>To enable application profile support globally on a system, edit
|
||||
the file $HOME/.nv/nvidia-application-profile-globals-rc to contain
|
||||
a JSON object with a member "enabled" set to true or false. For
|
||||
example, if this file contains the following string:</p>
|
||||
<pre class="screen">
|
||||
{ "enabled" : true }
|
||||
</pre>
|
||||
<p>application profiles will be enabled globally in the driver. If
|
||||
this file does not exist or cannot be read by the parser,
|
||||
application profiles will be enabled by default.</p>
|
||||
<p>Application profile support in the driver can be toggled for an
|
||||
individual application by using the __GL_APPLICATION_PROFILE
|
||||
environment variable. Setting this to 1 enables application profile
|
||||
support, and setting this to 0 disables application profile
|
||||
support. If this environment variable is set, this overrides any
|
||||
setting specified in
|
||||
$HOME/.nv/nvidia-application-profile-globals-rc.</p>
|
||||
<p>Additionally, the application profile parser can log debugging
|
||||
information to stderr if the __GL_APPLICATION_PROFILE_LOG
|
||||
environment variable is set to 1. Conversely, setting
|
||||
__GL_APPLICATION_PROFILE_LOG to 0 disables logging of parse
|
||||
information to stderr.</p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"ApplicationProf9ccbe" id="ApplicationProf9ccbe"></a>Application
|
||||
Profile Search Path</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>By default, when the driver component ("libGL.so.1" in the case
|
||||
of GLX) is loaded by a process, the driver looks for files in the
|
||||
following search path:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p><code class=
|
||||
"filename">$HOME/.nv/nvidia-application-profiles-rc</code></p>
|
||||
</li>
|
||||
<li>
|
||||
<p><code class=
|
||||
"filename">$HOME/.nv/nvidia-application-profiles-rc.d</code></p>
|
||||
</li>
|
||||
<li>
|
||||
<p><code class=
|
||||
"filename">/etc/nvidia/nvidia-application-profiles-rc</code></p>
|
||||
</li>
|
||||
<li>
|
||||
<p><code class=
|
||||
"filename">/etc/nvidia/nvidia-application-profiles-rc.d</code></p>
|
||||
</li>
|
||||
<li>
|
||||
<p><code class=
|
||||
"filename">/usr/share/nvidia/nvidia-application-profiles-535.161.07-rc</code></p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p>By convention, the <code class="filename">*-rc.d</code> files
|
||||
are directories and the <code class="filename">*-rc</code> files
|
||||
are regular files, but the driver places no restrictions on file
|
||||
type, and any of the above files can be a directory or regular
|
||||
file, or a symbolic link which resolves to a directory or regular
|
||||
file. Files of other types (e.g. character or block devices,
|
||||
sockets, and named pipes) will be ignored.</p>
|
||||
<p>If a file in the search path is a directory, the parser will
|
||||
examine all regular files (or symbolic links which resolve to
|
||||
regular files) in that directory in alphanumeric order, as
|
||||
determined by strcoll(3). Files in the directory of other types
|
||||
(e.g. other directories, character or block devices, sockets, and
|
||||
named pipes) will be ignored.</p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"ConfigurationFi1ec50" id="ConfigurationFi1ec50"></a>Configuration
|
||||
File Syntax</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>When application profiles are enabled in the driver, the driver
|
||||
configuration is defined by a set of <span class=
|
||||
"emphasis"><em>profiles</em></span> and <span class=
|
||||
"emphasis"><em>rules</em></span>. Profiles are collections of
|
||||
driver settings given as key/value pairs, and rules are mappings
|
||||
between one or more <span class="emphasis"><em>patterns</em></span>
|
||||
which match against some feature of the process and a profile.</p>
|
||||
<p>Configuration files are written in a superset of JSON (<a href=
|
||||
"http://www.json.org/" target="_top">http://www.json.org/</a>) with
|
||||
the following additional features:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>A hash mark ('#') appearing outside of a JSON string denotes a
|
||||
comment, and any text appearing between the hash mark and the end
|
||||
of the line inclusively is ignored.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Integers can be specified in base 8 or 16, in addition to base
|
||||
10. Numbers beginning with '0' and followed by a digit are
|
||||
interpreted to be octal, and numbers beginning with '0' and
|
||||
followed by 'x' or 'X' are interpreted to be hexadecimal.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
<p>Each file consists of a root object with two optional
|
||||
members:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>"rules", which contains an array of rules, and</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"profiles", which contains an array of profiles.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p>Each rule is an object with the following members:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>"pattern", which contains either a string, a pattern object, or
|
||||
an array of zero or more pattern objects. If a string is given, it
|
||||
is interpreted to be a pattern object with the "feature" member set
|
||||
to "procname" and the "matches" member set to the value of the
|
||||
string. During application detection, the driver determines if each
|
||||
pattern in the rule matches the running process, and only applies
|
||||
the rule if all patterns in the rule match. If an empty array is
|
||||
given, the rule is unconditionally applied.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"profile", which contains either a string, array, or profile. If
|
||||
a string is given, it is interpreted to be the name of some profile
|
||||
in the configuration. If a profile is given, it is implicitly
|
||||
defined as part of the rule. If an array is given, the array is
|
||||
interpreted to be an inline profile with its "settings" member set
|
||||
to the contents of the array.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p>Each profile is an object with the following members:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>"name", a string which names the profile for use in a rule. This
|
||||
member is mandatory if the profile is specified as part of the root
|
||||
object's profiles array, but optional if the profile is defined
|
||||
inline as part of a rule.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"settings", an array of settings which can be given in two
|
||||
different formats:</p>
|
||||
<div class="orderedlist">
|
||||
<ol type="1">
|
||||
<li>
|
||||
<p>As an array of keys and values, e.g.</p>
|
||||
<pre class="screen">
|
||||
[ "key1", "value1", "key2", 3.14159, "key3", 0xF00D ]
|
||||
</pre>
|
||||
<p>Keys must be specified as strings, while a value may be a
|
||||
string, number, or true/false.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>as an array of JSON setting objects.</p>
|
||||
</li>
|
||||
</ol>
|
||||
</div>
|
||||
<p></p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p>Each setting object contains the following members:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>"k" (or "key"), the key given as a string</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"v" (or "value"), the value, given as a string, number, or
|
||||
true/false.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p>A pattern object may consist of a pattern primitive, or a
|
||||
logical operation on pattern objects. A pattern primitive is an
|
||||
object containing the following members:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>"feature", the feature to match the pattern against. Supported
|
||||
features are listed in the "Supported Features" section below.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"matches", the string to match.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p>A pattern operation is an object containing the following
|
||||
members:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>"op", a string describing the logical operation to apply to the
|
||||
subpatterns. Valid values are "and", "or", or "not".</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"sub": a pattern object or array of one or more pattern objects,
|
||||
to serve as the operands. Note that the "not" operator expects
|
||||
exactly one object; any other number of objects will cause the
|
||||
pattern to fail to match.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p>If the pattern is an operation, then the pattern matches if and
|
||||
only if the logical operation applied to the subpatterns is true.
|
||||
For example,</p>
|
||||
<pre class="screen">
|
||||
{
|
||||
"op" : "or",
|
||||
"sub" : [ { "feature" : "procname", "matches" : "foo" },
|
||||
{ "feature" : "procname", "matches" : "bar" } ]
|
||||
}
|
||||
</pre>
|
||||
<p>matches all processes with the name "foo" *or* "bar".
|
||||
Similarly,</p>
|
||||
<pre class="screen">
|
||||
{
|
||||
"op" : "and",
|
||||
"sub" : [ { "feature" : "procname", "matches" : "foo" },
|
||||
{ "feature" : "dso", "matches" : "bar.so" } ]
|
||||
}
|
||||
</pre>
|
||||
<p>matches all processes with the name "foo" that load DSO
|
||||
"bar.so", and</p>
|
||||
<pre class="screen">
|
||||
{
|
||||
"op" : "not",
|
||||
"sub" : { "feature" : "procname", "matches" : "foo" }
|
||||
}
|
||||
</pre>
|
||||
<p>matches a process which is *not* named "foo". Nested operations
|
||||
are possible; for example:</p>
|
||||
<pre class="screen">
|
||||
{
|
||||
"op" : "and",
|
||||
"sub" : [
|
||||
{ "feature" : "dso", "matches" : "foo.so" },
|
||||
{ "op" : "not", "sub" : { "feature" : "procname", "matches" : "bar" } }
|
||||
]
|
||||
}
|
||||
</pre>
|
||||
<p>matches processes that are *not* named "bar" that load DSO
|
||||
"foo.so".</p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"ExtendedBackusn4e5af" id="ExtendedBackusn4e5af"></a>Extended
|
||||
Backus-Naur Form (EBNF) grammar</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>Note: this definition omits the presence of whitespace or
|
||||
comments, which can be inserted between any pair of symbols.</p>
|
||||
<p>This is written in an "EBNF-like" grammar based on ISO/IEC
|
||||
14977, using the following (non-EBNF) extensions:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>object(A, B, ...) indicates that each symbol A, B, etc. must
|
||||
appear exactly once in any order, delimited by commas and bracketed
|
||||
by curly braces, unless the given symbol expands to an empty
|
||||
string.</p>
|
||||
<p>For example, assuming A and B are nonempty symbols:</p>
|
||||
<pre class="screen">
|
||||
object(A, B) ;
|
||||
</pre>
|
||||
<p>is equivalent to:</p>
|
||||
<pre class="screen">
|
||||
'{', (A, ',', B) | (B, ',', A), '}' ;
|
||||
</pre>
|
||||
<p>Also,</p>
|
||||
<pre class="screen">
|
||||
object([A], [B]);
|
||||
</pre>
|
||||
<p>is equivalent to:</p>
|
||||
<pre class="screen">
|
||||
'{', [ A | B | (A, ',', B) | (B, ',', A) ], '}' ;
|
||||
</pre>
|
||||
<p></p>
|
||||
</li>
|
||||
<li>
|
||||
<p>attr(str, A) is shorthand for:</p>
|
||||
<pre class="screen">
|
||||
( '"str"' | "'str'" ), ':', A
|
||||
</pre>
|
||||
<p></p>
|
||||
</li>
|
||||
<li>
|
||||
<p>array(A) is shorthand for:</p>
|
||||
<pre class="screen">
|
||||
'[', [ array_A ], ']'
|
||||
</pre>
|
||||
<p>where array_A is defined as:</p>
|
||||
<pre class="screen">
|
||||
array_A = (array_A, ',' A) | A
|
||||
</pre>
|
||||
<p></p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p>The grammar follows.</p>
|
||||
<pre class="screen">
|
||||
config_file = object( [ attr(rules, array(rule)) ] ,
|
||||
[ attr(profiles, array(profile)) ] ) ;
|
||||
rule = object(attr(pattern, pattern_object | array(pattern_object)),
|
||||
attr(profile, profile_ref)) ;
|
||||
pattern_object = pattern_op | pattern_primitive ;
|
||||
pattern_op = object(attr(op, string),
|
||||
attr(sub, pattern_object | array(pattern_object))) ;
|
||||
pattern_primitive = object(attr(feature, string),
|
||||
attr(matches, string)) ;
|
||||
profile_ref = string | settings | rule_profile ;
|
||||
profile = object(attr(name, string),
|
||||
attr(settings,
|
||||
(array(setting_kv) | array(setting_obj)))) ;
|
||||
rule_profile = object([ attr(name, string) ],
|
||||
attr(settings,
|
||||
(array(setting_kv) | array(setting_obj)))) ;
|
||||
setting_kv = string ',' value ;
|
||||
setting_obj = object(attr(k,string) | attr(key,string),
|
||||
attr(v,value) | attr(value,value)) ;
|
||||
string = ? any valid json string ? ;
|
||||
value = ? any valid json number ? | 'true' | 'false' |
|
||||
hex_value | oct_value ;
|
||||
hex_value = '0', ('x' | 'x'), hex_digit, { hex_digit } ;
|
||||
oct_value = '0', oct_digit, { oct_digit } ;
|
||||
hex_digit = ? any character in the range [0-9a-fA-F] ? ;
|
||||
oct_digit = ? any character in the range [0-7] ? ;
|
||||
|
||||
</pre>
|
||||
<p></p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name="RulePrecedence6f323"
|
||||
id="RulePrecedence6f323"></a>Rule Precedence</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>Profiles may be specified in any order, and rules defined in
|
||||
files earlier in the search path may refer to profiles defined
|
||||
later in the search path.</p>
|
||||
<p>Rules are prioritized based on the order in which they are
|
||||
defined: each rule has precedence over rules defined after it in
|
||||
the same file, and rules defined in a file have precedence over
|
||||
rules defined in files that come after that file in the search
|
||||
path.</p>
|
||||
<p>For example, if there are two files A and B, such that A comes
|
||||
before B in the search path, with the following contents:</p>
|
||||
<pre class="screen">
|
||||
# File A
|
||||
{
|
||||
"rules" : [ { "pattern" : "foo",
|
||||
"profile" : [ "a", 1 ] },
|
||||
{ "pattern" : "foo",
|
||||
"profile" : [ "a", 0, "b", 2 ] } ]
|
||||
}
|
||||
|
||||
# File B
|
||||
{
|
||||
"rules" : [ { "pattern" : "foo",
|
||||
"profile" : [ "a", 0, "b", 0, "c", 3 ] } ]
|
||||
}
|
||||
|
||||
</pre>
|
||||
<p>and the driver is loaded into a process with the name "foo", it
|
||||
will apply the settings "a" = 1, "b" = 2, and "c" = 3.</p>
|
||||
<p>Settings specified via application profiles have higher
|
||||
precedence than global settings specified in nvidia-settings, but
|
||||
lower precedence than settings specified directly via environment
|
||||
variables.</p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"ConfigurationFie7ae2" id="ConfigurationFie7ae2"></a>Configuration
|
||||
File Example</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>The following is a sample configuration file which demonstrates
|
||||
the various ways one can specify application profiles and rules for
|
||||
different processes.</p>
|
||||
<pre class="screen">
|
||||
{
|
||||
"rules" : [
|
||||
|
||||
# Define a rule with an inline profile, (implicitly) using
|
||||
# feature "procname".
|
||||
{ "pattern" : "glxgears", "profile" : [ "GLSyncToVBlank", "1" ] },
|
||||
|
||||
# Define a rule with a named profile, (implicitly) using feature
|
||||
# "procname".
|
||||
{ "pattern" : "gloss", "profile" : "p0" },
|
||||
|
||||
# Define a rule with a named profile, using feature "dso".
|
||||
{ "pattern" : { "feature" : "dso", "matches" : "libpthread.so.0" },
|
||||
"profile" : "p1" },
|
||||
|
||||
# Define a rule with a named, inline profile, using feature "true";
|
||||
# patterns using this feature will always match, and can be used
|
||||
# to write catch-all rules.
|
||||
{ "pattern" : { "feature" : "true", "matches" : "" },
|
||||
"profile" : { "name" : "p2",
|
||||
"settings" : [ "GLSyncToVBlank", 1 ] } },
|
||||
|
||||
# Define a rule with multiple patterns. This rule will only be
|
||||
# applied if the current process is named "foo" and has loaded
|
||||
# "bar.so".
|
||||
{ "pattern" : [ { "feature" : "procname", "matches" : "foo" },
|
||||
{ "feature" : "dso", "matches" : "bar.so" } ],
|
||||
"profile" : "p1" },
|
||||
|
||||
# Define a rule with no patterns. This rule will always be applied.
|
||||
{ "pattern" : [], "profile" : "p1" }
|
||||
|
||||
],
|
||||
"profiles" : [
|
||||
|
||||
# define a profile with settings defined in a key/value array
|
||||
{ "name" : "p0", "settings" : [ "GLSyncToVBlank", 0 ] },
|
||||
|
||||
# define a profile with settings defined in an array of setting
|
||||
# objects
|
||||
{ "name" : "p1", "settings" : [ { "k" : "GLDoom3", "v" : false } ] }
|
||||
|
||||
]
|
||||
}
|
||||
|
||||
</pre>
|
||||
<p></p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"SupportedFeatura8d39" id="SupportedFeatura8d39"></a>Supported
|
||||
Features</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>This NVIDIA Linux driver supports detection of the following
|
||||
features:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>"true": patterns using this feature will always match,
|
||||
regardless of the contents of the string provided by "matches".</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"procname": patterns using this feature compare the string
|
||||
provided by "matches" against the pathname of the current process
|
||||
with the leading directory components removed and match if they are
|
||||
equal.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"commname": patterns using this feature compare the string
|
||||
provided by "matches" against the commandname of the current
|
||||
process, as stored in /proc/self/comm.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"cmdline": patterns using this feature compare the string
|
||||
provided by "matches" against the argument 0 of the command line
|
||||
for the current process, as stored in /proc/self/cmdline (with
|
||||
leading directory components removed, separated by slashes and
|
||||
backslashes).</p>
|
||||
<p>This is useful for applications and games running through Wine.
|
||||
For example "glxgears" would match a process started with
|
||||
"/usr/bin/glxgears" or "notepad.exe" would match a process started
|
||||
with "wine C:\Windows\notepad.exe".</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"dso": patterns using this feature compare the string provided
|
||||
by "matches" against the list of currently loaded libraries in the
|
||||
current process and match if the string matches one of the entries
|
||||
in the list (with leading directory components removed).</p>
|
||||
<p>Please note that application detection occurs when the driver
|
||||
component ("libGL.so.1" in the case of GLX) is first loaded by a
|
||||
process, so a pattern using this feature may fail to match if the
|
||||
library specified by the pattern is loaded after the component is
|
||||
loaded. A potential workaround for this on Linux is to set the
|
||||
LD_PRELOAD environment variable (see ld-linux(8)) to include the
|
||||
component, as in the following example:</p>
|
||||
<pre class="screen">
|
||||
LD_PRELOAD="libGL.so.1" glxgears
|
||||
</pre>
|
||||
<p>Note this defeats one of the objectives of application detection
|
||||
(namely the need to set environment variables on the command line
|
||||
before running the application), but this may be useful when there
|
||||
is a need to frequently change driver settings for a particular
|
||||
application: one can write a wrapper script to set LD_PRELOAD once,
|
||||
then modify the JSON configuration repeatedly without needing to
|
||||
edit the wrapper script later on.</p>
|
||||
<p>Also note that the pattern matches against library names as they
|
||||
appear in the maps file of that process (see proc(5)), and not the
|
||||
names of symbolic links to these libraries.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"findfile": patterns using this feature should provide a
|
||||
colon-separated list of filenames in the "matches" argument. At
|
||||
runtime, the driver scans the directory of the process executable
|
||||
and matches the pattern if every file specified in this list is
|
||||
present in the same directory. Please note there is currently no
|
||||
support for matching against files in other paths than the process
|
||||
executable directory.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"ListOfSupportedd38df" id="ListOfSupportedd38df"></a>List of
|
||||
supported application profile settings</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>The list of supported application profile settings and their
|
||||
equivalent environment variable names (if any) is as follows:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>"GLFSAAMode" : see __GL_FSAA_MODE</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"GLLogMaxAniso" : see __GL_LOG_MAX_ANISO</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"GLNoDsoFinalizer" : see __GL_NO_DSO_FINALIZER</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"GLSingleThreaded" : see __GL_SINGLE_THREADED</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"GLSyncDisplayDevice" : see __GL_SYNC_DISPLAY_DEVICE</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"GLSyncToVblank" : see __GL_SYNC_TO_VBLANK</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"GLSortFbconfigs" : see __GL_SORT_FBCONFIGS</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"GLAllowUnofficialProtocol" : see
|
||||
__GL_ALLOW_UNOFFICIAL_PROTOCOL</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"GLSELinuxBooleans" : see __GL_SELINUX_BOOLEANS</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"GLShaderDiskCache" : see __GL_SHADER_DISK_CACHE</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"GLShaderDiskCachePath" : see __GL_SHADER_DISK_CACHE_PATH</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"GLYield" : see __GL_YIELD</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"GLThreadedOptimizations" : see __GL_THREADED_OPTIMIZATIONS</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"GLDoom3" : see __GL_DOOM3</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"GLExtensionStringVersion" : see __GL_ExtensionStringVersion</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"GLConformantBlitFramebufferScissor" : see
|
||||
__GL_ConformantBlitFramebufferScissor</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"GLAllowFXAAUsage" : see __GL_ALLOW_FXAA_USAGE</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"GLVRRAllowed" : see __GL_VRR_ALLOWED</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"GLWriteTextSection" : see __GL_WRITE_TEXT_SECTION</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"GLIgnoreGLSLExtReqs" : see __GL_IGNORE_GLSL_EXT_REQS</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"EGLVisibleDGPUDevices"</p>
|
||||
<p>On a multi-device system, this option can be used to make EGL
|
||||
ignore certain devices. This setting takes a 32-bit mask encoding a
|
||||
whitelist of visible devices. The bit position matches the minor
|
||||
number of the device to make visible.</p>
|
||||
<p>For instance, the profile</p>
|
||||
<pre class="screen">
|
||||
{
|
||||
"rules" : [
|
||||
{ "pattern" : [],
|
||||
"profile" : [ "EGLVisibleDGPUDevices", 0x00000002 ] }
|
||||
]
|
||||
}
|
||||
|
||||
</pre>
|
||||
<p>would only make the device with minor number 1 visible (i.e.
|
||||
/dev/nvidia1).</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"EGLVisibleTegraDevices" : Same semantics as
|
||||
EGLVisibleDGPUDevices</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"GLShowGraphicsOSD" : see __GL_SHOW_GRAPHICS_OSD</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"GLSharpenEnable" : see __GL_SHARPEN_ENABLE</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"GLSharpenValue" : see __GL_SHARPEN_VALUE</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>"GLSharpenIgnoreFilmGrain" : see
|
||||
__GL_SHARPEN_IGNORE_FILM_GRAIN</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"newusertips.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"appendices.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"gpunames.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Appendix I. Tips for New Linux Users </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Appendix K. GPU Names</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,412 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 18. Programming Modes</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="optimus.html" title=
|
||||
"Chapter 17. Using the NVIDIA Driver with Optimus Laptops">
|
||||
<link rel="next" href="flippingubb.html" title=
|
||||
"Chapter 19. Configuring Flipping and UBB">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 18. Programming
|
||||
Modes</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"optimus.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"flippingubb.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="programmingmodes" id=
|
||||
"programmingmodes"></a>Chapter 18. Programming Modes</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>The NVIDIA Accelerated Linux Graphics Driver supports all
|
||||
standard VGA and VESA modes, as well as most user-written custom
|
||||
mode lines.</p>
|
||||
<p>To request one or more standard modes for use in X, you can
|
||||
simply add a "Modes" line such as:</p>
|
||||
<pre class="screen">
|
||||
Modes "1600x1200" "1024x768" "640x480"
|
||||
</pre>
|
||||
<p>in the appropriate Display subsection of your X config file (see
|
||||
the xorg.conf man page for details). Or, the nvidia-xconfig(1)
|
||||
utility can be used to request additional modes; for example:</p>
|
||||
<pre class="screen">
|
||||
nvidia-xconfig --mode 1600x1200
|
||||
</pre>
|
||||
<p>See the nvidia-xconfig(1) man page for details.</p>
|
||||
<h3>Depth, Bits per Pixel, and Pitch</h3>
|
||||
<p>While not directly a concern when programming modes, the bits
|
||||
used per pixel is an issue when considering the maximum
|
||||
programmable resolution; for this reason, it is worthwhile to
|
||||
address the confusion surrounding the terms "depth" and "bits per
|
||||
pixel". Depth is how many bits of data are stored per pixel.
|
||||
Supported depths are 8, 15, 16, 24, and 30. Most video hardware,
|
||||
however, stores pixel data in sizes of 8, 16, or 32 bits; this is
|
||||
the amount of memory allocated per pixel. When you specify your
|
||||
depth, X selects the bits per pixel (bpp) size in which to store
|
||||
the data. Below is a table of what bpp is used for each possible
|
||||
depth:</p>
|
||||
<div class="informaltable">
|
||||
<table summary="(no summary available)" border="0">
|
||||
<colgroup>
|
||||
<col>
|
||||
<col></colgroup>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Depth</th>
|
||||
<th>BPP</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>8</td>
|
||||
<td>8</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>15</td>
|
||||
<td>16</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>16</td>
|
||||
<td>16</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>24</td>
|
||||
<td>32</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>30</td>
|
||||
<td>32</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<p>Lastly, the "pitch" is how many bytes in the linear frame buffer
|
||||
there are between one pixel's data, and the data of the pixel
|
||||
immediately below. You can think of this as the horizontal
|
||||
resolution multiplied by the bytes per pixel (bits per pixel
|
||||
divided by 8). In practice, the pitch may be more than this product
|
||||
due to alignment constraints.</p>
|
||||
<h3>Maximum Resolutions</h3>
|
||||
<p>The NVIDIA Accelerated Linux Graphics Driver and NVIDIA
|
||||
GPU-based graphics cards support resolutions up to 32767x32767
|
||||
pixels for Pascal and newer GPUs, and up to 16384x16384 pixels for
|
||||
older GPUs, though the maximum resolution your system can support
|
||||
is also limited by the amount of video memory (see <a href=
|
||||
"programmingmodes.html#UsefulFormulas" title=
|
||||
"Useful Formulas">Useful Formulas</a> for details) and the maximum
|
||||
supported resolution of your display device (monitor/flat
|
||||
panel/television). Also note that while use of a video overlay does
|
||||
not limit the maximum resolution or refresh rate, video memory
|
||||
bandwidth used by a programmed mode does affect the overlay
|
||||
quality.</p>
|
||||
<p>Using HDMI 2.0 4K@60Hz modes in the RGB 4:4:4 color space
|
||||
requires a high single-link pixel clock that is only available on
|
||||
GM20x or later GPUs. In addition, using a mode requiring the YCbCr
|
||||
4:2:0 color space over a DisplayPort connection requires a GP10x or
|
||||
later GPU. If driving the current mode in the RGB 4:4:4 color space
|
||||
would require a pixel clock that exceeds the display's or GPU's
|
||||
capabilities, and the display and GPU are capable of driving that
|
||||
mode in the YCbCr 4:2:0 color space, then the color space will be
|
||||
overridden to YCbCr 4:2:0. On all Turing and earlier GPUs, and on
|
||||
all DisplayPort display devices regardless of GPU, YCbCr 4:2:0 mode
|
||||
is not supported on depth 8 X screens, and is not currently
|
||||
supported with stereo or the GLX_NV_swap_group OpenGL
|
||||
extension.</p>
|
||||
<p><a name="UsefulFormulas" id="UsefulFormulas"></a></p>
|
||||
<h3>Useful Formulas</h3>
|
||||
<p>The maximum resolution is a function both of the amount of video
|
||||
memory and the bits per pixel you elect to use:</p>
|
||||
<div class="informalequation">
|
||||
<div class="mediaobject"><span>HR * VR * (bpp/8) = Video Memory
|
||||
Used</span></div>
|
||||
</div>
|
||||
<p>In other words, the amount of video memory used is equal to the
|
||||
horizontal resolution (HR) multiplied by the vertical resolution
|
||||
(VR) multiplied by the bytes per pixel (bits per pixel divided by
|
||||
eight). Technically, the video memory used is actually the pitch
|
||||
times the vertical resolution, and the pitch may be slightly
|
||||
greater than <span class="inlinemediaobject"><span>(HR *
|
||||
(bpp/8))</span></span> to accommodate the hardware requirement that
|
||||
the pitch be a multiple of some value.</p>
|
||||
<p>Note that this is just memory usage for the frame buffer; video
|
||||
memory is also used by other things, such as OpenGL and pixmap
|
||||
caching.</p>
|
||||
<p>Another important relationship is that between the resolution,
|
||||
the pixel clock (also known as the dot clock) and the vertical
|
||||
refresh rate:</p>
|
||||
<div class="informalequation">
|
||||
<div class="mediaobject"><span>RR = PCLK / (HFL * VFL)</span></div>
|
||||
</div>
|
||||
<p>In other words, the refresh rate (RR) is equal to the pixel
|
||||
clock (PCLK) divided by the total number of pixels: the horizontal
|
||||
frame length (HFL) multiplied by the vertical frame length (VFL)
|
||||
(note that these are the frame lengths, and not just the visible
|
||||
resolutions). As described in the XFree86 Video Timings HOWTO, the
|
||||
above formula can be rewritten as:</p>
|
||||
<div class="informalequation">
|
||||
<div class="mediaobject"><span>PCLK = RR * HFL * VFL</span></div>
|
||||
</div>
|
||||
<p>Given a maximum pixel clock, you can adjust the RR, HFL and VFL
|
||||
as desired, as long as the product of the three is consistent. The
|
||||
pixel clock is reported in the log file. Your X log should contain
|
||||
a line like this:</p>
|
||||
<pre class="screen">
|
||||
(--) NVIDIA(0): ViewSonic VPD150 (DFP-1): 165 MHz maximum pixel clock
|
||||
</pre>
|
||||
<p>which indicates the maximum pixel clock for that display
|
||||
device.</p>
|
||||
<h3>How Modes Are Validated</h3>
|
||||
<p>In traditional XFree86/X.Org mode validation, the X server takes
|
||||
as a starting point the X server's internal list of VESA standard
|
||||
modes, plus any modes specified with special ModeLines in the X
|
||||
configuration file's Monitor section. These modes are validated
|
||||
against criteria such as the valid HorizSync/VertRefresh frequency
|
||||
ranges for the user's monitor (as specified in the Monitor section
|
||||
of the X configuration file), as well as the maximum pixel clock of
|
||||
the GPU.</p>
|
||||
<p>Once the X server has determined the set of valid modes, it
|
||||
takes the list of user requested modes (i.e., the set of modes
|
||||
named in the "Modes" line in the Display subsection of the Screen
|
||||
section of X configuration file), and finds the "best" validated
|
||||
mode with the requested name.</p>
|
||||
<p>The NVIDIA X driver uses a variation on the above approach to
|
||||
perform mode validation. During X server initialization, the NVIDIA
|
||||
X driver builds a pool of valid modes for each display device. It
|
||||
gathers all possible modes from several sources:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>The display device's EDID</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The X server's built-in list</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Any user-specified ModeLines in the X configuration file</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The VESA standard modes</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p>For every possible mode, the mode is run through mode
|
||||
validation. The core of mode validation is still performed
|
||||
similarly to traditional XFree86/X.Org mode validation: the mode
|
||||
timings are checked against things such as the valid HorizSync and
|
||||
VertRefresh ranges and the maximum pixelclock. Note that each
|
||||
individual stage of mode validation can be independently controlled
|
||||
through the "ModeValidation" X configuration option.</p>
|
||||
<p>Note that when validating interlaced mode timings, VertRefresh
|
||||
specifies the field rate, rather than the frame rate. For example,
|
||||
the following modeline has a vertical refresh rate of 87 Hz:</p>
|
||||
<pre class="screen">
|
||||
# 1024x768i @ 87Hz (industry standard)
|
||||
ModeLine "1024x768" 44.9 1024 1032 1208 1264 768 768 776 817 +hsync +vsync Interlace
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>Invalid modes are discarded; valid modes are inserted into the
|
||||
mode pool. See MODE VALIDATION REPORTING for how to get more
|
||||
details on mode validation results for each considered mode.</p>
|
||||
<p>Valid modes are given a unique name that is guaranteed to be
|
||||
unique across the whole mode pool for this display device. This
|
||||
mode name is constructed approximately like this:</p>
|
||||
<pre class="screen">
|
||||
<width>x<height>_<refreshrate>
|
||||
</pre>
|
||||
<p>(e.g., "1600x1200_85")</p>
|
||||
<p>The name may also be prepended with another number to ensure the
|
||||
mode is unique; e.g., "1600x1200_85_0".</p>
|
||||
<p>As validated modes are inserted into the mode pool, duplicate
|
||||
modes are removed, and the mode pool is sorted, such that the
|
||||
"best" modes are at the beginning of the mode pool. The sorting is
|
||||
based roughly on:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>Resolution</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Source (EDID-provided modes are prioritized higher than
|
||||
VESA-provided modes, which are prioritized higher than modes that
|
||||
were in the X server's built-in list)</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Refresh rate</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p>Once modes from all mode sources are validated and the mode pool
|
||||
is constructed, all modes with the same resolution are compared;
|
||||
the best mode with that resolution is added to the mode pool a
|
||||
second time, using just the resolution as its unique modename
|
||||
(e.g., "1600x1200"). In this way, when you request a mode using the
|
||||
traditional names (e.g., "1600x1200"), you still get what you got
|
||||
before (the 'best' 1600x1200 mode); the added benefit is that all
|
||||
modes in the mode pool can be addressed by a unique name.</p>
|
||||
<p>When verbose logging is enabled (see <a href=
|
||||
"faq.html#xverboselog">“How can I increase the amount of data
|
||||
printed in the X log file?”</a>), the mode pool for each
|
||||
display device is printed to the X log file.</p>
|
||||
<p>After the mode pool is built for all display devices, the
|
||||
requested modes (as specified in the X configuration file), are
|
||||
looked up from the mode pool. Each requested mode that can be
|
||||
matched against a mode in the mode pool is then advertised to the X
|
||||
server and is available to the user through the X server's mode
|
||||
switching hotkeys (ctrl-alt-plus/minus) and the XRandR and
|
||||
XF86VidMode X extensions.</p>
|
||||
<p>Additionally, all modes in the mode pool of the primary display
|
||||
device are implicitly made available to the X server. See the
|
||||
<a href=
|
||||
"xconfigoptions.html#IncludeImplicitMetaModes">IncludeImplicitMetaModes</a>
|
||||
X configuration option for details.</p>
|
||||
<h3>The NVIDIA-Auto-Select Mode</h3>
|
||||
<p>You can request a special mode by name in the X config file,
|
||||
named "nvidia-auto-select". When the X driver builds the mode pool
|
||||
for a display device, it selects one of the modes as the
|
||||
"nvidia-auto-select" mode; a new entry is made in the mode pool,
|
||||
and "nvidia-auto-select" is used as the unique name for the
|
||||
mode.</p>
|
||||
<p>The "nvidia-auto-select" mode is intended to be a reasonable
|
||||
mode for the display device in question. For example, the
|
||||
"nvidia-auto-select" mode is normally the native resolution for
|
||||
flat panels, as reported by the flat panel's EDID, or one of the
|
||||
detailed timings from the EDID. The "nvidia-auto-select" mode is
|
||||
guaranteed to always be present, and to always be defined as
|
||||
something considered valid by the X driver for this display
|
||||
device.</p>
|
||||
<p>Note that the "nvidia-auto-select" mode is not necessarily the
|
||||
largest possible resolution, nor is it necessarily the mode with
|
||||
the highest refresh rate. Rather, the "nvidia-auto-select" mode is
|
||||
selected such that it is a reasonable default. The selection
|
||||
process is roughly:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>If the EDID for the display device reported a preferred mode
|
||||
timing, and that mode timing is considered a valid mode, then that
|
||||
mode is used as the "nvidia-auto-select" mode. You can check if the
|
||||
EDID reported a preferred timing by starting X with logverbosity
|
||||
greater than or equal to 5 (see <a href=
|
||||
"faq.html#xverboselog">“How can I increase the amount of data
|
||||
printed in the X log file?”</a>), and looking at the EDID
|
||||
printout; if the EDID contains a line:</p>
|
||||
<pre class="screen">
|
||||
Prefer first detailed timing : Yes
|
||||
</pre>
|
||||
<p>Then the first mode listed under the "Detailed Timings" in the
|
||||
EDID will be used.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>If the EDID did not provide a preferred timing, the best
|
||||
detailed timing from the EDID is used as the "nvidia-auto-select"
|
||||
mode.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>If the EDID did not provide any detailed timings (or there was
|
||||
no EDID at all), the best valid mode not larger than 1024x768 is
|
||||
used as the "nvidia-auto-select" mode. The 1024x768 limit is
|
||||
imposed here to restrict use of modes that may have been validated,
|
||||
but may be too large to be considered a reasonable default, such as
|
||||
2048x1536.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>If all else fails, the X driver will use a built-in 800 x 600
|
||||
60Hz mode as the "nvidia-auto-select" mode.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p>If no modes are requested in the X configuration file, or none
|
||||
of the requested modes can be found in the mode pool, then the X
|
||||
driver falls back to the "nvidia-auto-select" mode, so that X can
|
||||
always start. Appropriate warning messages will be printed to the X
|
||||
log file in these fallback scenarios.</p>
|
||||
<p>You can add the "nvidia-auto-select" mode to your X
|
||||
configuration file by running the command</p>
|
||||
<pre class="screen">
|
||||
nvidia-xconfig --mode nvidia-auto-select
|
||||
</pre>
|
||||
<p>and restarting your X server.</p>
|
||||
<p>The X driver can generally do a much better job of selecting the
|
||||
"nvidia-auto-select" mode if the display device's EDID is
|
||||
available. This is one reason why it is recommended to only use the
|
||||
"UseEDID" X configuration option sparingly. Note that, rather than
|
||||
globally disable all uses of the EDID with the "UseEDID" option,
|
||||
you can individually disable each particular use of the EDID using
|
||||
the "UseEDIDFreqs", "UseEDIDDpi", and/or the "NoEDIDModes" argument
|
||||
in the "ModeValidation" X configuration option.</p>
|
||||
<h3>Mode Validation Reporting</h3>
|
||||
<p>When log verbosity is set to 6 or higher (see <a href=
|
||||
"faq.html#xverboselog">“How can I increase the amount of data
|
||||
printed in the X log file?”</a>), the X log will record every
|
||||
mode that is considered for each display device's mode pool, and
|
||||
report whether the mode passed or failed. For modes that were
|
||||
considered invalid, the log will report why the mode was considered
|
||||
invalid.</p>
|
||||
<h3>Ensuring Identical Mode Timings</h3>
|
||||
<p>Some functionality, such as Active Stereo with TwinView,
|
||||
requires control over exactly which mode timings are used. For
|
||||
explicit control over which mode timings are used on each display
|
||||
device, you can specify the ModeLine you want to use (using one of
|
||||
the ModeLine generators available), and using a unique name. For
|
||||
example, if you wanted to use 1024x768 at 120 Hz on each monitor in
|
||||
TwinView with active stereo, you might add something like this to
|
||||
the monitor section of your X configuration file:</p>
|
||||
<pre class="screen">
|
||||
# 1024x768 @ 120.00 Hz (GTF) hsync: 98.76 kHz; pclk: 139.05 MHz
|
||||
Modeline "1024x768_120" 139.05 1024 1104 1216 1408 768 769 772 823 -HSync +Vsync
|
||||
</pre>
|
||||
<p>Then, in the Screen section of your X config file, specify a
|
||||
MetaMode like this:</p>
|
||||
<pre class="screen">
|
||||
Option "MetaModes" "1024x768_120, 1024x768_120"
|
||||
</pre>
|
||||
<p></p>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"optimus.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"flippingubb.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 17. Using the NVIDIA Driver with Optimus
|
||||
Laptops </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 19. Configuring Flipping and UBB</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,348 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 34. Offloading Graphics Display with RandR
|
||||
1.4</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="depth30.html" title=
|
||||
"Chapter 33. Configuring Depth 30 Displays">
|
||||
<link rel="next" href="primerenderoffload.html" title=
|
||||
"Chapter 35. PRIME Render Offload">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 34. Offloading
|
||||
Graphics Display with RandR 1.4</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"depth30.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"primerenderoffload.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="randr14" id=
|
||||
"randr14"></a>Chapter 34. Offloading Graphics Display
|
||||
with RandR 1.4</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>Version 1.4 of the X Resize, Rotate, and Reflect Extension
|
||||
(RandR 1.4 for short) adds a way for drivers to work together so
|
||||
that one graphics device can display images rendered by
|
||||
another.</p>
|
||||
<p><a name="requirements" id="requirements"></a></p>
|
||||
<h3>System Requirements</h3>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>For displaying NVIDIA GPU desktop contents on a screen connected
|
||||
to another graphics device, X.Org X server version 1.13 or
|
||||
higher.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>For displaying another graphics device's desktop contents on a
|
||||
screen connected to an NVIDIA GPU, X.Org X server version 1.20.7 or
|
||||
higher. X server version 1.20.6 is also supported using <a href=
|
||||
"xconfigoptions.html#AllowPRIMEDisplayOffloadSink"><code class=
|
||||
"computeroutput">Option "AllowPRIMEDisplayOffloadSink"
|
||||
"boolean"</code></a>.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>A Linux kernel, version 3.13 or higher, with CONFIG_DRM
|
||||
enabled.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Version 1.4.0 of the xrandr command-line utility.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p><a name="outputsource" id="outputsource"></a></p>
|
||||
<h3>Using the NVIDIA Driver as an RandR 1.4 Output Source or Output
|
||||
Sink Provider</h3>
|
||||
<p>To use the NVIDIA driver as an RandR 1.4 output source provider,
|
||||
also known as “<span class="quote">PRIME</span>”, the X
|
||||
server needs to be configured to use the NVIDIA driver for its
|
||||
primary screen and to use the “<span class=
|
||||
"quote">modesetting</span>” driver for the other graphics
|
||||
device. This can be achieved by placing the following in
|
||||
<code class="computeroutput">/etc/X11/xorg.conf</code>:</p>
|
||||
<pre class="screen">
|
||||
Section "ServerLayout"
|
||||
Identifier "layout"
|
||||
Screen 0 "nvidia"
|
||||
Inactive "intel"
|
||||
EndSection
|
||||
|
||||
Section "Device"
|
||||
Identifier "nvidia"
|
||||
Driver "nvidia"
|
||||
BusID "<BusID for NVIDIA device here>"
|
||||
EndSection
|
||||
|
||||
Section "Screen"
|
||||
Identifier "nvidia"
|
||||
Device "nvidia"
|
||||
Option "AllowEmptyInitialConfiguration"
|
||||
EndSection
|
||||
|
||||
Section "Device"
|
||||
Identifier "intel"
|
||||
Driver "modesetting"
|
||||
EndSection
|
||||
|
||||
Section "Screen"
|
||||
Identifier "intel"
|
||||
Device "intel"
|
||||
EndSection
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>To use the NVIDIA driver as an RandR 1.4 output sink provider,
|
||||
also known as “<span class="quote">Reverse
|
||||
PRIME</span>”, the X server needs to be configured to use the
|
||||
“<span class="quote">modesetting</span>” driver for its
|
||||
primary screen and to use the NVIDIA driver for the other graphics
|
||||
device. This can be achieved by placing the following in
|
||||
<code class="computeroutput">/etc/X11/xorg.conf</code>:</p>
|
||||
<pre class="screen">
|
||||
Section "ServerLayout"
|
||||
Identifier "layout"
|
||||
Screen 0 "intel"
|
||||
Inactive "nvidia"
|
||||
Option "AllowNVIDIAGPUScreens"
|
||||
EndSection
|
||||
|
||||
Section "Device"
|
||||
Identifier "intel"
|
||||
Driver "modesetting"
|
||||
BusID "<BusID for Intel device here>"
|
||||
EndSection
|
||||
|
||||
Section "Screen"
|
||||
Identifier "intel"
|
||||
Device "intel"
|
||||
EndSection
|
||||
|
||||
Section "Device"
|
||||
Identifier "nvidia"
|
||||
Driver "nvidia"
|
||||
EndSection
|
||||
|
||||
Section "Screen"
|
||||
Identifier "nvidia"
|
||||
Device "nvidia"
|
||||
EndSection
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>When using the NVIDIA driver as a “<span class=
|
||||
"quote">Reverse PRIME</span>” RandR 1.4 output sink provider
|
||||
combined with an application being run via <a href=
|
||||
"primerenderoffload.html" title=
|
||||
"Chapter 35. PRIME Render Offload">Chapter 35,
|
||||
<i>PRIME Render Offload</i></a>, an optimization known as
|
||||
“<span class="quote">Reverse PRIME Bypass</span>” may
|
||||
be used, bypassing the bandwidth overhead of both PRIME Render
|
||||
Offload and PRIME Display Offload. In order for Reverse PRIME
|
||||
Bypass to be used, a PRIME Render Offload application must be
|
||||
unredirected, fullscreen, and visible only on a single
|
||||
NVIDIA-driven PRIME Display Offload output. Usage of Reverse PRIME
|
||||
Bypass is printed to the X log when verbose logging is enabled in
|
||||
the X server.</p>
|
||||
<p>If an NVIDIA Reverse PRIME output is the sole display in the
|
||||
system then special conditions apply. That configuration is
|
||||
supported if the NVIDIA driver version is 495.46 or later and the
|
||||
X.Org X server version is newer than 21.1.3. Failing these
|
||||
conditions the NVIDIA Reverse PRIME output will not be synchronized
|
||||
to the native refresh rate of the NVIDIA graphics card in which
|
||||
case X.Org will revert the display to a default rate of 1 frame per
|
||||
second.</p>
|
||||
<p>Note that at the time of writing the latest X.Org X server is
|
||||
21.1.3 so there is no official X.Org release yet where this
|
||||
configuration is supported. For maintainers of Linux distributions
|
||||
and others who are willing to compile the X.Org X server locally,
|
||||
please cherry-pick this Git commit to support the configuration:
|
||||
<a href=
|
||||
"https://gitlab.freedesktop.org/xorg/xserver/-/commit/69774044716039fa70655b3bc6dd6a4ff4535cfd"
|
||||
target=
|
||||
"_top">https://gitlab.freedesktop.org/xorg/xserver/-/commit/69774044716039fa70655b3bc6dd6a4ff4535cfd</a>.
|
||||
The commit already lives in the branch where the next X.Org X
|
||||
server release after 21.1.3 will come from.</p>
|
||||
<p>See <a href="faq.html#busid">“What is the format of a PCI
|
||||
Bus ID?”</a> for information on determining the appropriate
|
||||
BusID string for your graphics card.</p>
|
||||
<p>The nvidia-xconfig(1) utility can be used to update the X
|
||||
configuration file for using the NVIDIA driver as an output source
|
||||
provider.</p>
|
||||
<pre class="screen">
|
||||
$ nvidia-xconfig --prime
|
||||
</pre>
|
||||
<p>See the nvidia-xconfig(1) man page for details.</p>
|
||||
<p>The X server does not automatically enable displays attached
|
||||
using the output sink in this configuration. To do that, use the
|
||||
<code class="computeroutput">xrandr</code> command line tool.</p>
|
||||
<p>For NVIDIA as an output source:</p>
|
||||
<pre class="screen">
|
||||
$ xrandr --setprovideroutputsource modesetting NVIDIA-0
|
||||
$ xrandr --auto
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>For NVIDIA as an output sink:</p>
|
||||
<pre class="screen">
|
||||
$ xrandr --setprovideroutputsource NVIDIA-G0 modesetting
|
||||
$ xrandr --auto
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>This pair of commands can be added to your X session startup
|
||||
scripts, for example by putting them in <code class=
|
||||
"computeroutput">$HOME/.xinitrc</code> before running <code class=
|
||||
"computeroutput">startx</code>.</p>
|
||||
<p>Use the</p>
|
||||
<pre class="screen">
|
||||
$ xrandr --listproviders
|
||||
</pre>
|
||||
<p>command to query the capabilities of the graphics devices. If
|
||||
the system requirements are met and the X server is configured
|
||||
correctly, there should be a provider named <code class=
|
||||
"computeroutput">NVIDIA-0</code> or <code class=
|
||||
"computeroutput">NVIDIA-G0</code> with the <code class=
|
||||
"computeroutput">Source Output</code> or <code class=
|
||||
"computeroutput">Sink Output</code> capability, respectively, and
|
||||
one named <code class="computeroutput">modesetting</code> with the
|
||||
<code class="computeroutput">Sink Output</code> and/or <code class=
|
||||
"computeroutput">Source Output</code> capabilities. If either
|
||||
provider is missing or doesn't have the expected capability, check
|
||||
your system configuration.</p>
|
||||
<p><a name="randr14sync" id="randr14sync"></a></p>
|
||||
<h3>Synchronized RandR 1.4 Outputs</h3>
|
||||
<p>When running against X.Org X server with video driver ABI 23 or
|
||||
higher, synchronization is supported with compatible drivers. At
|
||||
the time of writing, synchronization is compatible with the
|
||||
“<span class="quote">modesetting</span>” driver with
|
||||
Intel devices on Linux version 4.5 or newer. If all requirements
|
||||
are met, synchronization will be used automatically.</p>
|
||||
<p>X.Org X server version 1.19 or newer is required to support
|
||||
synchronization. Without synchronization, displays are prone to
|
||||
“<span class="quote">tearing</span>”. See <a href=
|
||||
"randr14.html#caveats" title="Caveats">Caveats</a> for details.</p>
|
||||
<p>If synchronization is being used but is not desired, it can be
|
||||
disabled with:</p>
|
||||
<pre class="screen">
|
||||
$ xrandr --output <output> --set "PRIME Synchronization" 0
|
||||
</pre>
|
||||
<p>and re-enabled with:</p>
|
||||
<pre class="screen">
|
||||
$ xrandr --output <output> --set "PRIME Synchronization" 1
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>See <a href="openglenvvariables.html#vblanksyncing" title=
|
||||
"Vblank syncing">Vblank syncing</a> for information on how OpenGL
|
||||
applications can synchronize with sink-provided outputs.</p>
|
||||
<p><a name="caveats" id="caveats"></a></p>
|
||||
<h3>Caveats</h3>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>Support for PRIME Synchronization relies on DRM KMS support. See
|
||||
<a href="kms.html" title=
|
||||
"Chapter 36. Direct Rendering Manager Kernel Modesetting (DRM KMS)">
|
||||
Chapter 36, <i>Direct Rendering Manager Kernel Modesetting
|
||||
(DRM KMS)</i></a> for more information.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Some Intel i915 DRM driver versions, such as that included with
|
||||
Linux 4.5, have a bug where drmModeMoveCursor() and
|
||||
drmModePageFlip() interfere with each other, resulting in only one
|
||||
occurring per frame. If choppy performance is observed in
|
||||
configurations using PRIME Synchronization and i915, it is
|
||||
suggested to add <code class="computeroutput">Option
|
||||
"SWCursor"</code> to Intel's device section in xorg.conf. The bug
|
||||
appears to be fixed as of Linux 4.6.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>When running against X.Org X server version 1.18.x or lower,
|
||||
there is no synchronization between the images rendered by the
|
||||
NVIDIA GPU and the output device. This means that the output device
|
||||
can start reading the next frame of video while it is still being
|
||||
updated, producing a graphical artifact known as
|
||||
“<span class="quote">tearing</span>”. Tearing is
|
||||
expected due to limitations in the design of the X.Org X server
|
||||
prior to video driver ABI 23.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>NVIDIA's implementation of PRIME requires support for DRM render
|
||||
nodes, a feature first merged in Linux 3.12. However, the feature
|
||||
was not enabled by default until Linux 3.17. To enable it on
|
||||
earlier supported kernels, specify the <code class=
|
||||
"computeroutput">drm.rnodes=1</code> kernel boot parameter.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>PRIME Synchronization is compatible with xf86-video-amdgpu as an
|
||||
output sink. xf86-video-amdgpu implements a separate interface for
|
||||
PRIME Synchronization that the RandR layer of the X server does not
|
||||
recognize. As a result, X will print "randr: falling back to
|
||||
unsynchronized pixmap sharing", despite the fact that PRIME is
|
||||
synchronized. Additionally, the "PRIME Synchronization" output
|
||||
property will not function to disable PRIME Synchronization when
|
||||
set to 0.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The NVIDIA driver only exposes the <code class=
|
||||
"computeroutput">Output Sink</code> capability by default on X
|
||||
server version 1.20.7 or later, but can be used without issue on X
|
||||
server version 1.20.6 with <code class="computeroutput">Option
|
||||
"AllowPRIMEDisplayOffloadSink"</code>. See <a href=
|
||||
"xconfigoptions.html#AllowPRIMEDisplayOffloadSink"><code class=
|
||||
"computeroutput">Option "AllowPRIMEDisplayOffloadSink"
|
||||
"boolean"</code></a> for more information.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The NVIDIA driver requires DRM KMS support to operate as an
|
||||
output sink when the output source driver is either NVIDIA or
|
||||
AMDGPU. See <a href="kms.html" title=
|
||||
"Chapter 36. Direct Rendering Manager Kernel Modesetting (DRM KMS)">
|
||||
Chapter 36, <i>Direct Rendering Manager Kernel Modesetting
|
||||
(DRM KMS)</i></a> for more information.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"depth30.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"primerenderoffload.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 33. Configuring Depth 30 Displays </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 35. PRIME Render Offload</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,87 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 26. NVIDIA Spectre V2 Mitigation</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="nvidiasettings.html" title=
|
||||
"Chapter 25. Using the nvidia-settings Utility">
|
||||
<link rel="next" href="nvidia-smi.html" title=
|
||||
"Chapter 27. Using the nvidia-smi Utility">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 26. NVIDIA Spectre
|
||||
V2 Mitigation</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"nvidiasettings.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"nvidia-smi.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="retpoline" id=
|
||||
"retpoline"></a>Chapter 26. NVIDIA Spectre V2
|
||||
Mitigation</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>The NVIDIA Linux driver supports the retpoline Spectre V2
|
||||
mitigation technique as identified by: <a href=
|
||||
"https://software.intel.com/security-software-guidance/api-app/sites/default/files/Retpoline-A-Branch-Target-Injection-Mitigation.pdf"
|
||||
target=
|
||||
"_top">https://software.intel.com/security-software-guidance/api-app/sites/default/files/Retpoline-A-Branch-Target-Injection-Mitigation.pdf</a></p>
|
||||
<p>For Linux systems that define CONFIG_RETPOLINE, the NVIDIA
|
||||
driver yields to the kernel's implementation of Spectre V2
|
||||
mitigation. When CONFIG_RETPOLINE is not defined, the NVIDIA Linux
|
||||
driver implements the retpoline thunk without the Spectre V2
|
||||
mitigation.</p>
|
||||
<p>Linux kernels that implement retpoline based Spectre V2
|
||||
mitigation provide a kernel boot flag to enable or disable the
|
||||
feature. When enabled, users may notice a performance degradation.
|
||||
In order to recover performance, the user can disable the feature
|
||||
using the <span><strong class="command">spectre_v2</strong></span>
|
||||
boot flag (unsafe).</p>
|
||||
<pre class="screen">
|
||||
spectre_v2=off
|
||||
</pre></div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"nvidiasettings.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"nvidia-smi.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 25. Using the nvidia-settings Utility </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 27. Using the nvidia-smi Utility</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,88 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 3. Selecting and Downloading the NVIDIA
|
||||
Packages for Your System</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="minimumrequirements.html" title=
|
||||
"Chapter 2. Minimum Requirements">
|
||||
<link rel="next" href="installdriver.html" title=
|
||||
"Chapter 4. Installing the NVIDIA Driver">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 3. Selecting and
|
||||
Downloading the NVIDIA Packages for Your System</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"minimumrequirements.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"installdriver.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="selectdriver" id=
|
||||
"selectdriver"></a>Chapter 3. Selecting and Downloading
|
||||
the NVIDIA Packages for Your System</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>NVIDIA drivers can be downloaded from the NVIDIA website
|
||||
(<a href="http://www.nvidia.com" target=
|
||||
"_top">http://www.nvidia.com</a>).</p>
|
||||
<p>The NVIDIA graphics driver uses a Unified Driver Architecture:
|
||||
the single graphics driver supports all modern NVIDIA GPUs.
|
||||
"Legacy" GPU support has been moved from the unified driver to
|
||||
special legacy GPU driver releases. See <a href=
|
||||
"supportedchips.html" title=
|
||||
"Appendix A. Supported NVIDIA GPU Products">Appendix A,
|
||||
<i>Supported NVIDIA GPU Products</i></a> for a list of legacy
|
||||
GPUs.</p>
|
||||
<p>The NVIDIA graphics driver is bundled in a self-extracting
|
||||
package named <code class=
|
||||
"filename">NVIDIA-Linux-x86_64-535.161.07.run</code>. On
|
||||
Linux-x86_64, that file contains both the 64-bit driver binaries as
|
||||
well as 32-bit compatibility driver binaries; the <code class=
|
||||
"filename">NVIDIA-Linux-x86_64-535.161.07-no-compat32.run</code>
|
||||
file only contains the 64-bit driver binaries.</p>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"minimumrequirements.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"installdriver.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 2. Minimum Requirements </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 4. Installing the NVIDIA Driver</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,457 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 31. Configuring SLI and Multi-GPU
|
||||
Mosaic</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="nvidia-persistenced.html" title=
|
||||
"Chapter 30. Using the nvidia-persistenced Utility">
|
||||
<link rel="next" href="framelock.html" title=
|
||||
"Chapter 32. Configuring Frame Lock and Genlock">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 31. Configuring
|
||||
SLI and Multi-GPU Mosaic</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"nvidia-persistenced.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"framelock.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="sli" id=
|
||||
"sli"></a>Chapter 31. Configuring SLI and Multi-GPU
|
||||
Mosaic</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>The NVIDIA Linux driver contains support for NVIDIA SLI and
|
||||
Multi-GPU Mosaic. This technology enables you to extend a single X
|
||||
screen transparently across all of the available display outputs on
|
||||
each GPU. See below for the exact set of configurations which can
|
||||
be used with SLI Mosaic Mode.</p>
|
||||
<p>The distinction between SLI and Multi-GPU is straightforward.
|
||||
SLI is used to leverage the processing power of GPUs across two or
|
||||
more graphics cards, while Multi-GPU is used to leverage the
|
||||
processing power of two GPUs colocated on the same graphics card.
|
||||
If you want to link together separate graphics cards, you should
|
||||
use the "SLI" X config option. Likewise, if you want to link
|
||||
together GPUs on the same graphics card, you should use the
|
||||
"MultiGPU" X config option. If you have two cards, each with two
|
||||
GPUs, and you wish to link them all together, you should use the
|
||||
"SLI" option.</p>
|
||||
<p>If any SLI mode is enabled, applications may override which
|
||||
rendering mode is in use by creating an OpenGL context with the
|
||||
GLX_CONTEXT_MULTIGPU_ATTRIB_NV attribute. In addition, applications
|
||||
may gain explicit control over individual GPU rendering in SLI
|
||||
configurations through the GL_NV_gpu_multicast extension by
|
||||
creating a context with the
|
||||
GLX_CONTEXT_MULTIGPU_ATTRIB_MULTICAST_NV attribute. Multicast
|
||||
rendering in SLI Mosaic configurations requires use of the
|
||||
GLX_CONTEXT_MULTIGPU_ATTRIB_MULTI_DISPLAY_MULTICAST_NV attribute,
|
||||
which is only allowed on Quadro GPUs.</p>
|
||||
<h3>Enabling Multi-GPU</h3>
|
||||
<p>Multi-GPU is enabled by setting the "MultiGPU" option in the X
|
||||
configuration file; see <a href="xconfigoptions.html" title=
|
||||
"Appendix B. X Config Options">Appendix B, <i>X
|
||||
Config Options</i></a> for details about the "MultiGPU" option.</p>
|
||||
<p>The nvidia-xconfig utility can be used to set the "MultiGPU"
|
||||
option, rather than modifying the X configuration file by hand. For
|
||||
example:</p>
|
||||
<pre class="screen">
|
||||
% nvidia-xconfig --multigpu=mosaic
|
||||
</pre>
|
||||
<p></p>
|
||||
<h3>Enabling SLI</h3>
|
||||
<p>SLI is enabled by setting the "SLI" option in the X
|
||||
configuration file; see <a href="xconfigoptions.html" title=
|
||||
"Appendix B. X Config Options">Appendix B, <i>X
|
||||
Config Options</i></a> for details about the SLI option.</p>
|
||||
<p>The nvidia-xconfig utility can be used to set the SLI option,
|
||||
rather than modifying the X configuration file by hand. For
|
||||
example:</p>
|
||||
<pre class="screen">
|
||||
% nvidia-xconfig --sli=mosaic
|
||||
</pre>
|
||||
<p></p>
|
||||
<h3>Enabling SLI Mosaic Mode</h3>
|
||||
<p>The simplest way to configure SLI Mosaic Mode using a grid of
|
||||
monitors is to use <span><strong class=
|
||||
"command">nvidia-settings</strong></span> (see <a href=
|
||||
"nvidiasettings.html" title=
|
||||
"Chapter 25. Using the nvidia-settings Utility">Chapter 25,
|
||||
<i>Using the nvidia-settings Utility</i></a>). The steps to perform
|
||||
this configuration are as follows:</p>
|
||||
<div class="orderedlist">
|
||||
<ol type="1">
|
||||
<li>
|
||||
<p>Connect each of the monitors you would like to use to any
|
||||
connector from any GPU used for SLI Mosaic Mode. If you are going
|
||||
to use fewer monitors than there are connectors, connect one
|
||||
monitor to each GPU before adding a second monitor to any GPUs.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Install the NVIDIA display driver set.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Configure an X screen to use the "nvidia" driver on at least one
|
||||
of the GPUs (see <a href="editxconfig.html" title=
|
||||
"Chapter 6. Configuring X for the NVIDIA Driver">Chapter 6,
|
||||
<i>Configuring X for the NVIDIA Driver</i></a> for more
|
||||
information).</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Start X.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Run <span><strong class=
|
||||
"command">nvidia-settings</strong></span> and open the "X Server
|
||||
Display Configuration" page using the navigation pane on the left
|
||||
side of the application.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Below the layout window, enable the "Use SLI Mosaic Mode" check
|
||||
box if not already enabled. Then click the "Configure SLI Mosaic
|
||||
Displays" button. You may need to click the "Advanced..." button
|
||||
near the bottom of the page.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>In the "Configure SLI Mosaic Layout" dialog, select the monitor
|
||||
grid configuration you'd like to use from the "Display
|
||||
Configuration" dropdown.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Choose the resolution and refresh rate at which you would like
|
||||
to drive each individual monitor.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Set any overlap you would like between the displays.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Click the "Apply to Layout" button. The configuration described
|
||||
in the dialog will be loaded into the "Display Configuration" page
|
||||
and can be adjusted, if needed.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Click the "Save to X Configuration File" button. NOTE: If you
|
||||
don't have permissions to write to your system's X configuration
|
||||
file, you will be prompted to choose a location to save the file.
|
||||
After doing so, you <span class="emphasis"><em>must</em></span>
|
||||
copy the X configuration file into a location the X server will
|
||||
consider upon startup (usually <code class=
|
||||
"filename">/etc/X11/xorg.conf</code>).</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Exit nvidia-settings and restart your X server.</p>
|
||||
</li>
|
||||
</ol>
|
||||
</div>
|
||||
<p>Alternatively, nvidia-xconfig can be used to configure SLI
|
||||
Mosaic Mode via a command like <span><strong class=
|
||||
"command">nvidia-xconfig --sli=Mosaic
|
||||
--metamodes=METAMODES</strong></span> where the METAMODES string
|
||||
specifies the desired grid configuration. For example:</p>
|
||||
<pre class="screen">
|
||||
nvidia-xconfig --sli=Mosaic --metamodes="GPU-0.DFP-0: 1920x1024+0+0, GPU-0.DFP-1: 1920x1024+1920+0, GPU-1.DFP-0: 1920x1024+0+1024, GPU-1.DFP-1: 1920x1024+1920+1024"
|
||||
</pre>
|
||||
<p>will configure four DFPs in a 2x2 configuration, each running at
|
||||
1920x1024, with the two DFPs on GPU-0 driving the top two monitors
|
||||
of the 2x2 configuration, and the two DFPs on GPU-1 driving the
|
||||
bottom two monitors of the 2x2 configuration.</p>
|
||||
<p>See the MetaModes X configuration description in details in
|
||||
<a href="configtwinview.html" title=
|
||||
"Chapter 12. Configuring Multiple Display Devices on One X Screen">
|
||||
Chapter 12, <i>Configuring Multiple Display Devices on One X
|
||||
Screen</i></a>. See <a href="displaydevicenames.html" title=
|
||||
"Appendix C. Display Device Names">Appendix C,
|
||||
<i>Display Device Names</i></a> for further details on GPU and
|
||||
Display Device Names.</p>
|
||||
<h3>Hardware requirements</h3>
|
||||
<p>SLI functionality requires:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>Identical PCI Express graphics cards</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>A supported motherboard</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>For the displays to be synchronized across GPUs, the GPUs must
|
||||
be connected using an SLI video bridge or nvlink bridge.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>SLI Mosaic Mode requires NVIDIA Quadro GPUs. GeForce GPUs in SLI
|
||||
can use Base Mosaic.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
<h3>Other Notes and Requirements</h3>
|
||||
<p>The following other requirements apply to SLI and Multi-GPU:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>Mobile GPUs are NOT supported</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>GPUs with ECC enabled may not be used in an SLI
|
||||
configuration</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>If X is configured to use multiple screens and screen 0 has SLI
|
||||
or Multi-GPU enabled, the other screens configured to use the
|
||||
nvidia driver will be disabled. Note that if SLI or Multi-GPU is
|
||||
enabled, the GPUs used by that configuration will be unavailable
|
||||
for single GPU rendering.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
<div class="qandaset">
|
||||
<table border="0" summary="Q and A Set">
|
||||
<col align="left" width="1%">
|
||||
<tbody>
|
||||
<tr class="qandadiv">
|
||||
<td align="left" valign="top" colspan="2"><a name=
|
||||
"FrequentlyAsked4dceb" id="FrequentlyAsked4dceb"></a>
|
||||
<h3 class="title">31.1. Frequently Asked SLI and Multi-GPU
|
||||
Questions</h3>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name="WhyDoesSliOrMul28671" id=
|
||||
"WhyDoesSliOrMul28671"></a></td>
|
||||
<td align="left" valign="top">
|
||||
<p><b>Why does SLI or MultiGPU fail to initialize?</b></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="answer">
|
||||
<td align="left" valign="top"></td>
|
||||
<td align="left" valign="top">
|
||||
<p>There are several reasons why SLI or MultiGPU may fail to
|
||||
initialize. Most of these should be clear from the warning message
|
||||
in the X log file; e.g.:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p><code class="computeroutput">Unsupported bus type</code></p>
|
||||
</li>
|
||||
<li>
|
||||
<p><code class="computeroutput">The video link was not
|
||||
detected</code></p>
|
||||
</li>
|
||||
<li>
|
||||
<p><code class="computeroutput">GPUs do not match</code></p>
|
||||
</li>
|
||||
<li>
|
||||
<p><code class="computeroutput">Unsupported GPU video
|
||||
BIOS</code></p>
|
||||
</li>
|
||||
<li>
|
||||
<p><code class="computeroutput">Insufficient PCIe link
|
||||
width</code></p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p>The warning message <code class="computeroutput">'Unsupported
|
||||
PCI topology'</code> is likely due to problems with your Linux
|
||||
kernel. The NVIDIA driver must have access to the PCI Bridge (often
|
||||
called the Root Bridge) that each NVIDIA GPU is connected to in
|
||||
order to configure SLI or MultiGPU correctly. There are many
|
||||
kernels that do not properly recognize this bridge and, as a
|
||||
result, do not allow the NVIDIA driver to access this bridge. See
|
||||
the below "How can I determine if my kernel correctly detects my
|
||||
PCI Bridge?" FAQ for details.</p>
|
||||
<p>Below are some specific troubleshooting steps to help deal with
|
||||
SLI and MultiGPU initialization failures.</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>Make sure that ACPI is enabled in your kernel. NVIDIA's
|
||||
experience has been that ACPI is needed for the kernel to correctly
|
||||
recognize the Root Bridge. Note that in some cases, the kernel's
|
||||
version of ACPI may still have problems and require an update to a
|
||||
newer kernel.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Run <span><strong class="command">lspci</strong></span> to check
|
||||
that multiple NVIDIA GPUs can be identified by the operating
|
||||
system; e.g:</p>
|
||||
<pre class="screen">
|
||||
% /sbin/lspci | grep -i nvidia
|
||||
</pre>
|
||||
<p>If <span><strong class="command">lspci</strong></span> does not
|
||||
report all the GPUs that are in your system, then this is a problem
|
||||
with your Linux kernel, and it is recommended that you use a
|
||||
different kernel.</p>
|
||||
<p>Please note: the <span><strong class=
|
||||
"command">lspci</strong></span> utility may be installed in a
|
||||
location other than <code class="filename">/sbin</code> on your
|
||||
system. If the above command fails with the error: <code class=
|
||||
"computeroutput">'/sbin/lspci: No such file or directory'</code>,
|
||||
please try:</p>
|
||||
<pre class="screen">
|
||||
% lspci | grep -i nvidia
|
||||
</pre>
|
||||
<p>, instead. You may also need to install your distribution's
|
||||
<code class="computeroutput">pciutils</code> package.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Make sure you have the most recent SBIOS available for your
|
||||
motherboard.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The PCI Express slots on the motherboard must provide a minimum
|
||||
link width. Please make sure that the PCI Express slot(s) on your
|
||||
motherboard meet the following requirements and that you have
|
||||
connected the graphics board to the correct PCI Express
|
||||
slot(s):</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="circle">
|
||||
<li>
|
||||
<p>A dual-GPU board needs a minimum of 8 lanes (i.e. x8 or x16)</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>A pair of single-GPU boards requires one of the following
|
||||
supported link width combinations:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="square">
|
||||
<li>
|
||||
<p>x16 + x16</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>x16 + x8</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>x16 + x4</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>x8 + x8</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="question">
|
||||
<td align="left" valign="top"><a name="HowCanIDetermin93bb2" id=
|
||||
"HowCanIDetermin93bb2"></a></td>
|
||||
<td align="left" valign="top">
|
||||
<p><b>How can I determine if my kernel correctly detects my PCI
|
||||
Bridge?</b></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr class="answer">
|
||||
<td align="left" valign="top"></td>
|
||||
<td align="left" valign="top">
|
||||
<p>As discussed above, the NVIDIA driver must have access to the
|
||||
PCI Bridge that each NVIDIA GPU is connected to in order to
|
||||
configure SLI or MultiGPU correctly. The following steps will
|
||||
identify whether the kernel correctly recognizes the PCI
|
||||
Bridge:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>Identify both NVIDIA GPUs:</p>
|
||||
<pre class="screen">
|
||||
% /sbin/lspci | grep -i vga
|
||||
|
||||
0a:00.0 VGA compatible controller: nVidia Corporation [...]
|
||||
81:00.0 VGA compatible controller: nVidia Corporation [...]
|
||||
</pre>
|
||||
<p></p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Verify that each GPU is connected to a bus connected to the Root
|
||||
Bridge (note that the GPUs in the above example are on buses 0a and
|
||||
81):</p>
|
||||
<pre class="screen">
|
||||
% /sbin/lspci -t
|
||||
</pre>
|
||||
<p>good:</p>
|
||||
<pre class="screen">
|
||||
-+-[0000:80]-+-00.0
|
||||
| +-01.0
|
||||
| \-0e.0-[0000:81]----00.0
|
||||
...
|
||||
\-[0000:00]-+-00.0
|
||||
+-01.0
|
||||
+-01.1
|
||||
+-0e.0-[0000:0a]----00.0
|
||||
</pre>
|
||||
<p>bad:</p>
|
||||
<pre class="screen">
|
||||
-+-[0000:81]---00.0
|
||||
...
|
||||
\-[0000:00]-+-00.0
|
||||
+-01.0
|
||||
+-01.1
|
||||
+-0e.0-[0000:0a]----00.0
|
||||
</pre>
|
||||
<p>Note that in the first example, bus 81 is connected to Root
|
||||
Bridge 80, but that in the second example there is no Root Bridge
|
||||
80 and bus 81 is incorrectly connected at the base of the device
|
||||
tree. In the bad case, the only solution is to upgrade your kernel
|
||||
to one that properly detects your PCI bus layout.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"nvidia-persistenced.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"framelock.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 30. Using the nvidia-persistenced
|
||||
Utility </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 32. Configuring Frame Lock and Genlock</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,179 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Appendix L. Wayland Known Issues</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="appendices.html" title=
|
||||
"Part II. Appendices">
|
||||
<link rel="prev" href="gpunames.html" title=
|
||||
"Appendix K. GPU Names">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Appendix L. Wayland Known
|
||||
Issues</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"gpunames.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part II. Appendices</th>
|
||||
<td width="20%" align="right"> </td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="appendix" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="wayland-issues" id=
|
||||
"wayland-issues"></a>Appendix L. Wayland Known
|
||||
Issues</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<h3>Overview</h3>
|
||||
<p>There are several areas in which the NVIDIA driver lacks feature
|
||||
parity between X11 and Wayland. These may be due to limitations of
|
||||
the driver itself, the Wayland protocol, or the specific Wayland
|
||||
compositor in use. Over time this list is expected to shorten as
|
||||
missing functionality is implemented both in the driver and in
|
||||
upstream components, but the following captures the situation as of
|
||||
the release of this driver version. Note that this assumes a
|
||||
compositor with reasonably complete support for graphics-related
|
||||
Wayland protocol extensions.</p>
|
||||
<h3>NVIDIA Driver Limitations</h3>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>The VDPAU library (<a href="vdpausupport.html" title=
|
||||
"Appendix G. VDPAU Support">Appendix G, <i>VDPAU
|
||||
Support</i></a>), used for hardware accelerated video decoding and
|
||||
presentation, does not have native Wayland support and does not
|
||||
work with Xwayland.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The NvFBC desktop capture library does not have native Wayland
|
||||
support and does not work with Xwayland.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Variable display refresh rate capabilities such as G-Sync are
|
||||
supported on Volta or newer GPUs with Wayland. Older GPUs are not
|
||||
supported.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Virtual reality displays, such as the SteamVR platform, require
|
||||
support for DRM display leasing which does not currently work.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>EGL_EXT_platform_x11 is not supported with Xwayland.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The nvidia-drm module does not support the GAMMA_LUT,
|
||||
DEGAMMA_LUT, CTM, COLOR_ENCODING, or COLOR_RANGE connector
|
||||
properties, which may impact some compositor features related to
|
||||
color correction.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The nvidia-settings configuration tool has limited functionality
|
||||
on Wayland.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Front-buffer rendering in GLX does not work with Xwayland.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<h3>Wayland Protocol or Compositor Limitations</h3>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>The following workstation features are not supported by any
|
||||
Wayland compositors or the Wayland protocol. They will also likely
|
||||
require new EGL extensions or other means to expose the related
|
||||
hardware functionality.</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="circle">
|
||||
<li>
|
||||
<p>SLI and Multi-GPU Mosaic (<a href="sli.html" title=
|
||||
"Chapter 31. Configuring SLI and Multi-GPU Mosaic">Chapter 31,
|
||||
<i>Configuring SLI and Multi-GPU Mosaic</i></a>)</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Frame Lock and Genlock (<a href="framelock.html" title=
|
||||
"Chapter 32. Configuring Frame Lock and Genlock">Chapter 32,
|
||||
<i>Configuring Frame Lock and Genlock</i></a>)</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Swap Groups</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Advanced display pipeline features including warp and blend,
|
||||
pixel shift, and emulated YUV420.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Stereo rendering</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
</li>
|
||||
<li>
|
||||
<p>There is no established public API through which Wayland
|
||||
compositors can power off video memory via RTD3 (<a href=
|
||||
"dynamicpowermanagement.html" title=
|
||||
"Chapter 22. PCI-Express Runtime D3 (RTD3) Power Management">Chapter 22,
|
||||
<i>PCI-Express Runtime D3 (RTD3) Power Management</i></a>).</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Xwayland does not provide a suitable mechanism for our driver to
|
||||
synchronize application rendering with presentation, which can
|
||||
cause visual corruption in some circumstances.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Display multiplexers (muxes) are typically used in laptops with
|
||||
both integrated and discrete GPUs to provide a direct connection
|
||||
between the discrete GPU and the built-in display (internal mux) or
|
||||
an external display (external mux). On X11, the display mux can be
|
||||
automatically switched when a full-screen application is running on
|
||||
the discrete GPU, enabling enhanced display features and improved
|
||||
performance, but no Wayland compositors currently support this
|
||||
functionality.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Indirect GLX does not work with Xwayland because the Glamor
|
||||
rendering engine is not compatible with our EGL implementation.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Hardware overlays cannot be used by GLX applications with
|
||||
Xwayland.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"gpunames.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"appendices.html">Up</a></td>
|
||||
<td width="40%" align="right"> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">Appendix K. GPU
|
||||
Names </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top"> </td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,193 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 24. Using the X Composite
|
||||
Extension</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="dynamicboost.html" title=
|
||||
"Chapter 23. Dynamic Boost on Linux">
|
||||
<link rel="next" href="nvidiasettings.html" title=
|
||||
"Chapter 25. Using the nvidia-settings Utility">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 24. Using the X
|
||||
Composite Extension</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"dynamicboost.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"nvidiasettings.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="xcompositeextension" id=
|
||||
"xcompositeextension"></a>Chapter 24. Using the X
|
||||
Composite Extension</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>X.Org X servers support an X protocol extension called
|
||||
Composite. This extension allows windows to be drawn into pixmaps
|
||||
instead of directly onto the screen. In conjunction with the Damage
|
||||
and Render extensions, this allows a program called a composite
|
||||
manager to blend windows together to draw the screen.</p>
|
||||
<p>Performance will be degraded significantly if the <code class=
|
||||
"computeroutput">RenderAccel</code> option is disabled in
|
||||
xorg.conf. See <a href="xconfigoptions.html" title=
|
||||
"Appendix B. X Config Options">Appendix B, <i>X
|
||||
Config Options</i></a> for more details.</p>
|
||||
<p>When the NVIDIA X driver is used and the Composite extension is
|
||||
enabled, NVIDIA's OpenGL implementation interacts properly with the
|
||||
Damage and Composite X extensions. This means that OpenGL rendering
|
||||
is drawn into offscreen pixmaps and the X server is notified of the
|
||||
Damage event when OpenGL renders to the pixmap. This allows OpenGL
|
||||
applications to behave properly in a composited X desktop.</p>
|
||||
<p>The Composite X extension is enabled by default. It can be
|
||||
disabled with <span><strong class="command">nvidia-xconfig
|
||||
--no-composite</strong></span>. See the nvidia-xconfig(1) man page
|
||||
for details.</p>
|
||||
<p>The Composite extension causes problems with some driver
|
||||
components:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>Xv adaptors will ignore the sync-to-vblank option when drawing
|
||||
into a redirected window.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Workstation overlays are incompatible with Composite.
|
||||
Workstation overlays will be automatically disabled when Composite
|
||||
is detected.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The NVIDIA Linux driver supports quad-buffered stereo together
|
||||
with Composite. However, many composite managers will only texture
|
||||
from and display the left eye content, effectively disabling the
|
||||
stereo effect. Workarounds for this problem are either to use a
|
||||
different composite manager that supports stereo or disable the
|
||||
Composite extension.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The Composite extension is incompatible with Xinerama in X.Org X
|
||||
servers prior to version 1.10. Composite will be automatically
|
||||
disabled when Xinerama is enabled on those servers.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Prior to X.Org X server version 1.15, the Damage extension does
|
||||
not properly report rendering events on all physical X screens in
|
||||
Xinerama configurations. This prevents most composite mangers from
|
||||
rendering correctly.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
<p>This NVIDIA Linux driver supports OpenGL rendering to 32-bit
|
||||
ARGB windows. 32-bit visuals are only available on screens with
|
||||
depths 24 or 30. If you are an application developer, you can use
|
||||
these new visuals in conjunction with a composite manager to create
|
||||
translucent OpenGL applications:</p>
|
||||
<pre class="screen">
|
||||
int attrib[] = {
|
||||
GLX_RENDER_TYPE, GLX_RGBA_BIT,
|
||||
GLX_DRAWABLE_TYPE, GLX_WINDOW_BIT,
|
||||
GLX_RED_SIZE, 1,
|
||||
GLX_GREEN_SIZE, 1,
|
||||
GLX_BLUE_SIZE, 1,
|
||||
GLX_ALPHA_SIZE, 1,
|
||||
GLX_DOUBLEBUFFER, True,
|
||||
GLX_DEPTH_SIZE, 1,
|
||||
None };
|
||||
GLXFBConfig *fbconfigs, fbconfig;
|
||||
int numfbconfigs, render_event_base, render_error_base;
|
||||
XVisualInfo *visinfo;
|
||||
XRenderPictFormat *pictFormat;
|
||||
|
||||
/* Make sure we have the RENDER extension */
|
||||
if(!XRenderQueryExtension(dpy, &render_event_base, &render_error_base)) {
|
||||
fprintf(stderr, "No RENDER extension found\n");
|
||||
exit(EXIT_FAILURE);
|
||||
}
|
||||
|
||||
/* Get the list of FBConfigs that match our criteria */
|
||||
fbconfigs = glXChooseFBConfig(dpy, scrnum, attrib, &numfbconfigs);
|
||||
if (!fbconfigs) {
|
||||
/* None matched */
|
||||
exit(EXIT_FAILURE);
|
||||
}
|
||||
|
||||
/* Find an FBConfig with a visual that has a RENDER picture format that
|
||||
* has alpha */
|
||||
for (i = 0; i < numfbconfigs; i++) {
|
||||
visinfo = glXGetVisualFromFBConfig(dpy, fbconfigs[i]);
|
||||
if (!visinfo) continue;
|
||||
pictFormat = XRenderFindVisualFormat(dpy, visinfo->visual);
|
||||
if (!pictFormat) continue;
|
||||
|
||||
if(pictFormat->direct.alphaMask > 0) {
|
||||
fbconfig = fbconfigs[i];
|
||||
break;
|
||||
}
|
||||
|
||||
XFree(visinfo);
|
||||
}
|
||||
|
||||
if (i == numfbconfigs) {
|
||||
/* None of the FBConfigs have alpha. Use a normal (opaque)
|
||||
* FBConfig instead */
|
||||
fbconfig = fbconfigs[0];
|
||||
visinfo = glXGetVisualFromFBConfig(dpy, fbconfig);
|
||||
pictFormat = XRenderFindVisualFormat(dpy, visinfo->visual);
|
||||
}
|
||||
|
||||
XFree(fbconfigs);
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>When rendering to a 32-bit window, keep in mind that composite
|
||||
managers expect "premultiplied alpha" colors. This means that if
|
||||
your color has components (r,g,b) and alpha value a, then you must
|
||||
render (a*r, a*g, a*b, a) into the target window.</p>
|
||||
<p>More information about Composite can be found at <a href=
|
||||
"http://freedesktop.org/Software/CompositeExt" target=
|
||||
"_top">http://freedesktop.org/Software/CompositeExt</a></p>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"dynamicboost.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"nvidiasettings.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 23. Dynamic Boost on Linux </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 25. Using the nvidia-settings Utility</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,136 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 13. Configuring GLX in Xinerama</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="configtwinview.html" title=
|
||||
"Chapter 12. Configuring Multiple Display Devices on One X Screen">
|
||||
<link rel="next" href="configmultxscreens.html" title=
|
||||
"Chapter 14. Configuring Multiple X Screens on One Card">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 13. Configuring
|
||||
GLX in Xinerama</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"configtwinview.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"configmultxscreens.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="xineramaglx" id=
|
||||
"xineramaglx"></a>Chapter 13. Configuring GLX in
|
||||
Xinerama</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>The NVIDIA Linux Driver supports GLX when Xinerama is enabled on
|
||||
similar GPUs. The Xinerama extension takes multiple physical X
|
||||
screens (possibly spanning multiple GPUs), and binds them into one
|
||||
logical X screen. This allows windows to be dragged between GPUs
|
||||
and to span across multiple GPUs. The NVIDIA driver supports
|
||||
hardware accelerated OpenGL rendering across all NVIDIA GPUs when
|
||||
Xinerama is enabled.</p>
|
||||
<p>To configure Xinerama</p>
|
||||
<div class="orderedlist">
|
||||
<ol type="1">
|
||||
<li>
|
||||
<p>Configure multiple X screens (refer to the xorg.conf man page
|
||||
for details).</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Enable Xinerama by adding the line</p>
|
||||
<pre class="screen">
|
||||
Option "Xinerama" "True"
|
||||
</pre>
|
||||
<p>to the "ServerFlags" section of your X config file.</p>
|
||||
</li>
|
||||
</ol>
|
||||
</div>
|
||||
<p></p>
|
||||
<p>Requirements:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>Using identical GPUs is recommended. Some combinations of
|
||||
non-identical, but similar, GPUs are supported. If a GPU is
|
||||
incompatible with the rest of a Xinerama desktop then no OpenGL
|
||||
rendering will appear on the screens driven by that GPU. Rendering
|
||||
will still appear normally on screens connected to other supported
|
||||
GPUs. In this situation the X log file will include a message of
|
||||
the form:</p>
|
||||
<pre class="screen">
|
||||
(WW) NVIDIA(2): The GPU driving screen 2 is incompatible with the rest of
|
||||
(WW) NVIDIA(2): the GPUs composing the desktop. OpenGL rendering will
|
||||
(WW) NVIDIA(2): be disabled on screen 2.
|
||||
</pre></li>
|
||||
<li>
|
||||
<p>NVIDIA's GLX implementation only supports Xinerama when physical
|
||||
X screen 0 is driven by the NVIDIA X driver. This is because the
|
||||
X.Org X server bases the visuals of the logical Xinerama X screen
|
||||
on the visuals of physical X screen 0.</p>
|
||||
<p>When physical X screen 0 is not being driven by the NVIDIA X
|
||||
driver and Xinerama is enabled, then GLX will be disabled. If
|
||||
physical X screens other than screen 0 are not being driven by the
|
||||
NVIDIA X driver, OpenGL rendering will be disabled on them.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Only the intersection of capabilities across all GPUs will be
|
||||
advertised.</p>
|
||||
<p>The maximum OpenGL viewport size is 16384x16384 pixels. If an
|
||||
OpenGL window is larger than the maximum viewport, regions beyond
|
||||
the viewport will be blank.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>X configuration options that affect GLX operation (e.g.: stereo,
|
||||
overlays) should be set consistently across all X screens in the X
|
||||
server.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"configtwinview.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"configmultxscreens.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 12. Configuring Multiple Display Devices on One X
|
||||
Screen </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 14. Configuring Multiple X Screens on One
|
||||
Card</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,511 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 15. Support for the X Resize and Rotate
|
||||
Extension</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="configmultxscreens.html" title=
|
||||
"Chapter 14. Configuring Multiple X Screens on One Card">
|
||||
<link rel="next" href="configlaptop.html" title=
|
||||
"Chapter 16. Configuring a Notebook">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 15. Support for
|
||||
the X Resize and Rotate Extension</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"configmultxscreens.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"configlaptop.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="xrandrextension" id=
|
||||
"xrandrextension"></a>Chapter 15. Support for the X
|
||||
Resize and Rotate Extension</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="toc">
|
||||
<p><b>Table of Contents</b></p>
|
||||
<dl>
|
||||
<dt><span class="section"><a href=
|
||||
"xrandrextension.html#randr-support">RandR Support</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"xrandrextension.html#randr-1.1-rotation-behavior">RandR 1.1
|
||||
Rotation Behavior</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"xrandrextension.html#randr-properties">Output
|
||||
Properties</a></span></dt>
|
||||
<dd>
|
||||
<dl>
|
||||
<dt><span class="section"><a href=
|
||||
"xrandrextension.html#randr-official-properties">Official
|
||||
Properties</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"xrandrextension.html#randr-unofficial-properties">Unofficial
|
||||
Properties</a></span></dt>
|
||||
</dl>
|
||||
</dd>
|
||||
<dt><span class="section"><a href=
|
||||
"xrandrextension.html#randr-dp12">DisplayPort 1.2</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"xrandrextension.html#randr-monitor-options">Monitor Configuration
|
||||
Options</a></span></dt>
|
||||
<dt><span class="section"><a href=
|
||||
"xrandrextension.html#randr-known-issues">Known
|
||||
Issues</a></span></dt>
|
||||
</dl>
|
||||
</div>
|
||||
<p>This NVIDIA driver release contains support for the X Resize and
|
||||
Rotate (RandR) Extension versions 1.1, 1.2, and 1.3. The version of
|
||||
the RandR extension advertised to X clients is controlled by the X
|
||||
server: the RandR extension and protocol are provided by the X
|
||||
server, which routes protocol requests to the NVIDIA X driver. Run
|
||||
<strong class="userinput"><code>xrandr --version</code></strong> to
|
||||
check the version of RandR provided by the X server.</p>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name="randr-support" id=
|
||||
"randr-support"></a>RandR Support</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>Specific supported features include:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>Modes can be set per-screen, and the X screen can be resized
|
||||
through the RRSetScreenConfig request (e.g., with xrandr(1)'s
|
||||
'--size' and '--rate' command line options).</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The X screen can be resized with the RandR 1.2 RRSetScreenSize
|
||||
request (e.g., with xrandr(1)'s '--fb' command line option).</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The state of the display hardware can be queried with the RandR
|
||||
1.2 and 1.3 RRGetScreenResources, RRGetScreenResourcesCurrent,
|
||||
RRGetOutputInfo, and RRGetCrtcInfo requests (e.g., with xrandr(1)'s
|
||||
'--query' command line option).</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Modes can be set with RandR CRTC granularity with the RandR 1.2
|
||||
RRSetCrtcConfig request. E.g., <strong class=
|
||||
"userinput"><code>xrandr --output DVI-I-2 --mode
|
||||
1920x1200</code></strong>.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Rotation can be set with RandR CRTC granularity with the RandR
|
||||
1.2 RRSetCrtcConfig request. E.g., <strong class=
|
||||
"userinput"><code>xrandr --output DVI-I-2 --mode 1920x1200
|
||||
--rotation left</code></strong>.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Per-CRTC transformations can be manipulated with the RandR 1.3
|
||||
RRSetCrtcTransform and RRGetCrtcTransform requests. E.g.,
|
||||
<strong class="userinput"><code>xrandr --output DVI-I-3 --mode
|
||||
1920x1200 --transform
|
||||
43.864288330078125,21.333328247070312,-16384,0,43.864288330078125,0,0,0.0321197509765625,19.190628051757812</code></strong>.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The RandR 1.0/1.1 requests RRGetScreenInfo and RRSetScreenConfig
|
||||
manipulate MetaModes. The MetaModes that the X driver uses (either
|
||||
user-requested or implicitly generated) are reported through the
|
||||
RRGetScreenInfo request (e.g., <strong class=
|
||||
"userinput"><code>xrandr --query --q1</code></strong>) and chosen
|
||||
through the RRSetScreenConfig request (e.g., <strong class=
|
||||
"userinput"><code>xrandr --size 1920x1200 --orientation
|
||||
left</code></strong>).</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
<p>The configurability exposed through RandR is also available
|
||||
through the MetaMode syntax, independent of X server version. See
|
||||
<a href="configtwinview.html#metamodes">MetaModes</a> for more
|
||||
details. As an example, these two commands are equivalent:</p>
|
||||
<pre class="screen">
|
||||
xrandr --output DVI-I-2 --mode 1280x1024 --pos 0x0 --rotate left \
|
||||
--output DVI-I-3 --mode 1920x1200 --pos 0x0
|
||||
|
||||
nvidia-settings --assign CurrentMetaMode="DVI-I-2: 1280x1024 +0+0 \
|
||||
{ Rotation=left }, DVI-I-3: 1920x1200 +0+0"
|
||||
</pre>
|
||||
<p></p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"randr-1.1-rotation-behavior" id=
|
||||
"randr-1.1-rotation-behavior"></a>RandR 1.1 Rotation Behavior</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>On X servers that support RandR 1.2 or later, when an RandR 1.1
|
||||
rotation request is received (e.g., <strong class=
|
||||
"userinput"><code>xrandr --orientation left</code></strong>), the
|
||||
NVIDIA X driver will apply that request to an entire MetaMode.
|
||||
E.g., if you configure multiple monitors, either through a MetaMode
|
||||
or through RandR 1.2:</p>
|
||||
<pre class="screen">
|
||||
xrandr --output DVI-I-2 --mode 1280x1024 --pos 0x0 \
|
||||
--output DVI-I-3 --mode 1920x1200 --pos 1280x0
|
||||
|
||||
nvidia-settings --assign CurrentMetaMode="DVI-I-2: 1280x1024 +0+0, \
|
||||
DVI-I-3: 1920x1200 +1280+0"
|
||||
</pre>
|
||||
<p>Requesting RandR 1.1 rotation through <strong class=
|
||||
"userinput"><code>xrandr --orientation left</code></strong>, will
|
||||
rotate the entire MetaMode, producing the equivalent of either:</p>
|
||||
<pre class="screen">
|
||||
xrandr --output DVI-I-2 --mode 1280x1024 --pos 176x0 --rotate left \
|
||||
--output DVI-I-3 --mode 1920x1200 --rotate left --pos 0x1280
|
||||
|
||||
nvidia-settings --assign CurrentMetaMode="DVI-I-2: 1280x1024 +176+0, \
|
||||
{ Rotation=left }, DVI-I-3: 1920x1200 +0+1280 { Rotation=left }"
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>On X servers that do not support RandR 1.2 or later, the NVIDIA
|
||||
X driver does not advertise RandR rotation support. On such X
|
||||
servers, it is recommended to configure rotation through MetaModes,
|
||||
instead.</p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name="randr-properties"
|
||||
id="randr-properties"></a>Output Properties</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>The NVIDIA Linux driver supports a number of output device
|
||||
properties.</p>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h3 class="title"><a name="randr-official-properties" id=
|
||||
"randr-official-properties"></a>Official Properties</h3>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>Properties that do not start with an underscore are officially
|
||||
documented in the file <code class=
|
||||
"computeroutput">randrproto.txt</code> in X.Org's randrproto
|
||||
package. See that file for a full description of these
|
||||
properties.</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p><a name="ConnectorNumber" id="ConnectorNumber"></a><code class=
|
||||
"computeroutput">ConnectorNumber</code></p>
|
||||
<p>This property groups RandR outputs by their physical connectors.
|
||||
For example, DVI-I ports have both an analog and a digital output,
|
||||
which is represented in RandR by two different output objects. One
|
||||
DVI-I port may be represented by RandR outputs <code class=
|
||||
"computeroutput">DVI-I-0</code> with <code class=
|
||||
"computeroutput">SignalFormat</code> <code class=
|
||||
"computeroutput">TMDS</code> (transition-minimized differential
|
||||
signaling, a digital signal format) and <code class=
|
||||
"computeroutput">DVI-I-1</code> with <code class=
|
||||
"computeroutput">SignalFormat</code> <code class=
|
||||
"computeroutput">VGA</code>, representing the analog part. In this
|
||||
case, both RandR outputs would have the same value of <code class=
|
||||
"computeroutput">ConnectorNumber</code>.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p><a name="ConnectorType" id="ConnectorType"></a><code class=
|
||||
"computeroutput">ConnectorType</code></p>
|
||||
<p>This property lists the physical type of the connector. For
|
||||
example, in the DVI-I example above, both <code class=
|
||||
"computeroutput">DVI-I-0</code> and <code class=
|
||||
"computeroutput">DVI-I-1</code> would have a <code class=
|
||||
"computeroutput">ConnectorType</code> of <code class=
|
||||
"computeroutput">DVI-I</code>.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p><a name="EDID" id="EDID"></a><code class=
|
||||
"computeroutput">EDID</code></p>
|
||||
<p>This property contains the raw bytes of the display's extended
|
||||
display identification data. This data is intended for applications
|
||||
to use to glean information about the monitor connected.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p><a name="SignalFormat" id="SignalFormat"></a><code class=
|
||||
"computeroutput">SignalFormat</code></p>
|
||||
<p>This property describes the type of signaling used to send image
|
||||
data to the display device. For example, an analog device connected
|
||||
to a DVI-I port might use VGA as its signaling format.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p><a name="Border" id="Border"></a><code class=
|
||||
"computeroutput">Border</code></p>
|
||||
<p>This property is a list of integers specifying adjustments for
|
||||
the edges of the displayed image. How this property is applied
|
||||
depends on the number of elements in the list:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="circle">
|
||||
<li>
|
||||
<p>0 = No border is applied.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>1 = A border of Border[0] is applied to all four sides of the
|
||||
image.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>2 = A border of Border[0] is applied to the left and right sides
|
||||
of the image, and a border of Border[1] is applied to the top and
|
||||
bottom.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>4 = The border dimensions are as follows: Border[0]: left,
|
||||
Border[1]: top, Border[2]: right, Border[3]: bottom</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p>This property is functionally equivalent to the ViewPortOut
|
||||
MetaMode token.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p><a name="BorderDimensions" id=
|
||||
"BorderDimensions"></a><code class="computeroutput">BorderDimensions</code></p>
|
||||
<p>This property lists how many Border adjustment parameters can
|
||||
actually be used. The NVIDIA implementation supports independently
|
||||
configuring all four Border values.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p><a name="GUID" id="GUID"></a><code class=
|
||||
"computeroutput">GUID</code></p>
|
||||
<p>DisplayPort 1.2 specifies that all devices must have a
|
||||
globally-unique identifier, referred to as a GUID. When a GUID is
|
||||
available, the <code class="computeroutput">GUID</code> property
|
||||
contains its raw bytes.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p><a name="CscMatrix" id="CscMatrix"></a><code class=
|
||||
"computeroutput">CscMatrix</code></p>
|
||||
<p>This property controls the color-space conversion matrix applied
|
||||
to the pixels being displayed. The matrix is 3 rows and 4 columns,
|
||||
stored in row-major order. Each entry is a 32-bit fixed-point
|
||||
number with 3 integer bits and 16 fractional bits. Each entry in
|
||||
the X colormap is treated as a 4-component column vector C = [ R,
|
||||
G, B, 1 ]. The resulting components of the color vector [ R', G',
|
||||
B' ] = CscMatrix * C are used as indices into the gamma ramp.</p>
|
||||
<p>For example, using xrandr version 1.5.0 or higher, you can
|
||||
exchange the red channel with the green channel using this
|
||||
command:</p>
|
||||
<pre class="screen">
|
||||
xrandr --output DP-6 --set CscMatrix \
|
||||
0,0x10000,0,0,0x10000,0,0,0,0,0,0x10000,0
|
||||
</pre>
|
||||
<p>To return to the default identity matrix, use</p>
|
||||
<pre class="screen">
|
||||
xrandr --output DP-6 --set CscMatrix \
|
||||
0x10000,0,0,0,0,0x10000,0,0,0,0,0x10000,0
|
||||
</pre>
|
||||
<p></p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h3 class="title"><a name="randr-unofficial-properties" id=
|
||||
"randr-unofficial-properties"></a>Unofficial Properties</h3>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>Properties whose names begin with an underscore are not
|
||||
specified by X.Org. They may be removed or modified in future
|
||||
driver releases. The NVIDIA Linux driver supports the following
|
||||
unofficial properties:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p><a name="ConnectorLocation" id=
|
||||
"ConnectorLocation"></a><code class=
|
||||
"computeroutput">_ConnectorLocation</code></p>
|
||||
<p>This property describes the physical location of the connector.
|
||||
On add-in graphics boards, connector location 0 should generally be
|
||||
the position closest to the motherboard, with increasing location
|
||||
numbers indicating connectors progressively farther away.</p>
|
||||
<p></p>
|
||||
<div class="informaltable">
|
||||
<table summary="(no summary available)" border="1">
|
||||
<colgroup>
|
||||
<col>
|
||||
<col></colgroup>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>Type</td>
|
||||
<td>INTEGER</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Format</td>
|
||||
<td>32</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td># Items</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Flags</td>
|
||||
<td>Immutable, Static</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Range</td>
|
||||
<td>0-</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<p></p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name="randr-dp12" id=
|
||||
"randr-dp12"></a>DisplayPort 1.2</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>When display devices are connected via DisplayPort 1.2 branch
|
||||
devices, additional RandR outputs will be created, one for each
|
||||
connected display device. These dynamic outputs will remain as long
|
||||
as the display device is connected or used in a MetaMode, even if
|
||||
they are not named in the current MetaMode. They will be deleted
|
||||
automatically when the display is disconnected and no MetaModes use
|
||||
them.</p>
|
||||
<p>See <a href="displaydevicenames.html" title=
|
||||
"Appendix C. Display Device Names">Appendix C,
|
||||
<i>Display Device Names</i></a> for a description of how the names
|
||||
of these outputs are generated.</p>
|
||||
<p>If you are developing applications that use the RandR extension,
|
||||
please be aware that outputs can be created and destroyed
|
||||
dynamically. You should be sure to use the XRRSelectInput function
|
||||
to watch for events that indicate when this happens.</p>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name=
|
||||
"randr-monitor-options" id="randr-monitor-options"></a>Monitor
|
||||
Configuration Options</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<p>This NVIDIA Linux driver honors the <code class=
|
||||
"computeroutput">Enable</code>, <code class=
|
||||
"computeroutput">Ignore</code>, <code class=
|
||||
"computeroutput">Primary</code>, and <code class=
|
||||
"computeroutput">Rotate</code> options in the Monitor section of
|
||||
the X configuration file. These options will apply to a monitor if
|
||||
the Identifier of the Monitor section matches one of the display
|
||||
device's names (see <a href="displaydevicenames.html" title=
|
||||
"Appendix C. Display Device Names">Appendix C,
|
||||
<i>Display Device Names</i></a> for a description of how a
|
||||
display's names are generated). For example, a Monitor section
|
||||
with</p>
|
||||
<pre class="screen">
|
||||
Identifier "DFP"
|
||||
</pre>
|
||||
<p>will apply to all digitally-connected displays, while a Monitor
|
||||
section with</p>
|
||||
<pre class="screen">
|
||||
Identifier "DPY-EDID-ee6cecc0-fa46-0c33-94e0-274313f9e7eb"
|
||||
</pre>
|
||||
<p>will apply only to a display device with a specific EDID-based
|
||||
identification hash. You can also specify the name of the Monitor
|
||||
section to use in the Screen section:</p>
|
||||
<pre class="screen">
|
||||
Option "Monitor-<dpyname>" "<Monitor name>"
|
||||
</pre>
|
||||
<p></p>
|
||||
<p>See the xorg.conf(5) man page for a description of these
|
||||
options.</p>
|
||||
</div>
|
||||
<div class="section" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title" style="clear: both"><a name="randr-known-issues"
|
||||
id="randr-known-issues"></a>Known Issues</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>Rotation and Transformations (configured either through RandR or
|
||||
MetaModes) are not yet supported with the GLX_NV_swap_group OpenGL
|
||||
extension.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Some of the RandR 1.2 X configuration options provided by the
|
||||
XFree86 DDX implementation and documented in xorg.conf(5) are not
|
||||
yet supported.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Transformations (configured either through RandR or MetaModes)
|
||||
are not yet correctly clipped.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"configmultxscreens.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"configlaptop.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 14. Configuring Multiple X Screens on One
|
||||
Card </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 16. Configuring a Notebook</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,160 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta name="generator" content=
|
||||
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
|
||||
<meta http-equiv="Content-Type" content=
|
||||
"text/html; charset=us-ascii">
|
||||
<title>Chapter 39. OpenGL and Vulkan on Xwayland</title>
|
||||
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
|
||||
<link rel="start" href="index.html" title=
|
||||
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
|
||||
<link rel="up" href="installationandconfiguration.html" title=
|
||||
"Part I. Installation and Configuration Instructions">
|
||||
<link rel="prev" href="ngx.html" title="Chapter 38. NGX">
|
||||
<link rel="next" href="gbm.html" title=
|
||||
"Chapter 40. GBM and GBM-based Wayland Compositors">
|
||||
</head>
|
||||
<body>
|
||||
<div class="navheader">
|
||||
<table width="100%" summary="Navigation header">
|
||||
<tr>
|
||||
<th colspan="3" align="center">Chapter 39. OpenGL and
|
||||
Vulkan on Xwayland</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="20%" align="left"><a accesskey="p" href=
|
||||
"ngx.html">Prev</a> </td>
|
||||
<th width="60%" align="center">Part I. Installation and
|
||||
Configuration Instructions</th>
|
||||
<td width="20%" align="right"> <a accesskey="n" href=
|
||||
"gbm.html">Next</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></div>
|
||||
<div class="chapter" lang="en">
|
||||
<div class="titlepage">
|
||||
<div>
|
||||
<div>
|
||||
<h2 class="title"><a name="xwayland" id=
|
||||
"xwayland"></a>Chapter 39. OpenGL and Vulkan on
|
||||
Xwayland</h2>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<h3>Overview</h3>
|
||||
<p>Xwayland is an X11 server implemented as a Wayland client,
|
||||
allowing one to run X11 applications on a Wayland desktop in a
|
||||
relatively seamless fashion. The NVIDIA driver is able to
|
||||
facilitate accelerated 3D rendering for such applications, but
|
||||
there are some particular considerations compared to a typical X11
|
||||
configuration which are outlined in this chapter.</p>
|
||||
<p>Note that some NVIDIA driver features may not be available, see
|
||||
<a href="wayland-issues.html" title=
|
||||
"Appendix L. Wayland Known Issues">Appendix L,
|
||||
<i>Wayland Known Issues</i></a> for details.</p>
|
||||
<h3>Requirements</h3>
|
||||
<p>The following are necessary to enable accelerated rendering on
|
||||
Xwayland with the NVIDIA driver:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>DRM KMS must be enabled. See <a href="kms.html" title=
|
||||
"Chapter 36. Direct Rendering Manager Kernel Modesetting (DRM KMS)">
|
||||
Chapter 36, <i>Direct Rendering Manager Kernel Modesetting
|
||||
(DRM KMS)</i></a> for details.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>The installed copy of Xwayland should be a build from the master
|
||||
branch of <a href="https://gitlab.freedesktop.org/xorg/xserver"
|
||||
target="_top">https://gitlab.freedesktop.org/xorg/xserver</a> at
|
||||
least as recent as commit c468d34c. Note that if this requirement
|
||||
is not satisfied, the NVIDIA GPU can still be used for rendering,
|
||||
however it will fall back to a suboptimal path for presentation
|
||||
resulting in degraded performance.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>libxcb version 1.13 or later must be present.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>egl-wayland version 1.1.7 or later must be present (if installed
|
||||
separately from the the NVIDIA driver).</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>If using the GNOME desktop environment, kms-modifiers must be
|
||||
enabled through gsettings. This can be done with the following
|
||||
command <strong class="userinput"><code>gsettings set
|
||||
org.gnome.mutter experimental-features
|
||||
[\"kms-modifiers\"]</code></strong></p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
<h3>Reporting Issues</h3>
|
||||
<p>The Wayland desktop relies on the close interaction of several
|
||||
components to function correctly. Because of this, it can be tricky
|
||||
to determine exactly which one is responsible for a suspected
|
||||
bug.</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="disc">
|
||||
<li>
|
||||
<p>If the issue only reproduces on NVIDIA hardware with the
|
||||
proprietary driver, see <a href="addtlresources.html" title=
|
||||
"Chapter 45. NVIDIA Contact Info and Additional Resources">
|
||||
Chapter 45, <i>NVIDIA Contact Info and Additional
|
||||
Resources</i></a> for links to the appropriate channels to report
|
||||
the bug to us.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>If the issue only reproduces with a particular compositor, it
|
||||
can be reported on that project's bug tracker, for example:</p>
|
||||
<div class="itemizedlist">
|
||||
<ul type="circle">
|
||||
<li>
|
||||
<p><a href="https://gitlab.gnome.org/GNOME/mutter/-/issues/"
|
||||
target="_top">https://gitlab.gnome.org/GNOME/mutter/-/issues/</a>
|
||||
for GNOME</p>
|
||||
</li>
|
||||
<li>
|
||||
<p><a href="https://bugs.kde.org/" target=
|
||||
"_top">https://bugs.kde.org/</a> for KDE</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
</li>
|
||||
<li>
|
||||
<p>If the issue is specific to X11 applications running on
|
||||
Xwayland, it can be reported on the X.org xserver issue tracker
|
||||
<a href="https://gitlab.freedesktop.org/xorg/xserver/-/issues"
|
||||
target=
|
||||
"_top">https://gitlab.freedesktop.org/xorg/xserver/-/issues</a>.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<p></p>
|
||||
</div>
|
||||
<div class="navfooter">
|
||||
<hr>
|
||||
<table width="100%" summary="Navigation footer">
|
||||
<tr>
|
||||
<td width="40%" align="left"><a accesskey="p" href=
|
||||
"ngx.html">Prev</a> </td>
|
||||
<td width="20%" align="center"><a accesskey="u" href=
|
||||
"installationandconfiguration.html">Up</a></td>
|
||||
<td width="40%" align="right"> <a accesskey="n" href=
|
||||
"gbm.html">Next</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="40%" align="left" valign="top">
|
||||
Chapter 38. NGX </td>
|
||||
<td width="20%" align="center"><a accesskey="h" href=
|
||||
"index.html">Home</a></td>
|
||||
<td width="40%" align="right" valign="top">
|
||||
Chapter 40. GBM and GBM-based Wayland
|
||||
Compositors</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
Reference in New Issue
Block a user