“Tirando leite de pedra” de computador fraco – Parte 1

Hoje mostrarei um sistema Linux console: mais otimizado que o SteamOS, que inicia com apenas 100 Mb de RAM e roda games em computador fraco!

---

| Se você apoia nosso site, desative o AdBlock quando visitá-lo, inclusive em Mobile!
Os anúncios são poucos e não invasivos. Se quiser contribuir com nosso trabalho, clique em qualquer banner de sua preferência, exceto dos Parceiros. Mais detalhes clicando aqui.

---

1. Introdução

Há um bom tempo atrás mostrei aqui no site de onde vem a otimização dos consoles: na ocasião vimos videogames como o PlayStation 2 e o Xbox 360, por exemplo, com tão “pouco” hardware, conseguem rodar games, que no PC exigiriam mais hardware do que o teoricamente realmente necessário.

No Linux hoje trarei um teste e um tutorial interessante: Como rodar um game num Linux sem interface para computador fraco!
Sem desktop, somente terminal. E o quanto isso dá de desempenho extra a um mesmo hardware!

O foco de hoje, será em computadores absolutamente ruins, fracos, e como tirar “leite da pedra”, ou seja, otimiza-los para rodar games com mais desempenho.

2.Especificações de Hardware

A novela começou quando pensei em ver qual o limite de execução de games de um computador fraco que possuo guardado.

O hardware em questão a ser testado inicialmente foi:

• Netbook Asus – Modelo X102B
• CPU AMD APU A4-1200 @ Máx. 1.0 Ghz!
• GPU Kabini – Radeon HD 8180
• 2 Gb de RAM DDR2 – Sendo que 512 Mb ficam reservados para Vídeo, restando 1,5 Gb de RAM pra uso.
• SSD de 60 GB – O netbook já é lento demais, se fosse HDD… Melhor nem comentar!
• Sem bateria
• Touchscreen
• Sem qualquer suporte a Vulkan!

É um hardware de respeito, negativamente falando. Originalmente rodava Windows 8.1, nada que instalei nele rodou “decentemente” até então, exceto Androix86, transformando-o em um Chromebook. Mas sua placa de vídeo fraca atrapalha o desempenho final, então os apps que ele executou eram bem básicos, nada que exija aceleração 3D de fato, realmente um computador fraco.

A ideia é: O que conseguimos rodar com ele, com tão limitadas especificações?
E o quão melhor conseguimos rodar com ele, com um sistema sem interface?

3. Especificações de Software

Realizei os testes sobre o Ubuntu, porque eu já o conheço a fundo e sei de suas capacidades. Não quis arriscar um sistema como Manjaro por não ter o mesmo domínio do sistema e correr o risco de fazer testes injustos.  e criando inimigos

Lado a lado, dois sabores diferentes neste mesmo hardware:

• Ubuntu MATE 21.04 – Instalação Mínima via Ubiquity!
  Possui interface de usuário mas programas básicos por padrão.
• Ubuntu Minimal 20.04 LTS – Sem qualquer serviço adicional selecionado no Tasksel!
  Portanto de execução sumariamente grosseira e simples.

Ambos com ajustes de otimização, são eles:

• Swappiness ajustado para 10!
  vm.swappiness=10 >> sysctl.conf

Assim o sistema só fará o despejo de SWAP quando atingir +89% de RAM total em uso.

• Montar a /tmp na RAM
  tmpfs /tmp tmpfs defaults 0 0 >> /etc/fstab
• Montar a /var/tmp na RAM
  tmpfs /var/tmp tmpfs defaults 0 0 >> /etc/fstab

Dessa forma, as pastas de arquivos temporários do sistema usarão a RAM em vez do SSD para armazenar dados; consome um pouco mais de RAM, mas otimiza mais o sistema, diminuindo os gargalos.

E por fim, mitigations=off em /etc/default/grub – conforme já falei aqui no site – para desligar todas as correções da Intel/AMD e dar máximo desempenho ao netbook; e removi o parâmetro Splash, para que o sistema não abra a tela Splash no carregamento!

GRUB_CMDLINE_LINUX_DEFAULT=”quiet mitigations=off”

Além disso, após os updates, o Ubuntu MATE 21.04 ficou como:

• OpenGL 4.5
• DRM 2.50.0
• LLVM 11.0.1
• MESA 21.0.1
• Kernel Linux 5.11.0-22-generic

Já o Ubuntu Minimal 20.04 ficou como:

• OpenGL 4.5
• DRM 2.50.0
• LLVM 11.0.0
• MESA 20.2.6
• Kernel Linux 5.4.0-77-generic

E por fim, o consumo de RAM, após o boot, com o sistema em idle:

• Ubuntu MATE 21.04
  481 Mb de uso real, sendo 503 Mb de Buff/Cache (totalizando 984 Mb em uso) e 430 Mb livres totais
• Ubuntu Minimal 20.04 LTS
  110 Mb de uso real, sendo 150 Mb de Buff/Cache (totalizando 300 Mb em uso) e 1.1 Gb livres totais

A memória RAM total disponível é apenas 1.5 Gb, porque 512 MB ficam separadas para vídeo nesse netbook – e o restinho, pra conta fechar, fica com o Kernel!

3.1 Nossas apostas

Com o Ubuntu MATE 21.04, o sistema teoricamente deveria rodar melhor os games, porque está com um Kernel Linux mais novo, há um compositor de tela e drivers mais atualizados – bleeding edge – comparado á versão anterior do Ubuntu Minimal 20.04 LTS!

4. Testes

4.1 Firefox

Inicialmente testei o consumo de CPU e RAM com o Firefox 90.0 em ambos sistemas.

• Ubuntu MATE 21.04
  O Firefox aumentou o consumo de RAM para 750 Mb, uso de Swap foi para 1 Mb.
• Abri o Youtube apenas, e entrei neste video. – Sem Copyrights!
  Após a conclusão da reprodução do mesmo, em 360p – deixei selecionar automaticamente – a RAM usada foi para 911 Mb e a Swap para 123 Mb!

Com o uso de SWAP, ao fechar o Firefox, o sistema ficou engasgando até que os 123 Mb despejados retornassem á RAM propriamente dita. – Os valores de Buff/Cache subiram pra aproximadamente 450 Mb.

Visivelmente funciona porém com desempenho aquém do desejado.

Com tais resultados, dei boot no Ubuntu Minimal 20.04 LTS.

• Ubuntu Minimal 20.04 LTS
  O Firefox aumentou o consumo de RAM para apenas 354 Mb, sem usar Swap!
• Abri o Youtube apenas, e entrei neste video. – Sem Copyrights!
  Após a conclusão da reprodução do mesmo, em 480p – deixei selecionar automaticamente – a RAM usada foi de 598 Mb e a Swap continuou ZERO Mb! O Buff/Cache subiu pra 541 Mb e o espaço livre em 660 Mb.

Ou seja, ponto positivo para o sistema sem interface: O consumo de RAM foi absurdamente baixo e o desempenho da reprodução não foi afetado no gargalo ocasional pelo despejo de Swap, inclusive permitindo executar o mesmo vídeo com uma resolução maior.

4.2 Games

Em games, eu testei um dos poucos games pesados que teoricamente deveriam rodar nesse computador fraco: Driv3r!
Instalei o game com o WINE 6.12, pacote Staging do repositório do Xubuntu, sob o qual inicializei o game.

Os comandos usados foram:

$ echo “deb https://download.opensuse.org/repositories/Emulators:/Wine:/Debian/xUbuntu_21.04 ./” | sudo tee /etc/apt/sources.list.d/wine-obs.list
$ wget -O- -q https://download.opensuse.org/repositories/Emulators:/Wine:/Debian/xUbuntu_21.04/Release.key | sudo apt-key add –
$ sudo apt install winehq-staging

Uma observação importante:

Devido ao despejo de SWAP do teste anterior, reiniciei o netbook para que o sistema ficasse com a RAM o mais livre possível para não afetar os testes.

Entramos no jogo, cujas configurações foram definidas no seguinte:

Apos alguns minutos jogando, o resultado foi este:

Note que o baixo desempenho pode ser percebido a olho nu.

Nesse momento, a RAM consumia:

Incríveis 1.1 Gb, com 125 Mb disponíveis e 101 Mb de SWAP sendo despejado no meio do jogo!

Agora, o mesmo game, porém no Ubuntu Minimal, os resultados foram os seguintes:

Eu não dirijo mal,  fiz intencionalmente para averiguar o uso de placa de vídeo na renderização dos danos aos veículos.

Note como o jogo está, a olho nu, mais fluído que no vídeo anterior, com mais estabilidade de FPS.
O consumo de RAM?

Apenas 850 Mb totais, com 430 Mb disponíveis e apenas 1 Mb de Swap foi despejado! Vitória pro computador fraco!

5. Como fazer isso?

