Proton: [Solicitação de recurso]: Patches de Gálio Nove

Esta é uma opção muito melhor. E ouvi dizer que está sendo mesclado ao DXVK (eventualmente), então teremos todas as versões do D3D cobertas de 9 a 12. Os mais antigos não precisam dos recursos do Vulkan de qualquer maneira, acredito que os jogos D3D 8 poderiam até mesmo ser executados em um processador de software em 60 FPS em hardware moderno.

Muito interessante! Onde você descobriu que ele seria mesclado com o DXVK?

Não consigo encontrar nada sobre isso, então posso estar enganado. Provavelmente não será incorporado diretamente ao DXVK, mas sim suportado junto com ele ou mesclado ao Wine. Lembro-me vagamente desses dois projetos mencionados no mesmo contexto (o que não é surpreendente) de substituir a tradução D3D => OGL ou algo parecido. De qualquer forma, acho que a sobrecarga do Vulkan é insignificante em comparação com a abordagem direta do Gallium Nine, mas os benefícios são óbvios - todos os jogadores podem usá-lo, não apenas aqueles com drivers FOSS. E pode ser levado ainda mais longe, para o próprio Windows, para que os usuários do Windows possam executar jogos com desempenho possivelmente melhor devido à melhor utilização da CPU ou executá-los, pois alguns jogos mais antigos não funcionam mais no Windows moderno, mas funcionam no Wine.

Concordo que o VK9 ou algo semelhante seria a melhor solução / implementação. No entanto, tanto quanto eu entendo, a versão atual do VK9 ainda é uma prova de conceito e suporta muito pouco ou nenhum jogo. Ele só pode renderizar alguns testes DirectX9 simples.

Os patches Gallium Nine estão prontos, bem testados por muitos jogadores e oferecem desempenho (quase) nativo. Implementar isso seria bastante trivial, uma vez que os patches já estão lá. Seria uma adição muito bem-vinda para todos os jogadores AMD / Intel por enquanto, até que o VK9 atinja a maturidade.

O VK9 está a anos de ser concluído e acho que até mesmo a sobrecarga do d3d-pba poderia ser considerada "insignificante".
Se houver, gostaria que o próton (mas mesmo o vinho upstream) tivesse alguns tipos de prioridades.
Digamos, primeiro nativo (gálio) ou vulkan (dxvk), depois o outro, por último, mas não menos importante, wined3d (porque nem todo gpu por aí suporta vulkan)

ps Nine não funciona para usuários Intel

Como há centenas de jogos Direct3D 9 ainda sendo jogados no Steam e como Gallium Nine provou ser muito mais eficiente do que o tradicional d3d9 Wine, deve ser um recurso opcional pelo menos via user_setting.py.

Eu preferiria que a válvula mesclasse VK9 com DXVK. portanto, eles têm uma cobertura vulkan uniforme.

Claro, em um mundo ideal. Mas o VK9 não rodou um único jogo até agora e está apenas na fase de prova de conceito. Ele pode executar alguns testes simples dx9 e é isso. Além disso, o cara que está trabalhando nisso o considera um projeto de hobby e não dá tanto trabalho quanto o cara que desenvolve o DXVK. Pode levar anos até que o VK9 esteja pronto para ser usado. Enquanto isso, por que não usar patches para usuários AMD bem testados e totalmente finalizados?

Eu concordo que os patches Gallium 9 devem ser usados ​​por usuários AMD mesa. Faz parte do mesa, só precisamos da versão wine para permitir seu uso.

Concordou. E quem sabe? Talvez num futuro próximo não sejam apenas o radeonsi e o nuveau que se beneficiariam disso?
https://www.phoronix.com/scan.php?page=news_item&px=Intel-Iris-Gallium

Eu tive muito sucesso com isso e os patches estão bem mantidos. Os pacotes Mesa são construídos no openSUSE e todos funcionam juntos. Geralmente vai de jogável com muitos travamentos a suave como a seda, enquanto outros jogos ficam com uma tela preta. Teria que ser alternável ou duas versões do wine ou algo assim com os padrões fornecidos para jogos suportados.

Gálio Nove tem sido nada menos que fantástico em minha experiência. Seria ótimo vê-lo incluído no Proton.

Eu pessoalmente voto a favor da abordagem totalmente Vulkan.

@ shoober420 Eu também preferiria isso eventualmente. Mas uma camada translacional de trabalho dx9 para vulkan está a um ano de ser concluída, se isso acontecer. Por que não permitir que os usuários da AMD aproveitem o desempenho nativo do dx9 por meio dos patches Gallium Nine bem testados e totalmente finalizados? Eles só precisam ser combinados para que os usuários AMD possam aproveitar o desempenho nativo agora.

@ shoober420 Acho que todos nós preferimos essa rota para o próton. É o passo lógico em frente. Não estamos pedindo que a válvula renuncie a uma implementação vulkan do d3d9. Estamos pedindo que eles permitam que as pessoas com drivers à base de gálio aberto usem o que já possuem. O Gálio 9 já faz parte do nosso pacote de drivers. O "Gallium nine patches" para o vinho simplesmente pula a tradução padrão da api d3d9 para opengl e, em vez disso, alimenta as chamadas api diretamente para o gpu. Evitando perda de desempenho devido à tradução da API.

@Mushoz @Xalphenos

Eu vejo seus rapazes apontam, vocês dois estão certos. Eu não sabia que o VK9 estava tão longe. Em seguida, apóio a escolha de mais opções. Posso usar um AMD ou Intel um dia.

Eu fiz o trabalho para construir todas as variações de wine, staging e nove para o openSUSE. Basicamente, basta aplicar o conjunto de patches relevante de https://github.com/sarnex/wine-d3d9-patches e compilar normalmente. Portanto, precisamos compilar o wine duas vezes e fornecer uma opção para um binário específico.

Para referência, o pacote openSUSE / wine que constrói todos os quatro sabores de vinho.

• vinho
• vinho-nove
• encenação de vinho
• vinho-encenação-nove

Não tenho certeza de qual é a situação no próton em relação ao estadiamento do vinho. Se ninguém mais conseguir fazer isso e a Valve não se opor, posso dar uma facada, mas o Steam precisaria de uma opção de IU para realmente adicionar o polimento.

O que você está pensando é o nº 22. Pode haver algum mecanismo para adicionar o próprio tempo de execução, mas ele é desconhecido no momento.

