Mirrored_Repos/LookingGlass
1
0
Fork 0
mirror of https://github.com/gnif/LookingGlass.git synced 2024-11-10 00:28:20 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

[doc] fix my inabillity to spell :)

Browse Source
This commit is contained in:
Geoffrey McRae 2022-09-18 12:21:11 +10:00
parent f489006531
commit de5030f564
2 changed files with 12 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
doc/requirements.rst
View File

@ -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 <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.

2
doc/words.txt
View File

@ -1,5 +1,6 @@
backtrace
borderless
BigNavi
cgroups
clang
cmake
@ -32,6 +33,7 @@ mipmapping
modprobe
msys
multisampling
Navi
Nvidia
overlayed
pacman