Inicialmente: não me responsabilizo por danos ou perda de capacidade consequentes de seguir esses passos. É por sua própria conta e risco. O que está descrito aqui foi testado e funcionou de forma adequada, mas não é possível garantir o pleno funcionamento de nada descrito aqui ou outros casos implícitos.
Algumas etapas como a configuração do servidor VNC sem senha e a não ativação do firewall foram feitas de tal forma porque considera-se que o sistema convidado pode ter plena confiança no hospedeiro e ele só pode ser acessado a partir do hospedeiro. Não exponha um computador configurado daquela forma direto na internet!
Nas referências, há algumas opções adicionais que são utilizadas nos exemplos, mas que não foi possível encontrar suas funções e, aparentemente, a ausência não prejudicou o desempenho ou a estabilidade dos convidados ou do hospedeiro. Por isso, foram omitidas.
Prepare-se para o dmesg ficar vermelho: muitíssimas mensagens de erro surgem, praticamente todas inofensivas. A partir da versão 4.17 do kernel
Linux, várias delas deixaram de existir, tornando a leitura do dmesg mais fácil.
O quão capazes são os convidados criados com iGVT-g? Os resultados variam bastante, mas geralmente eles são muito positivos. Referente às capacidades de codificação de vídeo com VA-API, um vídeo de teste foi usado como referência. O teste realizado é codificar esse vídeo usando o FFmpeg com o seguinte comando:
ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -i input.webm -vf format=nv12,hwupload -acodec aac -vcodec h264_vaapi output.mp4
O hospedeiro com Xubuntu 18.04 codifica o vídeo a uma velocidade de 13,5x o tempo real. O convidado com Xubuntu 18.04, executando o mesmo comando com a mesma versão do FFmpeg para codificar o vídeo o codifica a uma velocidade de 8x o tempo real.
Foi percebida uma diferença notável no uso de recursos do hospedeiro entre o comando ser executado no hospedeiro ou no convidado. Usando o programa intel-gpu-overlay junto com o Xephyr, foi possível capturar a tela mostrando a diferença existente:
Hospedeiro:
Convidado:
No Windows 10, o FFmpeg utiliza os codificados Intel QSV (Quick Sync Video) ao invés de VA-API. O comando no Windows ficaria algo como:
ffmpeg -i input.webm -acodec aac -vcodec h264_qsv output.mp4
E a velocidade obtida foi de 5,5x o tempo real. A versão do FFmpeg era diferente, o sistema era diferente e, mesmo assim, o codificador Intel QSV funcionou corretamente.
Os resultados de benchmark foram bastante interessantes. Foi utilizado o PassMark PerformanceTest 9.0 para obter os resultados. O sistema hospedeiro com Windows 10 obteve o seguinte resultado:
O convidado Windows 10 com o driver versão 15.45:
O convidado Windows 10 com o driver versão 24.20:
Chegou-se ao ponto de o convidado ter um desempenho 3D maior que o hospedeiro, mesmo com a sobrecarga do KVM mais o hospedeiro Linux. Evidentemente, um teste do "mundo real" deveria ser feito:
Esse é um dos exemplos de modelos de simulação disponíveis no Tecnomatix Plant Simulation 13, da Siemens. Sistemas Windows já penam para exibir simulações mais complexas em 3D, o convidado lidou super bem com ela.
Esses vales no uso de GPU ocorriam puramente devido à configuração do som. O som mal configurado prejudica muito o funcionamento do convidado Windows 10.
Praticamente todos os aplicativos testados funcionam corretamente no convidado Windows 10. Há um único jogo que, por um motivo conhecido (port mal-feito) não abre. A primeira tela carrega, mas então o logo da desenvolvedora não aparece e o jogo trava.
É raro um projeto chamar tanto a minha atenção, mas ver do que a solução Intel GVT-g é capaz, ter visto esse projeto evoluir de "tela azul a cada 2 minutos com o sistema sem uso" para "5 horas de teste de tortura" e podendo usar algo tão avançado com um simples Intel Core i3-6100U e uma Intel HD Graphics 520 é realmente espetacular.
Referências