Mas para mim, vinho e próton deveriam ter apenas um mecanismo elegante de fallbacks. De vulkan a gálio, a opengl .. Dependendo do fallback mais funcional que você pode usar em seu sistema.

Certamente relacionado, mas este pedido sempre terá que ser opcional pela mesma razão que o wine upstream não o mescla ... ele não funciona em todas as plataformas e apenas com um subconjunto de placas que podem usar os drivers Mesa relacionados. Isso é um pouco diferente das outras alterações feitas no wine neste repo (além de excluir as cartas mais antigas). # 22 permitiria que alguém com um wine-nine construído o substituísse, mas este problema é sobre tê-lo como parte da construção oficial.

Sim ... e não vejo o que é difícil verificar qual driver está sendo usado, em qual hardware e encerrar o dia (o mesmo para vulkan ou opengl, de qualquer maneira)

Eu também não, nunca disse que não era. Apenas respondendo ao nº 22, que é especificamente sobre a escolha de builds personalizados fora do próton, que não é o que estou propondo nem sobre esse assunto.

Dada a extensa natureza da diferença de ValveSoftware / wine (3.7) vs wine / wine (3.7) e a abordagem que a Valve está adotando, provavelmente faz mais sentido fundi-la diretamente em seu garfo de vinho. Ele então a) teria que ser alternado em tempo de execução (possivelmente automaticamente) ou compilado duas vezes (acredite que os patches já incluem uma alternância em tempo de compilação).

Os patches de tag 3.7 não se aplicam de forma limpa ao ValveSoftware / wine.

error: patch failed: configure.ac:1261
error: configure.ac: patch does not apply
wine-d3d9.patch:5385: new blank line at EOF.
+

Pode ser simples, mas imagino que este seja um problema contínuo que provavelmente seria outro motivo para mesclar diretamente nessa bifurcação.

Eles irão atualizá-lo assim que lidar com "problemas de inicialização"

... além disso, talvez fosse mais produtivo se você trabalhasse primeiro para conseguir isso na encenação

Atualizar a versão do wine não era o que eu pedia ou precisava enquanto aplicava os patches para o 3.7. Quanto ao preparo, este tem sido um pedido de longo prazo no qual o wine upstream não está interessado principalmente porque não funciona no Mac e nem em todos os hardwares Linux. Conseqüentemente, o próton está integrando uma variedade de melhorias de desempenho que limitam o escopo do hardware ... então, isso pode ser do interesse deles.

Fazê-lo no estágio de vinho ou no vinho propriamente dito seria ótimo, mas você pode encontrar muitas questões anteriores indicando que isso não acontecerá em nossa vida.

Mac não é um problema, nem compatibilidade de hardware (_especialmente_ após os últimos rumores da Intel).
Você pode ver meus links para saber por que o problema mais ... preocupante, pelo menos por enquanto, é apenas a falta de reconhecimento em primeiro lugar.
(por tanto, quem sabe, talvez já cheguem a um consenso sobre o IRC)

Mesmo se o VK9 estivesse pronto para o Proton, eu preferiria a solução mais eficiente. Até que a Proton ofereça isso, eu continuo usando meu antigo e confiável vinho de nove patches para jogos que dependem de d3d9.

Estou plenamente ciente de que o Gálio Nove não será (e provavelmente nunca será) a solução mais eficiente para todos , mas esse não é o meu ponto aqui. Ter isso como uma opção para aqueles que têm um driver Gallium seria ótimo! :)

Aqui está a solução:
https://www.phoronix.com/scan.php?page=news_item&px=Zink-Gallium3D-OpenGL-Vulkan
https://gitlab.freedesktop.org/kusma/mesa/tree/zink/src/gallium/drivers/zink

Basicamente, Gallium3D sempre foi uma abstração tênue entre vários rastreadores estaduais e os drivers, então apenas calçadeira em Vulkan como um piloto e bam, você tem todos os rastreadores estaduais suportados, incluindo Gallium nove e OpenGL da Mesa. O ciclo de vida do bytecode do shader será o bytecode DX9 HLSL do jogo-> TGSI-> NIR-> SPIRV uau, se funciona, funciona .... :)

A única coisa que vejo como uma "solução" é uma solução temporária para as placas Nvidia antes que o VK9 esteja pronto. Certamente não seria mais rápido na AMD.

@ jerbear64 Gallium Nine já foi bastante testado em batalha pelo que vejo, pelo menos no driver amdgpu. Eu costumava pensar que isso poderia ter sido feito desde o início, mesmo com o caso do DXVK, poderia ter sido apenas um rastreador de estado dentro do Mesa também e então apenas escrever algo como ZINK no final para drivers fechados ou usar o hardware nativo diretamente sempre que possível. Não reclamando ... :)

Nem todo mundo usa mesa.

Na quarta-feira, 26 de setembro de 2018, 20:35, Alex Fuller, [email protected] escreveu:

@ jerbear64 https://github.com/jerbear64 Gallium Nine já é bastante
testado em batalha pelo que vejo, pelo menos no driver amdgpu. eu era
muitas vezes pensando que isso poderia ter sido feito desde o início, mesmo com DXVK's
caso poderia ter sido apenas um rastreador de estado dentro de Mesa também e então
basta escrever algo como ZINK no final para drivers fechados ou usar o
hardware nativo diretamente onde possível. Não reclamando ... :)

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/ValveSoftware/Proton/issues/66#issuecomment-424824077 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAipRw-R-g3DJOiWzHdR5SOHBu2X-xCxks5ue8jigaJpZM4WHXpZ
.

@cjwijtmans bem com isso todos podem ter um driver vulkan existente, seria apenas uma lib para vincular como DXVK ...

Aqui está outra maneira de ir:

https://github.com/GabrielMajeri/d3d9-to-11

dgVoodoo já implementa direct3d 1 a 7 mais 8.1 a 11 entre outras coisas, de modo que a reimplementação do projeto de direct3d9 em direct3d 11 permitiria que todas as versões antigas de direct3d apenas rodassem em DXVK.

@ jerbear64 isso soa ao contrário. Nine é inútil apenas no proprietário da nVidia. Com a AMD, você usa o Mesa predominantemente. A Intel também está construindo um novo driver Gallium3D, então esta será a solução Intel + nouveau + AMD em algum momento no futuro.

Parece que dgVoodoo está trabalhando no suporte D3D9:

https://www.vogons.org/viewtopic.php?f=59&t=34931&start=3780#p705374

