Como executar um vapor para o jogo do Windows no zangão?

Question

O que eu estou falando aqui é a horrível combinação Optirun / Primusrun + PlayonLinux + Steam que torna os wrappers em invólucros sobre invólucros (o primus / optirun chama o playonlinux, que chama o vinho através de um monte de scripts wrapper, que por sua vez chama steam, que finalmente chama o seu jogo executável)

E, não, não funciona tão bem.

No meu caso, o jogo em questão é o Audiosurf (primeiro de seu nome), embora eu também esteja interessado em fazer outros jogos (como Skyrim) funcionarem da mesma maneira.

Os fatos

O que tenho certeza é que o jogo é executado. Mas não no cartão nvidia.
Eu fiz o seguinte teste estúpido:

1. Verifique o status do daemon bumblebee em systemctl status bumblebeed
   Observe a linha do CGroup:

   CGroup: /system.slice/bumblebeed.service
                 └─809 /usr/sbin/bumblebeed

2. Execute o glxgears no bumblebee em primusrun glxgears

3. Enquanto ainda estiver executando glxgears , verifique novamente por bumblebee em systemctl status bumblebeed

   CGroup: /system.slice/bumblebeed.service
                 ├─ 809 /usr/sbin/bumblebeed
                 └─3707 Xorg :8 -config /etc/bumblebee/xorg.conf.nvidia -configdir ...

   Como seria de esperar, agora existe uma instância do servidor X, gerada pelo bumblebee, que está executando glxgears na placa nvidia

4. Pare glxgears e verifique novamente: A instância do X.org desapareceu

5. Agora inicie o jogo de vapor até primusrun e primusrun /usr/share/playonlinux/playonlinux --run "Steam" -applaunch 12900

6. E verifique o status do Bumblebee: Volte no passo 1, sem filho Xorg. (Certifique-se de estar no jogo quando fizer isso, não apenas no menu)

Eu usei primusrun porque se o programa não usa a placa gráfica, então nenhuma instância do Xorg é gerada, enquanto que o optirun de alguma forma força a instanciação do Worg

Eu até fui tão longe a ponto de parar o daemon zangão para ter certeza que o jogo ainda estava rodando (NÃO FAÇA ISSO! Se o programa está realmente rodando na placa nvidia que não seria apenas congelar a janela do seu lado, mas também protelar a GPU)

As conjecturas

Então, certo, o jogo não roda no Bumblebee; Mas cadê o problema?

Tem que ser porque, em algum lugar, um dos wrappers gera um novo processo e retorna. Tornando o processo de destino inacessível para primusrun. Mas quem é o culpado?
É um dos vários wrappers usados pelo playonlinux? Ou é só vapor?

Ou talvez seja ainda mais profundo do que isso: E se o Audiosurf simplesmente não usar o opengl? É claro que não nativamente , mas o vinho não traduz o DirectX chamadas para chamadas opengl?

Deixando de lado essa hipótese sombria, imaginei que deveria chegar o mais perto possível do executável antes de chamar primusrun. O ideal é algo como primusrun wine game.exe .

Então, como faço isso?

Bem, para começar, eu encontrei o "Comando para exec antes de executar o programa" no " Miscellaneous da janela de configuração do playonlinux, como sugerido por esta linha :

You can use this box to prefix commands to the shortcut. Handy in, say, the case of laptops with Nvidia and Intel graphics, and you need to use prefix primusrun or optirun before starting a particular game.

Mas acontece que isso é um completo BOLLOCKS

Depois de procurar nas fontes do PlayonLinux, encontrei o bastardo:

if [ -e "$HOME/.PlayOnLinux/configurations/pre_shortcut/$NAME" ]; then source "$HOME/.PlayOnLinux/configurations/pre_shortcut/$NAME" fi exec ./playonlinux-bash "$HOME/.PlayOnLinux/shortcuts/$NAME" "$@"

O arquivo $HOME/.PlayOnLinux/configurations/pre_shortcut/$NAME é onde o campo "Comando para executar antes de executar o programa" é salvo. Como você pode ver, este arquivo é source d, o que significa que você pode fazer um monte de coisas antes executando o programa (que seria a última linha com o comando exec ), mas não < em> como você está usando.

Então chamar qualquer wrapper como primusrun nessa caixa seria como bater no ar .