Aos leitores que quiserem se aventurar em fazer seus testes com um sistema limpo, sem interface, apenas Terminal de Comandos para computador fraco, faça o seguinte:

1. Instale o Ubuntu Minimal 20.04 LTS – Pegue a versão Minimal mais recente, com base no último LTS.
   Ou o sistema Linux de sua preferência, desde que seja 100% sem interface!
   O Xorg costuma bugar e os testes não funcionam adequadamente se você tentar fazer isso com uma distro com interface instalada rodando no TTY7.
2. Instale estes 2 pacotes:
   $ xterm
   Faz a ponte entre o shell e o XOrg
   $ xorg
   Com o parâmetro –no-install-recommends se utilizar distros com base em APT
3. Na hora de executar algo, por exemplo o Firefox, faça desta forma:

$ xinit firefox $* -- :0 vt$XDG_VTNR

Para rodar o comando no TTY1 mas abrir o vídeo no TTY3, por exemplo, esse ato requer root:

$ sudo xinit firefox $* -- :1

5.1 FAQ

A seguir algumas dicas, truques e comandos que vão salvá-los caso encarem o desafio de rodar aplicações de forma headless – somente terminal!

A medida que eu descobrir novas dicas e observações, adicionarei elas nesta sessão!

• Todo pacote que instalar, SEMPRE tente usar o parâmetro –no-install-recommends, principalmente se usar Ubuntu e seus sabores. Alguns metapacotes, por padrão, podem simplesmente forçar a instalação do restante da interface de usuário, quebrando seu sistema e/ou tornando sua experiência problemática.
• Você pode abrir quantas aplicações desejar nos TTY’s do sistema.
  Poderá abrir o Chrome no TTY1, enquanto abre a Steam no TTY2. Alterne com CTRL+ALT+Fx (Ubuntu, Debian, etc)
• Caso abra o Youtube no TTY1, e fizer login no sistema com o mesmo usuário no TTY2, o som do TTY1 reproduzirá no TTY2!
  Esse é o modo de funcionamento padrão dos canais de audio no kernel Linux. Você pode reproduzir sons diferentes em diferentes TTY, porém tudo ficará “misturado” nos auto falantes.
• O Ubuntu Minimal vem sem som por padrão. Instale estes pacotes para ter audio:
  $ sudo apt install alsa-base pulseaudio
  Reinicie seu sistema. O áudio funcionará imediatamente. Para controlar o Volume, entre no comando $ alsamixer
  O mesmo vale para fones de ouvido: Basta plugar e o som sairá nos headphones. Controle o volume pelo alsamixer.
• Ainda não encontrei uma forma prática e direta de controlar o brilho de tela nos notebooks.
  O brilho ficará no máximo, sempre, por padrão.
• Se quiser Mouse, instale este pacote: gpm
  Ele permitirá que seu touch, trackpad e/ou mouse funcione normalmente em qualquer TTY!
  Por padrão o Xorg nas janelas abertas gerará um Mouse, sem maiores empecilhos/problemas.
• Sem um compositor de janelas, você não conseguirá fechar, maximizar ou minimizar uma janela diretamente.
  Para maximizar, force com parâmetros (abaixo explico detalhes). Para fechar, dê CTRL+Q ou clique “Arquivo > Sair”, no menu.
• O Firefox tem uma grande dependência com o compositor de janelas, bugando os menus sem uma interface. Recomendo que use o Google Chrome, que possui um motor de exibição mais sólido, que independe de janelas.
• Para rodar games ou aplicações sob WINE/Proton, crie um .sh – shell script – que inicialize esse game/aplicação específico. Na hora de executar, faça:  $ xinit /caminho/completo/do/script.sh $* — :0 vt$XDG_VTNR
  Um exemplo do que colocar dentro do .sh:
  WINEPREFIX=”/caminho/do/game” wine “/caminho/do/game/game.exe”
  Se for Lutris:
  lutris lutris:rungame/nome-do-game
  Ou apenas “exporte” um atalho no Desktop e copie o caminho do Atalho!
  Se for Steam e Proton:
  ~/.steam/steam/steamapps/common/<nome do jogo que quer rodar>
  Vai ter provavelmente uma versão x86 ou x64, escolha a mais adequada.
  Ou exporte o atalho do game e use o caminho do atalho no Terminal!