É limitado ao modelo de sombreador 1.x. Isso significa que os jogos que usam D3D9 com shader modelo 1.x podem ser executados em cima do DXVK em seu próximo lançamento. A desvantagem disso é que o dgVoodoo não é um código aberto.

Pelo que vale a pena, agora temos suporte para parte Mesa do Gallium Nine agora no Steam Flatpak devido à demanda por outras aplicações Flatpak

@ jerbear64 isso soa ao contrário. Nine é inútil apenas no proprietário da nVidia. Com a AMD, você usa o Mesa predominantemente. A Intel também está construindo um novo driver Gallium3D, então esta será a solução Intel + nouveau + AMD em algum momento no futuro.

Bem, é inútil para os usuários da Nvidia, mas não quebra a compatibilidade com ele. Tudo bem dar algo para usuários de gráficos de código aberto e não para a Nvidia, se estiver disponível

Espere, não é? Achei que a parte do Vinho (que é discutida aqui) sim. De qualquer forma, provavelmente seria bom tê-lo construído e enviado, mesmo que não seja usado por padrão.

Espere, não é? Achei que a parte do Vinho (que é discutida aqui) sim. De qualquer forma, provavelmente seria bom tê-lo construído e enviado, mesmo que não seja usado por padrão.

Ele detecta se galliumnine está presente ao iniciar o jogo e redireciona para a outra implementação, se necessário

@shanefagan A GPU habilitada para non gallium nine pode ser a minoria no futuro.
A Intel manifestou interesse em oferecer suporte ao Gallium 3d em todas as GPUs futuras.

@hungrymonkey Não acho que @shanefagan tenha afirmado algo contrário. Além disso, as GPUs nVidia com drivers proprietários ainda ocupam uma grande parte do uso do desktop Linux.

@nanonyme gallium nine não afeta nem o uso nem os drivers proprietários da nvidia. Ele verifica se o driver em uso é compatível com g9 e, caso não seja, não é usado. Especificamente, ele verifica se o mesa tem g9 habilitado e, em seguida, verifica qual driver mesa está em uso. Se nenhum driver mesa estiver em uso, ele literalmente não poderá usar a funcionalidade g9 e será completamente ignorado.

@GloriousEggroll , parece que não estamos falando no mesmo idioma. Isso foi explicado alguns posts acima.

Uma boa observação para o patch é que o desenvolvedor dele tem mantido os patches do WINE atualizados com o trabalho até 3 dias atrás. Eu diria que seria bom pelo menos construí-lo e ter a seleção como uma configuração para alguns sistemas que têm problemas de desempenho do dx3d9 (como eu com jogos como o SC2 sem modificações pesadas).

De qualquer forma, é bom vincular os patches, pois não vi nenhum link https://github.com/sarnex/wine-d3d9-patches

@Mushoz É o Unreal Tournament agora. Durante 2019 _pode_ estar totalmente funcional. Você tem o roteiro aqui .

Ignorar drivers e ferramentas nativos que já estão em uso e prontos para ir em favor da camada de transição que está sob intenso desenvolvimento não parece sensato. No mínimo, o Gallium Nine, que já está pronto, deve ser apresentado como uma opção para usuários de AMD; uma vez / se o VK9 chegar, ele ainda pode permanecer como uma opção.

Eu veria que a principal desvantagem são os vários codepaths, potencialmente tornando o suporte aos jogos mais difícil. Então, novamente, os resultados do teste mesmo agora não são aplicáveis ​​entre fornecedores de GPU

O VK9 não funciona em dispositivos não amdgpu / GPUs pré-GCN. O Gallium-Nine, por outro lado, poderia rodar no antigo r300g e até mesmo em GPUs como o meu VEGA10. Mas sim, essas velhas GPUs VLIW baseadas em r600g, nas quais alguns de meus amigos ainda dependem, são consideradas obsoletas.

Assim como o próprio D3D9.

Eu veria que a principal desvantagem são os vários codepaths, potencialmente tornando o suporte aos jogos mais difícil. Então, novamente, os resultados do teste mesmo agora não são aplicáveis ​​entre fornecedores de GPU

Bem, é um benefício se funcionar, insignificante se não funcionar. Como se você pudesse tornar o padrão ainda a implementação do WINE, mas permitir que os usuários a definam como uma variável de ambiente se quiserem experimentá-la. Eles já fazem isso se você obtiver melhor desempenho do próprio WINE em vez do DXVK, portanto, não é realmente um problema de ferramentas deles para configuração. Eles apenas precisam colocá-lo no lugar certo. Eles poderiam até contratar o cara que faz o patch para amarrar os últimos 10% para colocá-lo lá.

A diferença aqui é que a WineHQ não vende jogos e pode precisar fazer reembolsos

Eu pensei que é por isso que temos uma lista de permissões ...

A lista de permissões não funcionará se você tiver ramificações complicadas de modos operacionais, certamente

"Complicado"

A lista de permissões não funcionará se você tiver ramificações complicadas de modos operacionais, certamente

Bem, pode ser uma opção que só é habilitada pelos próprios usuários se eles quiserem experimentá-la se o desempenho do jogo não for bom

A lista de permissões não funcionará se você tiver ramificações complicadas de modos operacionais, certamente

Bem, pode ser uma opção que só é habilitada pelos próprios usuários se eles quiserem experimentá-la se o desempenho do jogo não for bom

Parece justo para mim.

Eu acho que você precisa colocar libd3dadapter9-mesa no runtime do Steam primeiro.

Eu acho que você precisa colocar libd3dadapter9-mesa no runtime do Steam primeiro.

Como funciona o libd3dadapter9? Eu sei que GalliumNine está em Mesa propriamente dita e os patches para WINE apontam para isso. Eu vi que está no Ubuntu a partir de 18.10, mas nunca usei essa lib.

Como funciona o libd3dadapter9? Eu sei que GalliumNine está em Mesa propriamente dita e os patches para WINE apontam para isso. Eu vi que está no Ubuntu a partir de 18.10, mas nunca usei essa lib.

Ele está apenas endereçando o rastreador de estado D3D9 da Mesa, assim como o opengl32.dll.so do Wine faz com rastreadores de estado OpenGL comuns, por exemplo¹.
Edit: Desculpe, confundi libd3dadapter9 com a DLL construída para o Wine. Não tomei café suficiente naquele dia. A biblioteca em questão implementa um rastreador de estado D3D9 para Mesa. Simplificado: oferece suporte nativo a D3D9 sem camadas de tradução adicionais como WineD3D ou VK9. Dê uma olhada nesta apresentação se estiver interessado .