No entanto, seguindo essa liderança, descobri também que $HOME/.PlayOnLinux/shortcuts/$NAME contém uma chamada para a função POL_Wine seguida pelo arquivo .exe real, e isso é o mais importante que eu já entrei na cadeia de wrappers usados por POL.

Nota inferior

Eu percebo que eu tenho divergido muito do tópico entrando em detalhes, mas realmente quero dizer para esta pergunta incluir qualquer jogo a vapor ainda não disponível nativamente no Linux que possa ter os mesmos problemas, então vou tentar reformular as questões aqui (por favor, não apenas responda com "Você poderia fazer este hack para fazê-lo funcionar com o Audiosurf"):

• Por que meu jogo não está sendo executado na placa nvidia discreta quando usei primusrun / optirun ?
• O que posso fazer para contornar isso?

Answer 1

Posso responder à sua segunda pergunta: O que posso fazer para contornar isso?

O que queremos fazer é rodar o Steam através do PlayonLinux com optirun / primusrun como um prefixo. Todos os jogos que você executa no Steam também serão iniciados automaticamente assim.

Temos que ir para /usr/share/playonlinux/lib/

Existe um arquivo chamado wine.lib que editaremos.

Importante: crie um backup desse arquivo apenas para o caso de algo quebrar.

Dentro do arquivo, existe uma função chamada POL_Wine () .

Basicamente, o que queremos mudar dentro desta função é a forma como o vinho é executado toda vez que você inicia um aplicativo através do PlayonLinux.

Então, dentro desta função você tem que encontrar todas as partes onde o vinho é chamado. Procure wine "$@" no arquivo com ctrl + F no seu editor de texto favorito. No meu arquivo havia 3 ocorrências de wine "$@" .

Antes de cada ocorrência, acabei de adicionar primusrun , então parece primusrun wine "$@" . Você pode experimentar optirun ou optirun -b primus , mas primusrun é o que funciona para mim.

É assim que a seção que eu editei parece agora:

if [ "$POL_OS" = "Linux" ] || [ "$POL_OS" = "Mac" ];
then
    if [ "$LOGFILE" = "/dev/null" ]; then
        $BEFORE_WINE $(POL_Config_Read BEFORE_WINE) primusrun wine "$@"  2> >(grep -v menubuilder --line-buffered | tee -a "$WINEPREFIX/playonlinux.log" >&2) > >(tee -a "$WINEPREFIX/playonlinux.log")
        errors=$?
    else
        $BEFORE_WINE $(POL_Config_Read BEFORE_WINE) primusrun wine "$@" 2> >(grep -v menubuilder --line-buffered | tee -a "$LOGFILE" "$WINEPREFIX/playonlinux.log" >&2) > >(tee -a "$LOGFILE" "$WINEPREFIX/playonlinux.log")
        errors=$?
    fi
else
    # FIXME 
    $BEFORE_WINE $(POL_Config_Read BEFORE_WINE) primusrun wine "$@"  2> "$WINEPREFIX/playonlinux.log" > "$WINEPREFIX/playonlinux.log"
    errors=$?
fi

Salve o arquivo e inicie o PlayonLinux normalmente.

Você pode verificar a qualquer momento se sua placa de vídeo discreta é usada ou não, executando o seguinte comando em um terminal:

optirun --status

Quando NÃO é usado, a saída é assim:

Bumblebee status: Ready (3.2.1). X inactive. Discrete video card is off.

Selecione o Steam em seus aplicativos do PlayonLinux e execute-o. Quando for iniciado, verifique com optirun --status para ver se o seu cartão discreto está ativado.

Minha saída ficou assim:

Bumblebee status: Ready (3.2.1). X is PID 26685, 1 applications using bumblebeed.

Ótimo! O Steam agora está usando seu cartão discreto!

Agora, vamos tentar iniciar um jogo no Steam. Escolha um e inicie-o normalmente (não é necessário mexer nas opções de lançamento no Steam).

Verifique novamente com optirun --status . A saída deve ficar assim:

Bumblebee status: Ready (3.2.1). X is PID 26685, 2 applications using bumblebeed.

Wondeful! O jogo que você lançou também está usando seu cartão discreto!

A beleza disso é que funciona com qualquer aplicativo que você execute no PlayonLinux, não apenas no Steam.

Para reverter as alterações, basta usar o arquivo de backup que você criou ou apenas excluir os prefixos adicionados em wine.lib e salvar o arquivo. Tente todos os prefixos diferentes que mencionei acima se você tiver problemas.