Portál AbcLinuxu, 5. května 2024 18:14
Samozřejmě platí, že při výběru HW je nutné se orientovat dle "success stories".
Z vlastních pokusů (Asrock 970Ex4:AMD 970+Ath IIX4; MSI BigBang Trinery:P55&nF200+Xeon X3430) mi přišlo, že problém IOMMU/VT-d (pokud funguje!) není až tak v zátěži sdílených prostředků (CPU,MEM) HostOSem jako spíš v příslušnosti integrovaných device k nízkému počtu IOMMU_group což brání jejich optimální dělbě HW mezi HostOS a GuesOS(y). Testů, které by se exaktně zabývaly výslednými vlastnostmi virtualizované "Game machine" (KB/MS,LAN,SND,GPU:fps,latence,lagy, notabene s vlivem zátěže HostOSu) asi mnoho nebude.Jsem zvědav jak na tom bude platforma X99/Haswell-E, ale mám obavu aby nám naděje nevydržela pouze do první errata (pozn. respektive druhé, ta první bude patrně mj. o TSX).
Na to kolik je technologii IOMMU/VT-d již let (2006?), jí asimilace mezi ty běžně dostupné docela trvá.
5.3. PCI Express* Root Ports (D28:F0,F1,F2,F3,F4,F5,F6,F7) There are eight root ports available in the PCH. The root ports are compliant to the PCI Express 2.0 specification running at 5.0 GT/s. The ports all reside in Device 28, and take Function 0 – 7. Port 1 is Function 0, Port 2 is Function 1, Port 3 is Function 2, Port 4 is Function 3, Port 5 is Function 4, Port 6 is Function 5, Port 7 is Function 6, and Port 8 is Function 7. This section assumes the default PCI Express Function Number-to-Root Port mapping is used. Function numbers for a given root port are assignable through the Root Port Function Number and Hide for PCI Express Root Ports register (RCBA+404h). Access Control Services (ACS)/Alternate Routing ID (ARI) are not supported on the PCI Express root ports. Devices connected to these ports may not support direct assignment for Single Root I/O Virtualization (SR-IOV)
Včera/dnes jsem zkusil na testovacím VT-d prostředí (tj. mb MSI BigBang Trinergy[P55&nF200]+X3430@3,6GHz+8GB/1600MHz RAM+HD4870/512MB) srovnat výsledky benchmarků Windows 8.1x64(native) a Windows 7x64(KVM+PCI passthrough/vga_vfio, 2GB, HD4870, 4-core). HostOS: Kubuntu 14.04 s vanilla 3.15.3
3Dmark 2006 (u moderních silných GK bráno jako čistý CPU benchmark, použitou HD4870 CPU nelimituje).
Windows 7x64 (kvm): 13638 (SM2.0 5175, SM3.0 5901, CPU 5030)
Windows 8.1x64 (native): 14143 (SM2.0 5170, SM3.0 6094, CPU 5802), výhoda native v CPU cca 15%.
Wprime 1.55 (vícevláknový CPU benchmark)
Windows 7x64 (kvm): 35,428s
Windows 8.1x64 (native): 34,594s , výhoda native cca 2%
SuperPi (jednovláknový CPU benchmark)
Windows 7x64 (kvm): 11,637s
Windows 8.1x64 (native): 11,580s , výhoda native cca 0,5%
Pozn. Pro relevatní testování by to chtělo silnější GPU, aby se mohly projevit případné rozdíly celkového výkonu. Použitelnost virtuální GameMachine je samozřejmě odvislá na mnoha dalších aspektech (zvuk,latence,..), na druhou stranu dnešní moderní HW by mohl jít svým výkonem/průchodností požadavkům naproti. Uvidíme zda X99/H-E splní v tomto naději či nikoli.
It is recommended to avoid device direct assignment to Virtual Machines in virtualized environments with this processor due to the lack of Access Control Services (ACS) support in PCI-Express root ports. Some Operating Systems may check for ACS support and potentially disable direct device assignment (that is, affects SR-IOV setup/ configuration within the server) as well.Z dokumentace k Intel C600 series chipsets:
Access Control Services (ACS)/Alternative Routing ID (ARI) are not supported on the PCI Express* Root Port of the Intel® C600 series chipset, devices connected to these ports may not support direct assignment or Single Root I/O Virtualization (SR-IOV).
Jak ten win v lin beha? Mam stare C2D - lenovo T400 a na nem W7. Chtel jsem delat dualboot, ale prijde mi, ze ve WIN pouzivam taky dohromady dve,tri aplikace a ze by mi stacil ve virtualce. ALE - kdyz na tom lenovu ve W7 virtualizuju UBUNTU, skoro vubec to nejede - ma to spatny vykon grafiky.
Proto by mne zajimalo, jak chodi takovy W7 naopak, pod linuxem? Da se na tom i na tom C2D pracovat trochu svizne, nebo je lepsi na takovem stroji pouzit dualboot?
P.
Všechny tyhle operace grafická karta urychluje.Počkej, jako že se grafice pošle JPEG a rozbalí se přes OpenCL? Nějak si nedokážu představit rozbalování JPEGu napsané v OpenCL.
Všechny tyhle operace grafická karta urychluje.„Všechny tyhle operace“ jsou konkrétně tyto tři (podle vašeho textu):
Ještě brutálnější jsou operace z RAW.Stejné tři kroky, dekomprese RAWu na grafické kartě je ještě daleko nepravděpodobnější, než u JPEGu.
strká do karty na jednotlivé video stránky fotky pro next/previous takže následná fotka je okamžitá protože jen přepne stránku. Je to brutálně vidět, když se stránkuje rychleZatímco když není dalčí obraz připraven ve videopaměti, ale vykresluje se tam nebo se do ní přesouvá z hlavní paměti, tak na překreslení čekáte? Takže třeba když pohnete kurzorem myši nebo dokonce přetahujete celé okno, nedejbože přehráváte video, tak vidíte, jak se obrazovka pomalu překresluje? Tomu bych věřil u dvacet let starého počítače…
následující asi 4 o trochu pomalejší fotky v RAM ale nezpracované pro výřezKdyž si takhle pustíte video, je to 25 snímků za sekundu. Osobní počítače to už hezkých pár let zvládají. Buď ty následující fotky prohlížíte větším tempem než 25 snímků za sekundu, nebo máte fotky v nějakém obrovském rozlišení, nebo je to zpomalení způsobené něčím jiným, než si myslíte. Ona ta RAM zas tak pomalá není.
Tiskni Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.