¹: Aviso: a resposta pode ser imprecisa.

Consegui construir próton com nove patches enquanto o arch linux local é construído com --no-steam-runtime. O único jogo que testei até agora é Valkyria Chronicles 1 e que estava se comportando de forma estranha com esta compilação local, por exemplo, RX 480 foi detectado como R9 290 nas configurações, os controles não estavam funcionando corretamente às vezes e as configurações definidas pela ferramenta de configuração Valkyria Chronicles não foram salvo em tudo.

Embora esses problemas possam estar relacionados ao próton sendo construído com --no-steam-runtime ao invés dos nove patches.

O patch original de https://github.com/sarnex/wine-d3d9-patches/blob/wine-d3d9-3.16/wine-d3d9.patch precisava apenas de uma correção para o contexto em configure.ac consulte https: // gist .github.com / raetiacorvus / 8bf19a733ac131d744030788030941c4 apenas as linhas 72 e 73 foram removidas do patch original.

Você ainda precisa aplicar https://github.com/sarnex/wine-d3d9-patches/blob/wine-d3d9-3.16/d3d9-helper.patch primeiro e executar autoreconf na pasta de vinhos depois de aplicar ambos patches.

Além disso, eu tive que adicionar -with-d3d9-nine-module=/usr/lib32/d3d/d3dadapter9.so à configuração do wine32 no arquivo a seguir, mas isso pode ser o resultado de não configurar o ambiente de compilação corretamente? https://github.com/ValveSoftware/Proton/blob/83871c7bf93b785b23b987956b7cc3608d6998b3/build/makefile_base.mak#L713 -L726

Também não se esqueça de que você precisa habilitar o gálio nove através do winecfg para cada pfx.

https://github.com/ValveSoftware/Proton/issues/66#issuecomment -447569917

Esta é uma grande notícia! Apesar dos contratempos iniciais, ter uma construção um tanto funcional é um progresso significativo. Já que não sou muito versado em codificação, você pode explicar, por que você construiu com o argumento --no-steam-runtime ? O Proton que você construiu não funciona com o cliente Steam? Causa, todo o objetivo do Proton é rodar jogos Steam que requerem Steam DRM com cliente Steam nativo em vez da versão do Windows.

@raetiacorvus

Tenho uma coleção de jogos consideravelmente grande no Steam. Por favor, me avise, se você precisar testar mais jogos, para que eu possa tentar organizá-los.

O único jogo que testei até agora é Valkyria Chronicles 1 e que estava se comportando de forma estranha com esta compilação local, por exemplo, RX 480 foi detectado como R9 290 nas configurações

Este é um comportamento normal do Gálio Nove, meu RX 580 faz a mesma coisa nas minhas compilações de degustação de vinho.

Parece que nenhum dos problemas que encontrei está relacionado com o gálio nove, mas foi causado por --no-steam-runtime ou pelo próprio jogo.

@ rea987 --no-steam-runtime significa que o próton é construído com base nas bibliotecas locais, em vez dos patches do contêiner docker do steam runtime. Ainda é uma ferramenta de compatibilidade de vapor válida e pode ser usada como uma substituição de válvula de liberação de prótons fornecida. Um problema até agora é que falta o mapeamento do controlador corrigido do tempo de execução, resultando no problema que tive com Valkyria Chronicles. Você provavelmente poderia contornar isso usando algumas das ferramentas disponíveis para o wine para mapear os controladores corretamente.

@raetiacorvus Seria maravilhoso se você fornecesse um guia passo a passo de compilação de Gálio Nove para Prótons. Além disso, que tal fazer uma solicitação de pull para que talvez @ValveSoftware o mescle com um dos branches. Se essa for uma construção funcional, considerarei seriamente a mudança para a AMD. @raetiacorvus Minha oferta de fornecer mais jogos para teste ainda permanece.

Eu fiz meu próprio fork de Proton com os patches:

https://github.com/popsUlfr/Proton (verifique o branch proton_3.16_gallium_nine_extras e siga o readme)

git clone https://github.com/popsUlfr/Proton.git
cd Proton
git checkout proton_3.16_gallium_nine_extras
git submodule update --init

Ele também funciona com o tempo de execução do Steam, tive que adicionar este bloco ligeiramente feio de coisas mesa: https://github.com/popsUlfr/Proton/commit/0397af03059c32a6ac5e0213d39769e33f2914df

Eu adicionei uma variável de ambiente PROTON_USE_GALLIUM_NINE=1 que você pode usar para habilitar facilmente o Gallium nove se sua placa suportar (também pode ser habilitada por meio da guia de teste em winecfg)

Recursos :

• Gálio Nove obviamente
• Patch dx11 do Path of Exile: https://bugs.winehq.org/show_bug.cgi?id=42695
• Força wined3d11 se não houver suporte para Vulkan: # 1749
• Habilite o ffmpeg por padrão e construa o FAudio com ele: # 2082
• Alternar GLSL para desativar os shaders GLSL e usar shaders ARB em vez de reduzir a gagueira com wined3d

Aqui está uma versão para testar:
~ Proton_3.16-5_Gallium_Nine_Extras.tar.xz ~
~ Proton 3.16-5 Gálio Nove Extras 0.1.0 ~
~ Proton 3.16-5 Gálio Nove Extras 0.1.1 ~
~ Proton 3,16-6 Gálio Nove Extras 0,1.1 ~
~ Proton 3,16-6 Gálio Nove Extras 0,1,2 ~
Próton 3.16-6 Gálio Nove Extras 0.1.3

$ mkdir -p ~/.steam/root/compatibilitytools.d
$ tar xf Proton_3.16-6_Gallium_Nine_Extras_0.1.3.tar.xz -C ~/.steam/root/compatibilitytools.d

Em sua guia Steamplay, ele deve aparecer como Proton 3.16-6 Gallium Nine Extras

A propósito, eu adicionei isso ao README, após a etapa de configuração, você precisa executar make all dist vez de apenas make dist ou você acabará com o vinho win64 e nada mais. Portanto, isso parece ser um erro no README do próton oficial ou apenas agindo assim no meu próprio sistema, não tenho certeza.

Excelente trabalho @popsUlfr!

Você terá versões genéricas de 32 bits, 64 bits e / ou multiarch na página GitHub de seu fork?