• Você pode forçar a aplicação a ficar em tela cheia desde que você saiba como passar os parâmetros.
  Se for o Google Chrome, crie um chromefull.sh e coloque:
  google-chrome-stable –window-size=1360,768
  Se for o Firefox, crie um firefull.sh e coloque:
  firefox -width 1360 -height 768
  Onde 1360 e 768 é a sua resolução de tela, altere de acordo com seu monitor. Execute-os conforme mencionado acima para que abram em tela cheia.
  Na hora de executar, faça, por exemplo:  $ xinit /caminho/completo/do/firefull.sh $* — :0 vt$XDG_VTNR
• Algumas aplicações, mesmo que instaladas, exigirão o caminho completo para executar! Por exemplo:
  $ xinit /usr/bin/microsoft-edge $* — :0 vt$XDG_VTNR
• Steam foi testada, funciona normalmente, executa e abre!
  Porém os games dentro da Steam ainda não testei.
  Da mesma forma não sei dizer como forçar a Steam a ficar de tela cheia, por enquanto ela abre apenas em modo janela.
• O Kodi, instalado direto do repositório, funcionou perfeitamente também.
  Por padrão ele abrirá em tela cheia, o que não será um problema. No netbook dos testes, rodou liso, sem engasgos.
• Se for instalar um programa .deb via terminal utilize:
  $ sudo dpkg -i nome-do-programa.deb
  Se der erro de dependência não contentável, tente este em seguida:
  $ sudo apt install -f
  O sistema deverá baixar os pacotes ausentes e concluir; Se não funcionar, o pacote é incompatível com seu sistema.
• A Aceleração 3D das aplicações dependerá unicamente dos drivers disponíveis no sistema. Se estiverem adequadamente instalados, o XOrg os chamará quando for pertinente durante a execução da aplicação.
  Se houver Screen Tearing, faça como ensinado aqui para eliminar o problema!
• Se a aplicação não abre, dá muitos erros e fecha, verifique se o caminho dela está correto, completo, e se os parâmetros de execução, se houverem, estão adequadamente inseridos. (Use um .sh á parte para garantir! Não passe parâmetros diretamente para o comando xinit, ele não aceitará).

6. Análise Opinativa

A princípio realizei os testes focando em “tirar leite da pedra” de uma máquina ruim – ruim é apelido, ela é horrível! – com o sistema enxugado a ponto de ter apenas o terminal e inicializando com 110 Mb de RAM.

Os testes foram promissores e haverá uma Parte 2 desta publicação! Na próxima, pretendo trazer os testes, porém, para um computador gamer, com uma GTX 1050, e o quanto de ganho de FPS se consegue num sistema sem interface, se comparado a um com interface.

Voltando ao tópico da otimização dos consoles, um sistema Linux normal utiliza estas camadas de execução de um game:

Jogo > OpenGL (ou Vulkan) > X.Org > GPU > Tela

O kernel Linux está nas > acima! É a cola que une os componentes do computador e faz tudo funcionar.

Com um sistema headless, não pulamos etapas como se possa pensar, apenas filtramos mais a parte que tange a etapa X.Org – e seus asseclas, como o gerenciador de janelas, o compositor de tela, etc – e executamos tudo mais diretamente, sem percalços.

Ou seja, após tudo isso, é notável que aja um ganho de desempenho visível, palpável, substancial num mesmo computador fraco. Uma pena que, para tal, é pertinente que o usuário tenha conhecimento profundo do Terminal e esteja disposto a abrir mão dos “luxos” de se ter um compositor de janelas cuidando de tudo!

Mas e o Wayland?

Possivelmente com Wayland o desempenho fique ainda melhor sem precisar matar toda a interface. Isso explica a recém empreitada da Valve em apostar no KDE Plasma no SteamOS3; Mesmo com XOrg, o Plasma possui um desempenho superior aos compositores de tela convencionais.

Lembrando que não só de compositores se faz um sistema, sem interface de usuário o Ubuntu ficou sem gestor de Wifi, sem Bluetooth, sem menus, sem preempção de desktop, sem servidor de impressão, etc. Em suma, capado! E capado, sobra mais poder de CPU/RAM para usar, tornamos o PC um videogame, com funcionamento dedicado a uma tarefa específica, seja ela um game ou aplicação.

Para aqueles que estiverem dispostos, não há dúvidas que valha a pena o esforço para fazer a execução dessas aplicações num sistema sem interface, com o nível de desempenho que se ganha no final.

O que acharam? Farão os testes também? Consideraram a ideia de usar um sistema sem interface para computador fraco?
Vejo vocês na próxima publicação, a Parte 2.
Até lá!

#UrbanCompassPony