From de5030f564390353ad03a2220aa0d520b5d82695 Mon Sep 17 00:00:00 2001 From: Geoffrey McRae Date: Sun, 18 Sep 2022 12:21:11 +1000 Subject: [PATCH] [doc] fix my inabillity to spell :) --- doc/requirements.rst | 20 ++++++++++---------- doc/words.txt | 2 ++ 2 files changed, 12 insertions(+), 10 deletions(-) diff --git a/doc/requirements.rst b/doc/requirements.rst index e1987d2c..73b61b20 100644 --- a/doc/requirements.rst +++ b/doc/requirements.rst @@ -11,9 +11,9 @@ Minimum The most basic requirement to make use of Looking Glass is to have a system with two GPUs, the following configurations are valid: -* Two descrete GPUs (dGPU) -* A descrete GPU and an integrated (iGPU) such as is common in laptops. -* A descrete GPU or iGPU and a virtual GPU (vGPU) as supported by some +* Two discrete GPUs (dGPU) +* A discrete GPU and an integrated (iGPU) such as is common in laptops. +* A discrete GPU or iGPU and a virtual GPU (vGPU) as supported by some hardware. .. note:: @@ -23,14 +23,14 @@ with two GPUs, the following configurations are valid: Looking Glass aims to achieve the lowest possible latency and as such it is important that you do not overload your system. The minimum recommended CPU -to obtain a decent expereience with Looking Glass is 6 cores or more, with +to obtain a decent experience with Looking Glass is 6 cores or more, with Hyper-threading (>= 12 threads). PCIe bandwidth can also be a limiting factor, as such both GPUs should have a minimum of 8 lanes (x8) at PCIe3 speeds, or 4 lanes (x4) at PCIe4 speeds. The GPU used for the guest virtual machine must have either a physical monitor -attached to it, or a cheap dummy plug. The guest operating system (most notibly +attached to it, or a cheap dummy plug. The guest operating system (most notably Windows) will disable the GPU output if there is nothing attached to it and Looking Glass will not be able to function. If you are using a vGPU the virtual device should already have a virtual monitor attached to it negating this @@ -46,12 +46,12 @@ At this time the recommended configuration is as follows: * CPU 8 cores (16 threads) or better @ 3.0GHz or faster (full cores, not efficiency cores). -* Two descrete GPUs consisting of: +* Two discrete GPUs consisting of: * AMD or Intel brand GPU for the client application (usually your host system). * NVIDIA brand GPU for the guest system (virtual machine). -The reason for these reccomendations are as follows: +The reason for these recommendations are as follows: AMD or Intel for the client ^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -60,16 +60,16 @@ AMD and Intel both support the `DMABUF` feature which enables offloading memory transfers to the GPU hardware. Please note that making use of this feature requires :doc:`loading the KVMFR kernel module `. -Additionally AMD GPUs suffer stabillity issues when operating as a passthrough +Additionally AMD GPUs suffer stability issues when operating as a passthrough device and as such we do not recommend their usage for such purposes. Models of note that have issues include but are not limited to the entire Polaris, Vega, -Navi and BigNavi GPU series. Vega and Navi are notibly the worst and should be +Navi and BigNavi GPU series. Vega and Navi are notably the worst and should be avoided for virtualization usage. NVIDIA for the guest ^^^^^^^^^^^^^^^^^^^^ -NVIDIA unlike AMD do not seem to suffer from the same stabillity issues as AMD +NVIDIA unlike AMD do not seem to suffer from the same stability issues as AMD GPUs when operating as a passthrough GPU, however due to the closed source nature of their drivers NVIDIA can not make use of the DMABUF feature in the Linux kernel and as such it is not recommended for use as the host GPU. diff --git a/doc/words.txt b/doc/words.txt index fc2ce328..0a099239 100644 --- a/doc/words.txt +++ b/doc/words.txt @@ -1,5 +1,6 @@ backtrace borderless +BigNavi cgroups clang cmake @@ -32,6 +33,7 @@ mipmapping modprobe msys multisampling +Navi Nvidia overlayed pacman