Obrigado pelo esforço e bifurcação!

@ rea987 Gosta disso? https://github.com/popsUlfr/Proton/releases/tag/proton-3.16-5-gne-0.1.0

Diga-me se funciona bem para você, não tenho acesso a um cartão amd para testar isso completamente: /

Hrm, eu segui as instruções, mas parece que o Steam não está pegando o que quer que esteja no diretório criado. A lista suspensa da ferramenta de compatibilidade mostra apenas as versões "regulares" do Steam.

Alguma ideia do que posso estar fazendo de errado? Estou no KDE NEON 18.04 (basicamente Ubuntu), se isso muda alguma coisa?

@popsUlfr Precisamente! É uma forma mais clara e explicativa de distribuí-lo. Sim, também preciso de uma placa AMD para testá-la corretamente. : - /

@AndrewLoom A instalação do Steam está localizada no diretório ~/.local/share/Steam ou ~/.steam ? Porque eu precisava usar o último para fazer funcionar.

Obrigado rea987! D'Oh, tão óbvio agora, mas ainda não pensei nisso. :-)

@AndersDala Não tem problema, esse é um problema que confunde muitas pessoas recentemente. Talvez @popsUlfr possa editar o guia de instalação para apontar o diretório ~/.steam também?

Eu possuo um AMD Radeon Vega 56. Eu o instalei com sucesso e o selecionei para ser usado com todos os jogos do Windows, mas parece que jogos como A Hat in Time ou Dragon Age: Origins não funcionarão se eu habilitar Gallium Nine com PROTON_USE_GALLIUM_NINE = 1 (com prefixo limpo), uma janela nem mesmo aparece. Com PROTON_USE_GALLIUM_NINE = 0 eles funcionam bem.

Eu possuo um AMD Radeon Vega 56. Eu o instalei com sucesso e o selecionei para ser usado com todos os jogos do Windows, mas parece que jogos como A Hat in Time ou Dragon Age: Origins não funcionarão se eu habilitar Gallium Nine com PROTON_USE_GALLIUM_NINE = 1 (com prefixo limpo), uma janela nem mesmo aparece. Com PROTON_USE_GALLIUM_NINE = 0 eles funcionam bem.

Mesma GPU e mesmo resultado para mim. Os jogos (Dishonered, Dead Space) não começarão com Gallium.

@Mastergatto , @archfan Você instalou os drivers Mesa habilitados para Gallium Nine?

https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers

Sim, estou no Arch e instalei o mesa-git do AUR. Ele vem com Gallium Nine habilitado.

@archfan Tudo bem, amanhã, vou testá-lo em meu antigo laptop AMD que, espero, suporta Gallium Nine.

Sim, como Gallium Nine é habilitado por padrão com o pacote mesa, pelo menos para placas AMD no ArchLinux. Eu também tenho o gálio para o estágio do vinho, no qual o Gálio Nove funciona como planejado.

Você pode olhar para a saída quando é executado com gálio nove?
Portanto, nas opções de inicialização do jogo, adicione:

PROTON_DUMP_DEBUG_COMMANDS=1 PROTON_USE_GALLIUM_NINE=1 %command%

Execute o jogo.
Isso deixará alguns scripts de prótons em /tmp/proton_<username>
Lance ./run para ver a saída.

Também só para ter certeza, mude para outro próton, reinicie o vapor. Agora mude para o próton gálio nove.

EDITAR: para não poluir este tópico, acho melhor discuti-lo aqui: https://github.com/popsUlfr/Proton/issues/2

Também lamento se isso lhe deu esperanças e não funcionou fora da caixa. Eu mantive isso localmente, a parte do gálio nove era mais um 'e se' no caso de eu poder testar no amd. Decidi compartilhá-lo de qualquer maneira, vendo esta discussão se tornando mais proeminente e pode ser útil fazer algo sobre o suporte do gálio nove no próton :)
Os outros recursos incluídos também podem ser úteis para ...

Gallium Nine funciona em Proton com https://github.com/dhewg/nine

Sem surpresa, isso quebra a sobreposição do Steam, mas, por outro lado, funciona bem.

Gallium Nine funciona em Proton com https://github.com/dhewg/nine

Sem surpresa, isso quebra a sobreposição do Steam, mas, por outro lado, funciona bem.

ei legal!

você poderia fornecer um guia do que você fez? Estou um pouco perdida.

@tatsujb

https://github.com/popsUlfr/Proton/releases

Outro projeto a ser considerado como alternativa a este https://github.com/Joshua-Ashton/d9vk

aparentemente, deveríamos usar protontricks para obter todas essas guloseimas?

alguém sabe sobre isso?

aparentemente, deveríamos usar protontricks para obter todos aqueles googdies?

alguém sabe sobre isso?

Boa decisão. Eu honestamente prefiro uma solução sem protontricks, mas vou tentar isso o mais rápido possível.

Eu fiz isso :

wget https://raw.githubusercontent.com/Winetricks/winetricks/master/src/winetricks
chmod +x winetricks
wget https://raw.githubusercontent.com/Winetricks/winetricks/master/src/winetricks.bash-completion
sudo mv winetricks /usr/bin
sudo mv winetricks.bash-completion /usr/share/bash-completion/completions/winetricks
python3 -m pip install --user pipx
~/.local/bin/pipx ensurepath
eval "$(cat .bashrc | tail -n +10)"
pipx install protontricks
pipx upgrade protontricks
protontricks 9420 galliumnine

mas agora o jogo (que estava funcionando) me mostra uma caixa de erro dizendo: "Falha ao criar dispositivo direct3d"

@tatsujb Não acho que seja a página correta para isso, mas aqui vai. Você está usando Ubuntu 18.04 ou Mint 19? Porque os drivers Mesa do oibaf para essas versões do Ubuntu / Mint estão quebrados para o Gallium Nine desde dezembro / janeiro. Tive o mesmo problema, mudei para o Ubuntu Mate 19.04 e agora funciona.

@ rea987 Estou usando o ubuntu 19.04, vou tentar novamente. EDIT nah isso não ajuda. o que mais você fez? quais argumentos de execução você tem e qual jogo está funcionando para você?

@tatsujb Honestamente, não muito.

• Evitei Mesa PPAs de terceiros, pois a compatibilidade dos drivers Mesa da
• Verifiquei se libd3dadapter9-mesa e libd3dadapter9- mesa: i386 estão instalados.
• / Usr / bin / winetricks substituído manualmente pela versão mais recente: https://wiki.winehq.org/Winetricks
• Apagado ~ / .cache / winetricks
• Gallium Nine Standalone reinstalado (mais recente) via Protontricks.

@ rea987

• / Usr / bin / winetricks substituído manualmente pela versão mais recente: https://wiki.winehq.org/Winetricks

sim, esse era o truque. Eu descobri desde então, obrigado!

seria bom ter galliumnine e d9vk btw. Eu os comparei no chapéu a tempo hoje e o galliumnine funciona muito melhor (20% ou mais fps mais alto) e não gagueja na primeira vez que você visita uma nova área. ter ambos resultaria em maiores chances de rodar um determinado jogo Directx9 com bom desempenho, pois alguns títulos podem quebrar com um ou outro.

Em um mundo ideal, o renderizador poderia retroceder graciosamente de nativo para vulkan para opengl (ou alternar a prioridade dos dois primeiros se d9vk eventualmente tivesse alguma vantagem intrínseca, mas ainda assim).
Em vez disso, a Valve (e até mesmo os codeweavers, dados todo o escárnio em torno de Nine) parece focada em apenas criar um belo jardim "bem o suficiente" para os cartões mais recentes, em vez de ter tudo e a pia da cozinha funcionando. Eles nem mesmo adicionarão a verificação automática de cartas que não têm vulkan

Aqui estão meus 20 centavos:

Agora que temos o Gallium Nine autônomo, é muito fácil de usar porque você não precisa mais de adesivos para vinho. Tudo o que você precisa fazer é: (1) instalar mesa-libd3d9 a partir do gerenciador de pacotes da sua distro (2) instalar o Nine no prefixo wine usando winetricks ou o script do instalador.

Com relação a qual é a opção "melhor": Não pretendo iniciar uma guerra de insultos aqui, então vou apenas compartilhar o que descobri até agora: https://github.com/Joshua-Ashton/d9vk/issues/ 95 # issuecomment -492651741 - isso, claro, apenas significa que no meu sistema Nine foi mais rápido com os títulos que experimentei até agora, o que pode não ser representativo de como funcionariam nos computadores de outras pessoas. EDIT: Eu percebo que o Nine não é atualmente uma opção para usuários NVidia, mas funciona razoavelmente bem com AMD (radeonsi) e Intel (iris), e irá melhorar em NVidia assim que o zink se tornar maduro o suficiente.

Nove autônomo é uma moleza de usar, de fato, com certeza.
De alguma forma, * toda vez * que você aponta isso para os desenvolvedores, parece que não dá para ouvir.
Não sei se as discussões não poderiam ter acontecido atrás de portas / IRC e também não quero entrar em conflito - mas não sei mais o que dizer para que reconheçam o * presente * estado de coisas do maldito código, em vez de qualquer imagem caricatural que eles tenham em suas mentes sobre como era o projeto há meia década.

Sei que o Nine não é atualmente uma opção para usuários da NVidia, mas funciona razoavelmente bem com AMD (radeonsi) e Intel (iris), e irá melhorar a NVidia assim que o zink se tornar maduro o suficiente.

Ele também funciona bem no r600g. GPUs suportadas por r600g não têm suporte Vulkan btw.

na nvidia por enquanto eu alterno entre um ubuntu com 418 instalado e um ubuntu com Nouveau instalado para que eu possa habilitar o mesa e o gallium nine. o desempenho com jogos linux nativos que podem rodar sob nouveau é aceitável e os jogos wine-gallium-nine rodam muito bem.

Mas obviamente não posso esperar que a mesa dê suporte à Nvidia também.

Acho que isso está resolvido pelo D9VK agora. Eu testei com o SC2 e alguns outros jogos e funciona muito bem. Esperançosamente, isso será integrado ao DXVK no futuro e os patches enviados para o Proton também.

O d9vk ainda tem um desempenho muito pior do que o gálio nove, mas sim, mesmo apenas o suporte d9vk integrado seria incrível, pois já é mais difícil do que o gálio nove para integrar em uma instalação de próton existente

também outra parte complicada do envio do d9vk é que ele requer o mesa mais recente. não apenas a versão mais recente, é baseado no mesa-git. então, para torná-lo acessível a uma ampla variedade de distros, você pode até ter que enviar o mesa-git com ele ou instruir os usuários a descobrir como obter o mesa-git para sua distro

@shanefagan Não, d9vk é muito, muito mais lento do que nove, veja minhas descobertas em meu post anterior.

Existe uma versão autônoma que é fácil de instalar. Talvez eles possam ser enviados com o Proton e ativados com um argumento. O D9VK é ótimo, mas, como outros disseram, é mais lento e costuma usar drivers de última geração. Instalar o Gallium através de winetricks funciona, mas ter uma opção integrada seria muito bom.

Independente: https://github.com/iXit/wine-nine-standalone

Olá! ~ Alguém mais experimentou travamentos silenciosos em 4.11-6 ao lançar jogos com Gallium Nine Standalone instalado?

@Bryophyllum mesmo, o jogo não iniciará após a instalação de galliumnine via protontricks.
A pior parte é que não há maneira fácil de saber se a gáliumnina está funcionando.

Na verdade, depois de algumas tentativas e erros, funcionou:

Você pode olhar para a saída quando é executado com gálio nove?
Portanto, nas opções de inicialização do jogo, adicione:

PROTON_DUMP_DEBUG_COMMANDS=1 PROTON_USE_GALLIUM_NINE=1 %command%

Execute o jogo.
Isso deixará alguns scripts de prótons em /tmp/proton_<username>
Lance ./run para ver a saída.

Também só para ter certeza, mude para outro próton, reinicie o vapor. Agora mude para o próton gálio nove.

EDITAR: para não poluir este tópico, acho que seria melhor discuti-lo aqui: popsUlfr # 2

Também lamento se isso lhe deu esperanças e não funcionou fora da caixa. Eu mantive isso localmente, a parte do gálio nove era mais um 'e se' no caso de eu poder testar no amd. Decidi compartilhá-lo de qualquer maneira, vendo esta discussão se tornando mais proeminente e pode ser útil fazer algo sobre o suporte do gálio nove no próton :)
Os outros recursos incluídos também podem ser úteis para ...

Se eu iniciar a partir do Steam, ele exibe "Instalando drivers" ou algo parecido e desativa o galliumnine antes de iniciar o jogo.
No entanto, iniciar o jogo por meio de scripts despejados não desativa o galliumnine e o jogo é iniciado com ele.

@tuxutku Alguns dos jogos que experimentei com Gallium Nine Standalone no Proton 4.11

A pior parte é que não há maneira fácil de saber se a gáliumnina está funcionando.

Não exatamente. Se você executar o Steam Client a partir da CLI, verá uma mensagem do Gallium Nine em verde ou vermelho quando o jogo iniciar; entretanto, neste caso, nada é gerado.

Com PROTON_LOG=1 recebo este erro quando tento executar GTA SA:

10264.098:0031:0032:err:module:import_dll Library d3d9.dll (which is needed by L"Z:\\var\\home\\user\\.local\\share\\Steam\\steamapps\\common\\Grand Theft Auto San Andreas\\gta-sa.exe") not found

Não sei o que causa isso, nem como faço para corrigi-lo, mas, felizmente, alguém pode descobrir a raiz desse problema juntando todas as pistas.

Vou abrir um novo problema sobre o cliente Steam desabilitando o galliumnine antes do lançamento do jogo, estou tendo esse problema em outro jogo

Olá @tuxutku , esta solicitação de recurso é o lugar certo para discutir o novo comportamento. Parece que a mudança aconteceu ao mesmo tempo que o d9vk foi adicionado ao Proton e pode ser um efeito colateral do Proton gerenciando isso.

A pior parte é que não há maneira fácil de saber se a gáliumnina está funcionando.

Não exatamente. Se você executar o Steam Client a partir da CLI, verá uma mensagem do Gallium Nine em verde ou vermelho quando o jogo iniciar; entretanto, neste caso, nada é gerado.

Com PROTON_LOG=1 recebo este erro quando tento executar GTA SA:

10264.098:0031:0032:err:module:import_dll Library d3d9.dll (which is needed by L"Z:\\var\\home\\user\\.local\\share\\Steam\\steamapps\\common\\Grand Theft Auto San Andreas\\gta-sa.exe") not found

@Bryophyllum não é tão fácil quanto ver se Native Direct3D 9 v0.5.0.356-release is active. For more information visit https://github.com/iXit/wine-nine-standalone foi postado.
Por exemplo, ao lançar o jogo tomb raider 2013 a partir do comando ./run despejado, ele posta a linha porque o inicializador usa directx9, mas não o jogo. Tive que ajustar um registro com regedit para jogar o jogo com galliumnine

Jogos com VAC costumavam funcionar com afaik de vinho. mas agora não o fazem por algum motivo. CSGO reclama sobre assinaturas de arquivo não coincidentes. TF2 não dá nenhuma razão específica.

Por alguma razão, PROTON_DUMP_DEBUG_COMMANDS=1 não funcionou no Team Fortress 2 e eu tive que copiar e modificar um script de outro jogo.

#!/bin/bash
#Run game or given command in environment

cd "/home/utku/took/happytosharemysteamapps/steamapps/common/Team Fortress 2"
DEF_CMD=("/home/utku/took/happytosharemysteamapps/steamapps/common/Team Fortress 2/hl2.exe" "-steam" "-dev" "-secure" "-game" "tf" "-w" "1366" "-h" "768")
PATH="/home/utku2/.local/share/Steam/compatibilitytools.d/Proton-4.15-GE-4/dist/bin/:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/bin:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/bin:/home/utku3/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/utku3/.local/bin" \
    TERM="xterm" \
    WINEDEBUG="-all" \
    WINEDLLPATH="/home/utku2/.local/share/Steam/compatibilitytools.d/Proton-4.15-GE-4/dist/lib64//wine:/home/utku2/.local/share/Steam/compatibilitytools.d/Proton-4.15-GE-4/dist/lib//wine" \
    LD_LIBRARY_PATH="/home/utku2/.local/share/Steam/compatibilitytools.d/Proton-4.15-GE-4/dist/lib64/:/home/utku2/.local/share/Steam/compatibilitytools.d/Proton-4.15-GE-4/dist/lib/:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/pinned_libs_32:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/pinned_libs_64:/usr/lib/x86_64-linux-gnu/libfakeroot:/lib/i386-linux-gnu:/usr/local/lib:/usr/local/lib/libstrangle/lib32:/usr/local/lib/libstrangle/lib64:/lib/x86_64-linux-gnu:/lib32:/libx32:/lib:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib:" \
    WINEPREFIX="/home/utku/took/happytosharemysteamapps/steamapps/compatdata/440/pfx/" \
    WINEESYNC="1" \
    SteamGameId="440" \
    SteamAppId="440" \
    WINEDLLOVERRIDES="steam.exe=b;mfplay=n;d3d11=n;d3d10=n;d3d10core=n;d3d10_1=n;dxgi=n;d3d9=n" \
    STEAM_COMPAT_CLIENT_INSTALL_PATH="/home/utku2/.local/share/Steam" \
    "/home/utku2/.local/share/Steam/compatibilitytools.d/Proton-4.15-GE-4/dist/bin/wine" steam.exe "${@:-${DEF_CMD[@]}}"

Saída TF2

saída csgo

Também aqui está o script gerado automaticamente por PROTON_DUMP_DEBUG_COMMANDS=1 :

#!/bin/bash
#Run game or given command in environment

cd "/mnt/WD-green/common/Counter-Strike Global Offensive"
DEF_CMD=("/mnt/WD-green/common/Counter-Strike Global Offensive/csgo.exe" "-steam")
PATH="/home/utku2/.local/share/Steam/compatibilitytools.d/Proton-4.15-GE-4/dist/bin/:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/bin:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/bin:/home/utku3/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/utku3/.local/bin" \
    TERM="xterm" \
    WINEDEBUG="-all" \
    WINEDLLPATH="/home/utku2/.local/share/Steam/compatibilitytools.d/Proton-4.15-GE-4/dist/lib64//wine:/home/utku2/.local/share/Steam/compatibilitytools.d/Proton-4.15-GE-4/dist/lib//wine" \
    LD_LIBRARY_PATH="/home/utku2/.local/share/Steam/compatibilitytools.d/Proton-4.15-GE-4/dist/lib64/:/home/utku2/.local/share/Steam/compatibilitytools.d/Proton-4.15-GE-4/dist/lib/:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/pinned_libs_32:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/pinned_libs_64:/usr/lib/x86_64-linux-gnu/libfakeroot:/lib/i386-linux-gnu:/usr/local/lib:/usr/local/lib/libstrangle/lib32:/usr/local/lib/libstrangle/lib64:/lib/x86_64-linux-gnu:/lib32:/libx32:/lib:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu:/home/utku2/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib:" \
    WINEPREFIX="/home/utku/took/happytosharemysteamapps/steamapps/compatdata/730/pfx/" \
    WINEESYNC="1" \
    SteamGameId="730" \
    SteamAppId="730" \
    WINEDLLOVERRIDES="steam.exe=b;mfplay=n;d3d11=n;d3d10=n;d3d10core=n;d3d10_1=n;dxgi=n;d3d9=n" \
    STEAM_COMPAT_CLIENT_INSTALL_PATH="/home/utku2/.local/share/Steam" \
    "/home/utku2/.local/share/Steam/compatibilitytools.d/Proton-4.15-GE-4/dist/bin/wine" steam.exe "${@:-${DEF_CMD[@]}}"

Eu não tentei csgo, mas tf2 funciona e não tem problema de vac sob o Wine Steam

@tuxutku por que você está testando jogos que possuem portas nativas do Linux?

@tuxutku
O que isso tem a ver com o Gálio 9?

Eu estava perguntando porque estou genuinamente curioso. saia dos votos negativos

@tuxutku por que você está testando jogos que possuem portas nativas do Linux?

porque os jogos da fonte 1 não funcionam bem o suficiente no linux?
Eles se saíram pior com a gálio-nina, mas isso não significa que os portos nativos estejam indo bem. Eles se saem muito mal em comparação com as contrapartes do Windows.
Os novos mapas de zona de perigo do CS: GO são totalmente impossíveis de jogar (~ 15fps) em amd a10-9620p + rx 540.
Quando há muita geometria no cenário, a taxa de quadros cai fortemente em todos os jogos da fonte 1 que testei até agora (nuclear dawn, cs: go, tf2, half-life 2, half-life 2 team death match).
left4dead2 é uma exceção e, na verdade, utiliza gpu bem o suficiente

a suposição é "o código é ruim" em vez de "as chamadas estão sendo interpretadas por meio de GL ao invés de vulkan", certo?

Se você tiver um jogo nativo vulkan funcional, os resultados não seriam melhores 100% do tempo em nativo?

Dado que isso está disponível externamente a partir do próton com truques de prótons, eu diria que essa solicitação de recurso está bastante substituída.

Se ser corrigível manualmente encerrasse o dia, poderíamos encerrar metade dos problemas aqui.

Dado que isso está disponível externamente a partir do próton com truques de prótons, eu diria que essa solicitação de recurso está bastante substituída.

O próprio Steam sempre desativa o galliumnine ao iniciar o jogo ou confirmar o cache. Além disso, não há sinalizador de prótons para ativá-lo e requer atualizações manuais.

Eu descobri que galliumnine muitas vezes não é apenas mais rápido do que a tradução padrão do wined3d (em r600), mas parece corrigir problemas com tela cheia para muitos jogos (comandante supremo FA, por exemplo). Adicioná-lo ao próton parece que seria muito fácil dada a versão autônoma, eu não diria que deveria ser uma opção "suportada", mas seria bom tê-la integrada como uma solução alternativa / aprimoramento.

eu acredito que isso é suportado desde próton 5

EDIT: nvm estou pensando em d9vk

eu acredito que isso é suportado desde próton 5

EDIT: nvm estou pensando em d9vk

Sim ... d9vk não funciona com R600, infelizmente. : /

Este é um problema que deve ser considerado, devemos ser capazes de habilitar o gálio nove sem recorrer a hacks (como protontricks) apenas por variáveis ​​de ambiente.

É fácil de consertar (vocês já têm muitos garfos e soluções alternativas para consertar isso), o Gallium Nine agora tem melhor suporte a GPU (agora funciona com os drivers mais recentes da Intel) e oferece aumento de desempenho de 1,5-2x sobre DXVK e wined3d.

E você já tem vários relatórios de jogos falando sobre compatibilidade aprimorada apenas com o uso do Gallium Nine.

https://github.com/ValveSoftware/Proton/issues/173#issuecomment -499869941
https://github.com/ValveSoftware/Proton/issues/255#issuecomment -415997284
https://github.com/ValveSoftware/Proton/issues/355#issuecomment -415972910
https://github.com/ValveSoftware/Proton/issues/554#issue -354016973
https://github.com/ValveSoftware/Proton/issues/770#issue -354455950
https://github.com/ValveSoftware/Proton/issues/1073#issuecomment -473703760
https://github.com/ValveSoftware/Proton/issues/2704#issuecomment -518029014

Eu sei que isso provavelmente não é uma prioridade para você, já que isso se aplica apenas a jogos antigos, mas vamos lá, há um enorme catálogo de ótimos jogos que irão se beneficiar do Gallium Nine.

Alguma atualização neste tópico? @popsUlfr infelizmente parou de fornecer compilações Proton novas com suporte nativo D3D9 há mais de um ano.

Alguma atualização neste tópico? @popsUlfr infelizmente parou de fornecer compilações Proton novas com suporte nativo D3D9 há mais de um ano.

Tenho usado próton normal + gálio nove autônomo. Tenho vindo a instalá-lo com winetricks e desativar DXVK

Tenho usado próton normal + gálio nove autônomo. Tenho vindo a instalá-lo com winetricks e desativar DXVK

Bom saber! Qual versão do Proton você usou e como desabilitou o DXVK? WineD3D estava interferindo na última vez que tentei isso.

@ crt0mega galliumnine ("d3d9") será sempre substituído por dxvk ou wined3d

Proton-5.9-GE-8-ST/proton:
            if "wined3d" in g_session.compat_config:
                dxvkfiles = ["dxvk_config"]
                wined3dfiles = ["d3d11", "d3d10", "d3d10core", "d3d10_1", "d3d9"]
            else:
                dxvkfiles = ["dxvk_config", "d3d11", "d3d10", "d3d10core", "d3d10_1", "d3d9"]
                wined3dfiles = []

deve ser consertado ...

ou podemos usar Proton-5.9-GE-8-ST / dist / bin / wine sem próton (e sem jogos do Steam)
ps: setup galliumnine:
WINE = "./ Proton-5.9-GE-8-ST / dist / bin / wine" WINEPREFIX = ~ / .steam / steam / steamapps / compatdata / 372000 / pfx / ./Proton-5.9-GE-8-ST/ protonfixes / winetricks --forçar galliumnine