Proton: [Demande de fonctionnalité] : Gallium neuf patchs

C'est une bien meilleure option. Et j'ai entendu dire qu'il allait fusionner avec DXVK (éventuellement) donc nous aurons toutes les versions D3D couvertes de 9 à 12. Les plus anciennes n'ont de toute façon pas besoin des fonctionnalités de Vulkan, je pense que les jeux D3D 8 pourraient même être exécutés sur un moteur de rendu logiciel en 60 FPS sur du matériel moderne.

Très intéressant! Où avez-vous trouvé qu'il allait être fusionné avec DXVK ?

Je n'ai rien trouvé à ce sujet donc je me trompe peut-être. Il ne sera probablement pas fusionné directement dans DXVK, mais plutôt pris en charge avec lui ou fusionné dans Wine. Je me souviens vaguement de ces deux projets évoqués dans le même contexte (ce qui n'est pas surprenant) de remplacement de la traduction D3D=>OGL ou quelque chose comme ça. Quoi qu'il en soit, je pense que les frais généraux de Vulkan sont négligeables par rapport à l'approche directe Gallium Nine, mais les avantages sont évidents - tous les joueurs peuvent l'utiliser, pas seulement ceux qui ont des pilotes FOSS. Et il peut être poussé encore plus loin, vers Windows lui-même, afin que les utilisateurs de Windows puissent exécuter des jeux avec éventuellement de meilleures performances en raison d'une meilleure utilisation du processeur ou les exécuter du tout car certains jeux plus anciens ne fonctionnent plus sur Windows moderne mais fonctionnent sur Wine.

Je suis d'accord que VK9 ou quelque chose de similaire serait la meilleure solution/implémentation. Cependant, pour autant que je sache, la version actuelle de VK9 est toujours une preuve de concept et prend en charge très peu, voire pas du tout, de jeux. Il ne peut rendre que quelques tests directx9 simples.

Les correctifs Gallium Nine sont prêts, bien testés par de nombreux joueurs et offrent des performances (presque) natives. L'implémenter serait plutôt trivial, puisque les correctifs sont déjà là. Ce serait un ajout très bienvenu pour tous les joueurs AMD/Intel pour le moment, jusqu'à ce que VK9 atteigne sa maturité.

VK9 est à des années de son achèvement, et je pense que même les frais généraux de d3d-pba pourraient être considérés comme "négligeables".
Le cas échéant, j'aimerais que le proton (mais même le vin en amont) ait certaines sortes de priorités.
Dites, d'abord natif (gallium) ou vulkan (dxvk), puis l'autre, last but not least wined3d (car tous les GPU ne prennent pas en charge vulkan)

ps Nine ne fonctionne pas pour les utilisateurs d'Intel

Comme il y a encore des centaines de jeux Direct3D 9 en cours de lecture sur Steam et que Gallium Nine s'est avéré bien plus efficace que d3d9 Wine traditionnel, cela devrait être une fonctionnalité optionnelle au moins via user_setting.py.

je préférerais que les vannes fusionnent VK9 avec DXVK. ils ont donc une couverture vulkan uniforme.

Bien sûr, dans un monde idéal. Mais VK9 n'exécute pas un seul jeu jusqu'à présent et n'en est qu'à la phase de validation du concept. Il peut exécuter des tests dx9 simples et c'est tout. De plus, le gars qui y travaille le considère comme un projet de passe-temps et ne fait pas autant de travail que le gars qui développe DXVK. Cela pourrait prendre des années avant que le VK9 soit prêt à être utilisé. En attendant, pourquoi ne pas utiliser des correctifs pour les utilisateurs d'AMD qui sont bien testés et complètement finis ?

Je suis d'accord que les correctifs Gallium 9 devraient être utilisables par les utilisateurs d'AMD mesa. Cela fait partie de mesa, nous avons juste besoin de la version wine pour permettre son utilisation.

D'accord. Et qui sait? Peut-être que dans un futur proche il n'y a pas que radeonsi et nuveau qui en profitent ?
https://www.phoronix.com/scan.php?page=news_item&px=Intel-Iris-Gallium

J'ai eu beaucoup de succès avec cela moi-même et les correctifs sont bien entretenus. Les packages Mesa sont construits sur openSUSE et fonctionnent tous ensemble. Va généralement de jouable avec beaucoup de bégaiement à soyeux tandis que d'autres jeux n'obtiennent qu'un écran noir. Devrait être basculable ou deux versions de wine ou quelque chose comme ça avec les valeurs par défaut fournies pour les jeux pris en charge.

Gallium Nine a été tout simplement fantastique dans mon expérience. Ce serait formidable de le voir inclus dans Proton.

Personnellement, je vote pour l'approche tout Vulkan.

@ shoober420 Je préférerais ça aussi éventuellement. Mais une couche de traduction de travail dx9 vers vulkan est dans une année avant d'être achevée, voire jamais. Pourquoi ne pas laisser les utilisateurs d'AMD profiter des performances natives du dx9 via des correctifs Gallium Nine bien testés et entièrement finis ? Ils n'ont besoin d'être fusionnés que pour que les utilisateurs d'AMD puissent profiter des performances natives dès maintenant.

@ shoober420 Je pense que nous préférons tous cette route pour le proton. C'est le pas en avant logique. Nous ne demandons pas à Valve de renoncer à une implémentation vulkan de d3d9. Nous demandons qu'ils autorisent les utilisateurs des pilotes ouverts à base de gallium à utiliser ce qu'ils ont déjà. Gallium 9 fait déjà partie de notre pile de pilotes. Les « neuf patches Gallium » pour wine ignorent simplement la traduction par défaut de l'api d3d9 vers opengl et alimentent à la place les appels api directement vers le gpu. Éviter les pertes de performances dues à la traduction de l'API.

@Mushoz @Xalphenos

Je vois que vos gars pointent, vous avez tous les deux raison. Je ne savais pas que VK9 était si loin. Je soutiens alors le choix pour plus d'options. J'utiliserai peut-être un AMD ou un Intel un jour.

J'ai fait le travail pour construire toutes les variations de vin, mise en scène et neuf pour openSUSE. Fondamentalement, il suffit d'appliquer le jeu de correctifs approprié à partir de https://github.com/sarnex/wine-d3d9-patches et de créer comme d'habitude. Nous devons donc compiler wine deux fois et fournir une option à un binaire spécifique.

Pour référence, le package openSUSE/wine qui construit les quatre saveurs de vin.

• vin
• vin neuf
• mise en scène
• vin-stade-neuf

Je ne sais pas quelle est la situation dans le proton relatif à la mise en scène du vin. Si personne d'autre n'y parvient et que Valve ne s'y oppose pas, je peux donner un coup de couteau, mais Steam aurait besoin d'une option d'interface utilisateur pour vraiment ajouter le vernis.

Ce à quoi vous pensez est #22. Il existe peut-être un mécanisme pour ajouter son propre runtime, mais il est inconnu pour le moment.

Mais pour moi, le vin et le proton ne devraient avoir qu'un gracieux mécanisme de repli. De vulkan à gallium, à opengl.. Selon la solution de secours la plus fonctionnelle que vous pourriez utiliser sur votre système.

Connexe certes, mais cette requête devra toujours être facultative pour la même raison que wine en amont ne la fusionne pas... cela ne fonctionne pas sur toutes les plateformes et uniquement avec un sous-ensemble de cartes pouvant utiliser les pilotes Mesa associés. Ceci est assez différent des autres modifications apportées à wine dans ce repo (à part l'exclusion des anciennes cartes). #22 permettrait à quelqu'un avec un wine-nine construit de le changer, mais ce problème consiste à le faire faire partie de la construction officielle.

Oui .. et je ne vois pas ce qui est difficile de vérifier quel pilote est utilisé, sur quel matériel, et de l'appeler un jour (même chose pour vulkan ou opengl de toute façon)

Moi non plus, je n'ai jamais dit que non. Je réponds juste au n°22 qui concerne spécifiquement le choix de constructions personnalisées en dehors du proton, ce qui n'est pas ce que je propose ni ce problème.

Étant donné la nature étendue de la différence entre ValveSoftware/wine (3.7) vs wine/wine (3.7) et l'approche adoptée par Valve, il est probablement plus logique de la fusionner directement dans leur fourchette de vin. Il devrait alors soit a) être basculable au moment de l'exécution (éventuellement automatiquement) soit être construit deux fois (je pense que les correctifs incluent déjà une bascule au moment de la compilation).

Les correctifs de l'étiquette 3.7 ne s'appliquent pas proprement à ValveSoftware/wine.

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

C'est peut-être simple, mais j'imagine que ce serait un problème persistant qui serait probablement une autre raison de fusionner directement avec ce fork.

Ils vont le mettre à jour dès qu'ils géreront les "problèmes de lancement"

... d'ailleurs, ce serait peut-être plus productif si vous travailliez d'abord pour obtenir cela dans la mise en scène

La mise à jour de la version de wine n'était pas ce que j'avais demandé ou dont j'avais besoin car j'ai appliqué des correctifs pour la 3.7. Quant à la mise en scène, il s'agit d'une demande à long terme qui n'intéresse pas wine en amont, principalement parce qu'il ne fonctionne pas sur Mac et pas sur tout le matériel Linux. Par conséquent, le proton intègre une variété d'améliorations de performances qui limitent la portée du matériel… cela pourrait donc les intéresser.

L'avoir dans la mise en scène du vin ou dans le vin proprement dit serait formidable, mais vous pouvez trouver de nombreux problèmes antérieurs indiquant que cela ne se produira pas de notre vivant.

Mac n'est pas un problème, ni la compatibilité matérielle (_surtout_ après les dernières rumeurs d'Intel).
Vous pouvez voir mes liens pour savoir pourquoi le problème réel le plus préoccupant, du moins pour le moment, est simplement le manque de reconnaissance en premier lieu.
(pour autant, qui sait, peut-être qu'ils parviennent déjà à un consensus sur IRC)

Même si VK9 serait prêt pour Proton, je préférerais la solution la plus efficace. Jusqu'à ce que Proton propose cela, je continue de m'en tenir à mon vieux vin de confiance à neuf patchs pour les jeux dépendant de d3d9.

Je suis pleinement conscient que Gallium Nine ne sera pas (et ne sera probablement jamais) la solution la plus efficace pour tout le monde , mais ce n'est pas mon propos ici. L'avoir en option pour ceux qui utilisent un pilote Gallium serait génial ! :)

Voici la solution :
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

Fondamentalement, Gallium3D a toujours été une fine abstraction entre divers trackers d'état et les pilotes, donc il suffit de mettre le chausse-pied dans Vulkan en tant que pilote et bam, vous obtenez tous les trackers d'état pris en charge, y compris Gallium neuf et OpenGL de Mesa. Le cycle de vie du bytecode du shader sera le bytecode DX9 HLSL du jeu->TGSI->NIR->SPIRV wow, si cela fonctionne, cela fonctionne.... :)

La seule chose à laquelle je peux voir que c'est une "solution" est un palliatif temporaire pour les cartes Nvidia avant que VK9 ne soit prêt. Ce ne serait certainement pas plus rapide sur AMD.

@ jerbear64 Gallium Nine est déjà assez testé au combat d'après ce que je vois, du moins sur le pilote amdgpu. Je pensais souvent que cela aurait pu être fait dès le début, même avec le cas de DXVK, cela aurait pu être aussi un tracker d'état à l'intérieur de Mesa, puis écrire quelque chose comme ZINK à la fin pour les pilotes fermés ou utiliser directement le matériel natif lorsque c'est possible. Je ne me plains pas pour autant... :)

Tout le monde n'utilise pas mesa.

Le mercredi 26 septembre 2018, à 20 h 35, Alex Fuller, [email protected] a écrit :

@jerbear64 https://github.com/jerbear64 Gallium Nine est déjà assez
testé au combat d'après ce que je vois, du moins sur le pilote amdgpu. j'étais
pensant souvent que cela aurait pu être fait depuis le début même avec les DXVK
au cas où cela aurait pu être aussi un traqueur d'état à l'intérieur de Mesa, puis
écrivez simplement quelque chose comme ZINK à la fin pour les pilotes fermés ou utilisez le
matériel natif directement lorsque cela est possible. Je ne me plains pas pour autant... :)

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/ValveSoftware/Proton/issues/66#issuecomment-424824077 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAipRw-R-g3DJOiWzHdR5SOHBu2X-xCxks5ue8jigaJpZM4WHXpZ
.

@cjwijtmans bien avec cela, tout le monde peut avoir un pilote vulkan existant, ce serait juste une bibliothèque à lier comme DXVK ...

Voici une autre façon de procéder :

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

dgVoodoo implémente déjà direct3d 1 à 7 plus 8.1 à 11 entre autres, de sorte que la réimplémentation du projet de direct3d9 dans direct3d 11 permettrait à toutes les anciennes versions de direct3d de fonctionner simplement via DXVK.

@ jerbear64 qui sonne à l'envers. Neuf est inutile sur nVidia propriétaire uniquement. Avec AMD, vous utilisez principalement Mesa. Intel construit également un nouveau pilote Gallium3D, ce sera donc une solution Intel+nouveau+AMD dans le futur.

Il semble que dgVoodoo fonctionne sur le support D3D9 :

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

Il est limité au modèle de shader 1.x. Cela signifie que les jeux qui utilisent D3D9 avec le modèle de shader 1.x pourraient être exécutés sur DXVK avec sa prochaine version. L'inconvénient est que dgVoodoo n'est pas open source.

Pour ce que ça vaut, nous avons maintenant pris en charge la partie Mesa de Gallium Nine maintenant dans Steam Flatpak en raison de la demande d'autres applications Flatpak

@ jerbear64 qui sonne à l'envers. Neuf est inutile sur nVidia propriétaire uniquement. Avec AMD, vous utilisez principalement Mesa. Intel construit également un nouveau pilote Gallium3D, ce sera donc une solution Intel+nouveau+AMD dans le futur.

Eh bien, c'est inutile pour les utilisateurs de Nvidia, mais cela ne rompt pas la compatibilité avec lui. C'est bien de donner quelque chose aux utilisateurs de graphiques open source et non à Nvidia s'il est disponible

Attends, non ? Je pensais que la partie Wine (qui est discutée ici) l'a fait. Quoi qu'il en soit, ce serait probablement bien de le faire construire et de l'expédier même s'il n'est pas utilisé par défaut.

Attends, non ? Je pensais que la partie Wine (qui est discutée ici) l'a fait. Quoi qu'il en soit, ce serait probablement bien de le faire construire et de l'expédier même s'il n'est pas utilisé par défaut.

Il détecte si la galliumnine est présente au démarrage du jeu et redirige vers l'autre implémentation si nécessaire

@shanefagan Le compatible avec le gallium neuf pourrait être la minorité à l'avenir.
Intel a exprimé son intérêt à prendre en charge Gallium 3d sur tous les futurs GPU.

@hungrymonkey Je ne pense pas que @shanefagan ait prétendu quoi que ce soit de contraire. De plus, les GPU nVidia avec des pilotes propriétaires occupent toujours une part massive de l'utilisation des ordinateurs de bureau Linux.

@nanonyme gallium neuf n'affecte pas du tout les pilotes propriétaires nvidia ni l'utilisation. Il vérifie si le pilote utilisé est capable de g9, et sinon, il n'est pas utilisé. Plus précisément, il vérifie si mesa a activé g9, puis vérifie quel pilote mesa est utilisé. Si aucun pilote mesa n'est utilisé, il ne peut littéralement pas utiliser la fonctionnalité g9 et est complètement ignoré.

@GloriousEggroll, il semble que nous ne

Une bonne note pour le correctif est que son développeur a maintenu les correctifs WINE à jour avec le travail jusqu'à il y a 3 jours. Je dirais qu'il serait bon de le construire au moins et d'avoir une sélection comme paramètre pour certains systèmes qui rencontrent des problèmes de performances dx3d9 (comme moi avec des jeux comme SC2 sans modification lourde).

Quoi qu'il en soit, c'est bien de lier les correctifs car je n'ai vu aucun lien https://github.com/sarnex/wine-d3d9-patches

@Mushoz Il gère maintenant Unreal Tournament. En 2019, _pourrait_ être pleinement fonctionnel. Vous avez la feuille de route ici .

Ignorer les pilotes et outils natifs qui sont déjà utilisés et prêts à être utilisés en faveur de la couche de transition qui est en cours de développement ne semble pas judicieux. Si quoi que ce soit, Gallium Nine qui est déjà prêt devrait être présenté comme une option pour les utilisateurs d'AMD ; une fois/si VK9 arrive, il peut toujours rester en option.

Je verrais que le principal inconvénient serait que les chemins de code multiples rendent potentiellement les jeux de support plus difficiles. Là encore, les résultats des tests, même maintenant, ne sont pas applicables entre les fournisseurs de GPU

VK9 ne fonctionnera pas sur les appareils non amdgpu / pré-GCN-GPU. Gallium-Nine, d'un autre côté, pourrait éventuellement fonctionner sur de vieux trucs r300g et même jusqu'à des GPU comme mon VEGA10. Mais oui, ces vieux GPU VLIW pilotés par r600g sur lesquels certains de mes amis comptent toujours sont considérés comme obsolètes.

Tout comme D3D9 lui-même.

Je verrais que le principal inconvénient serait que les chemins de code multiples rendent potentiellement les jeux de support plus difficiles. Là encore, les résultats des tests, même maintenant, ne sont pas applicables entre les fournisseurs de GPU

Eh bien, c'est un avantage si ça marche, négligeable si ça ne marche pas. Par exemple, vous pourriez faire en sorte que la valeur par défaut reste l'implémentation de WINE, mais autorisez les utilisateurs à la définir comme variable d'environnement s'ils souhaitent l'essayer. Ils le font déjà si vous obtenez de meilleures performances de WINE lui-même au lieu de DXVK, ce n'est donc pas vraiment un problème d'outillage de leur part pour la configuration. Ils n'ont qu'à le mettre en place. Ils pourraient même embaucher le gars qui fait le patch pour attacher les 10 % restants pour l'amener là-bas.

La différence ici est que WineHQ ne vous vend pas de jeux et est susceptible de devoir effectuer des remboursements

Je pensais que c'était pour ça qu'on avait une liste blanche...

La liste blanche ne fonctionnera pas si vous avez des branchements compliqués de modes de fonctionnement, sûrement

"Compliqué"

La liste blanche ne fonctionnera pas si vous avez des branchements compliqués de modes de fonctionnement, sûrement

Eh bien, cela pourrait être une option qui n'est activée que par les utilisateurs eux-mêmes s'ils veulent l'essayer si les performances du jeu ne sont pas excellentes

La liste blanche ne fonctionnera pas si vous avez des branchements compliqués de modes de fonctionnement, sûrement

Eh bien, cela pourrait être une option qui n'est activée que par les utilisateurs eux-mêmes s'ils veulent l'essayer si les performances du jeu ne sont pas excellentes

Cela me semble assez juste.

Je pense que vous devrez d'abord installer libd3dadapter9-mesa dans l'environnement d'exécution Steam.

Je pense que vous devrez d'abord installer libd3dadapter9-mesa dans l'environnement d'exécution Steam.

Comment fonctionne libd3dadapter9 ? Je sais que GalliumNine est à Mesa proprement dit et les correctifs de WINE le montrent. J'ai vu que c'est dans Ubuntu à partir de 18.10 mais je n'ai jamais utilisé cette bibliothèque.

Comment fonctionne libd3dadapter9 ? Je sais que GalliumNine est à Mesa proprement dit et les correctifs de WINE le montrent. J'ai vu que c'est dans Ubuntu à partir de 18.10 mais je n'ai jamais utilisé cette bibliothèque.

Il s'adresse simplement au tracker d'état D3D9 de Mesa, tout comme opengl32.dll.so de Wine le fait avec les trackers d'état OpenGL communs par exemple¹.
Edit : Désolé, j'ai confondu libd3dadapter9 avec la DLL conçue pour Wine. Je n'ai pas eu assez de café ce jour-là. La bibliothèque en question implémente un tracker d'état D3D9 pour Mesa. Simplifié : Il offre une prise en charge native de D3D9 sans couches de traduction supplémentaires comme WineD3D ou VK9. Jetez un œil à cette présentation si vous êtes intéressé .

¹ : Avertissement : La réponse peut être inexacte.

J'ai pu construire proton avec neuf correctifs en tant que build Linux local avec --no-steam-runtime. Le seul jeu que j'ai testé jusqu'à présent est Valkyria Chronicles 1 et qui se comportait étrangement avec cette version locale. sauvé du tout.

Bien que ces problèmes puissent être liés à la construction de protons avec --no-steam-runtime plutôt qu'avec les neuf correctifs.

Le correctif d'origine de https://github.com/sarnex/wine-d3d9-patches/blob/wine-d3d9-3.16/wine-d3d9.patch n'avait besoin que d'un correctif pour le contexte dans configure.ac voir https://gist .github.com/raetiacorvus/8bf19a733ac131d744030788030941c4 seules les lignes 72 et 73 ont été supprimées du correctif d'origine.

Vous devez toujours appliquer https://github.com/sarnex/wine-d3d9-patches/blob/wine-d3d9-3.16/d3d9-helper.patch d' abord et exécuter autoreconf dans le dossier wine après avoir appliqué les deux patchs.

De plus, j'ai dû ajouter -with-d3d9-nine-module=/usr/lib32/d3d/d3dadapter9.so à la configuration de wine32 dans le fichier suivant, mais cela peut être dû à une configuration incorrecte de l'environnement de construction ? https://github.com/ValveSoftware/Proton/blob/83871c7bf93b785b23b987956b7cc3608d6998b3/build/makefile_base.mak#L713 -L726

N'oubliez pas non plus que vous devez activer le gallium neuf creux winecfg pour chaque pfx.

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

C'est une super nouvelle! Malgré les revers initiaux, avoir une version quelque peu fonctionnelle est un progrès significatif. Puisque je ne connais pas bien le codage, pouvez-vous s'il vous plaît élaborer, pourquoi avez-vous construit avec l'argument --no-steam-runtime ? Le Proton que vous construisez ne fonctionne-t-il pas avec le client Steam ? En effet, tout l'intérêt de Proton est d'exécuter des jeux Steam qui nécessitent Steam DRM avec un client Steam natif au lieu de la version Windows.

@raetiacorvus

J'ai une collection de jeux considérablement importante sur Steam. S'il vous plaît laissez-moi savoir, si vous avez besoin de tester plus de jeux, afin que je puisse essayer de l'arranger.

Le seul jeu que j'ai testé jusqu'à présent est Valkyria Chronicles 1 et qui se comportait étrangement avec cette version locale, par exemple RX 480 a été détecté comme R9 290 dans les paramètres

C'est un comportement normal de Gallium Nine, mon RX 580 fait la même chose sur mes builds Wine-Staging-neine.

Il semble qu'aucun des problèmes que j'ai rencontrés ne soit lié au gallium neuf, mais soit causé par --no-steam-runtime ou le jeu lui-même.

@rea987 --no-steam-runtime signifie que proton est construit contre les bibliothèques locales au lieu de celles corrigées à partir du conteneur docker d'exécution de steam. Il s'agit toujours d'un outil de compatibilité de vapeur valide et peut être utilisé en remplacement des libérations de protons fournies par les valves. Un problème jusqu'à présent est qu'il manque le mappage de contrôleur corrigé du runtime, ce qui a entraîné le problème que j'ai eu avec Valkyria Chronicles. Vous pouvez probablement contourner ce problème en utilisant certains des outils disponibles pour wine pour mapper correctement les contrôleurs.

@raetiacorvus Ce serait merveilleux si vous fournissiez un guide de compilation étape par étape de Gallium Nine pour Proton. Aussi, que diriez-vous de faire une demande d'extraction pour que @ValveSoftware la fusionne peut-être avec l'une des branches. Si cela s'avère fonctionnel, j'envisagerai sérieusement de passer à AMD. @raetiacorvus Mon offre de fournir plus de jeux à tester est toujours valable.

J'ai fait mon propre fork de Proton avec les patchs :

https://github.com/popsUlfr/Proton (consultez la branche proton_3.16_gallium_nine_extras et suivez simplement le readme)

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

Ca marche aussi avec le runtime steam, j'ai du rajouter ce bloc un peu moche de trucs mesa : https://github.com/popsUlfr/Proton/commit/0397af03059c32a6ac5e0213d39769e33f2914df

J'ai ajouté une variable d'environnement PROTON_USE_GALLIUM_NINE=1 que vous pouvez utiliser pour activer facilement Gallium neuf si votre carte le prend en charge (peut également être activée via l'onglet de mise en scène dans winecfg)

Caractéristiques :

• Gallium Neuf évidemment
• Patch Path of Exile dx11 : https://bugs.winehq.org/show_bug.cgi?id=42695
• Force wined3d11 s'il n'y a pas de support Vulkan : #1749
• Activez ffmpeg par défaut et compilez FAudio avec : #2082
• Bascule GLSL pour désactiver les shaders GLSL et utiliser les shaders ARB à la place pour réduire le bégaiement avec wined3d

Voici un build à tester :
~ Proton_3.16-5_Gallium_Nine_Extras.tar.xz ~
~ Proton 3.16-5 Gallium Neuf Extras 0.1.0 ~
~ Proton 3.16-5 Gallium Neuf Extras 0.1.1 ~
~ Proton 3.16-6 Gallium Neuf Extras 0.1.1 ~
~ Proton 3.16-6 Gallium Neuf Extras 0.1.2 ~
Proton 3.16-6 Gallium Neuf 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

Dans votre onglet steamplay, il devrait apparaître sous la forme Proton 3.16-6 Gallium Nine Extras

Au fait, j'ai ajouté ceci au fichier README, après l'étape de configuration, vous devez exécuter make all dist au lieu de seulement make dist ou vous vous retrouverez avec win64 wine et rien d'autre. Cela semble donc être une erreur dans le README du proton officiel ou agissant simplement comme ça sur mon propre système, je ne suis pas sûr.

Super boulot @popsUlfr !

Aurez-vous des versions génériques 32 bits, 64 bits et/ou multiarch dans la page GitHub de votre fork ?

Merci pour l'effort et la fourchette !

@rea987 Vous aimez ça ? https://github.com/popsUlfr/Proton/releases/tag/proton-3.16-5-gne-0.1.0

Dites-moi si cela fonctionne bien pour vous, je n'ai pas accès à une carte amd pour tester cela à fond :/

Hrm, j'ai suivi les instructions, mais il semble que Steam ne récupère pas ce qui se trouve dans le répertoire créé. La liste déroulante de l'outil de compatibilité n'affiche que les versions « régulières » de Steam.

Des idées de ce que je pourrais faire mal? Je suis sur KDE NEON 18.04 (essentiellement Ubuntu) si cela change quelque chose ?

@popsUlfr Justement ! C'est une façon plus claire et explicative de le distribuer. Oui, j'ai aussi besoin d'une carte AMD pour le tester correctement. :-/

@AndrewLoom Votre installation Steam est-elle située dans le ~/.local/share/Steam ou ~/.steam ? Parce que j'avais besoin d'utiliser le plus tard pour le faire fonctionner.

Merci rea987 ! D'Oh, si évident maintenant mais je n'y avais toujours pas pensé. :-)

@AndersDala Pas de problème, c'est un problème qui déconcerte beaucoup de gens ces derniers temps. Peut-être que @popsUlfr peut modifier le guide d'installation pour indiquer également le répertoire ~/.steam ?

Je possède une AMD Radeon Vega 56. Je l'ai installée avec succès et sélectionnée pour être utilisée avec tous les jeux Windows, mais il semble que des jeux comme A Hat in Time ou Dragon Age: Origins ne fonctionneront pas si j'active Gallium Nine avec PROTON_USE_GALLIUM_NINE =1 (avec un préfixe propre), une fenêtre n'apparaît même pas. Avec PROTON_USE_GALLIUM_NINE=0, ils fonctionnent bien.

Je possède une AMD Radeon Vega 56. Je l'ai installée avec succès et sélectionnée pour être utilisée avec tous les jeux Windows, mais il semble que des jeux comme A Hat in Time ou Dragon Age: Origins ne fonctionneront pas si j'active Gallium Nine avec PROTON_USE_GALLIUM_NINE =1 (avec un préfixe propre), une fenêtre n'apparaît même pas. Avec PROTON_USE_GALLIUM_NINE=0, ils fonctionnent bien.

Même GPU et même résultat pour moi. Les jeux (Dishonered, Dead Space) ne démarreront pas avec Gallium.

@Mastergatto , @archfan Avez-vous installé les pilotes Mesa compatibles Gallium Nine ?

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

Oui, je suis sur Arch et j'ai installé mesa-git depuis l'AUR. Il est livré avec Gallium Nine activé.

@archfan D'accord, demain, je vais l'essayer sur mon ancien ordinateur portable AMD qui, espérons-le, prend en charge Gallium Nine.

Oui, car Gallium Nine est activé par défaut avec le package mesa, au moins pour les cartes AMD sur ArchLinux. J'ai aussi du gallium de mise en scène du vin, dans lequel Gallium Nine fonctionne comme prévu.

Pouvez-vous regarder le résultat lorsqu'il fonctionne avec du gallium neuf ?
Donc dans les options de lancement du jeu ajoutez :

PROTON_DUMP_DEBUG_COMMANDS=1 PROTON_USE_GALLIUM_NINE=1 %command%

Lancez le jeu.
Cela déposera des scripts de protons dans /tmp/proton_<username>
Lancez ./run pour voir la sortie.

Aussi juste pour être sûr, passez à un autre proton, redémarrez la vapeur. Passez maintenant au proton de gallium neuf.

EDIT : pour ne pas polluer ce fil je pense qu'il vaudrait mieux en discuter ici : https://github.com/popsUlfr/Proton/issues/2

Désolé également si cela vous a donné de l'espoir et ne fonctionne pas immédiatement. J'ai maintenu cela localement, la partie gallium neuf était plus un "et si" au cas où je pourrais tester sur amd. J'ai décidé de le partager quand même vu que cette discussion devenait plus importante et qu'il pourrait être utile de faire quelque chose sur le support du gallium neuf dans le proton :)
Les autres fonctionnalités intégrées pourraient également être utiles, donc ...

Gallium Nine fonctionne en Proton avec https://github.com/dhewg/nine

Sans surprise, cela casse la superposition Steam, mais sinon, cela fonctionne bien.

Gallium Nine fonctionne en Proton avec https://github.com/dhewg/nine

Sans surprise, cela casse la superposition Steam, mais sinon, cela fonctionne bien.

hé, sympa !

pourriez-vous fournir un guide de ce que vous avez fait? Je suis un peu perdu.

@tatsujb

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

Un autre projet à étudier comme alternative à celui-ci https://github.com/Joshua-Ashton/d9vk

Apparemment, nous devrions utiliser des protontricks pour obtenir tous ces cadeaux ?

quelqu'un est au courant ?

apparemment, nous devrions utiliser des protontricks pour obtenir tous ces googdies ?

quelqu'un est au courant ?

Bon appel. Honnêtement, je préférerais une solution sans protontricks mais je vais essayer ça dès que possible.

J'ai fait ça :

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

mais maintenant le jeu (qui fonctionnait) me donne une boîte d'erreur disant : "Impossible de créer un périphérique direct3d"

@tatsujb Je ne pense pas que ce soit la bonne page pour cela, mais voilà. Utilisez-vous Ubuntu 18.04 ou Mint 19 ? Parce que les pilotes Mesa d'oibaf pour ces versions d'Ubuntu/Mint sont cassés pour Gallium Nine depuis décembre/janvier. J'ai eu le même problème, je suis passé à Ubuntu Mate 19.04 et maintenant cela fonctionne.

@ rea987 J'utilise Ubuntu 19.04, je vais réessayer. EDIT non ça n'aide pas. Qu'a tu fais d'autre? quels arguments d'exécution avez-vous et quel jeu fonctionne pour vous ?

@tatsujb Honnêtement pas grand chose.

• J'ai évité les PPA Mesa tiers car la compatibilité Gallium Nine des pilotes Mesa d' Oibaf est cassée depuis décembre, je ne suis pas sûr que ce soit corrigé.
• Je me suis assuré que libd3dadapter9-mesa et libd3dadapter9- mesa:i386 sont installés.
• Remplacé manuellement /usr/bin/winetricks par la dernière version : https://wiki.winehq.org/Winetricks
• ~/.cache/winetricks effacé
• Réinstallé Gallium Nine Standalone (dernier) via Protontricks.

@rea987

• Remplacé manuellement /usr/bin/winetricks par la dernière version : https://wiki.winehq.org/Winetricks

ouais c'était l'astuce. J'avais compris depuis, merci !

ce serait bien d'avoir à la fois galliumnine et d9vk d'ailleurs. Je les ai comparés sur le chapeau dans le temps aujourd'hui et la galliumnine fonctionne beaucoup mieux (20 % ou plus de fps plus élevés) et ne bégaie pas la première fois que vous visitez une nouvelle zone. avoir les deux augmenterait les chances d'exécuter un jeu directx9 donné avec de bonnes performances, car certains titres pourraient rompre avec l'un ou l'autre.

Dans un monde idéal, le moteur de rendu passerait gracieusement de natif à vulkan à opengl (ou changerait la priorité des deux premiers si d9vk était finalement censé avoir un avantage intrinsèque, mais quand même).
Au lieu de cela, Valve (et même les tisserands de code étant donné tous les ricanements autour de Nine) semble concentré pour simplement créer un joli jardin "assez bien" pour les dernières cartes plutôt que de tout faire fonctionner et de faire fonctionner l'évier de la cuisine. Ils n'ajouteront même pas la vérification automatique des cartes qui manquent du tout de vulkan

Voici mes 20 centimes :

Maintenant que nous avons Gallium Nine autonome, il est assez facile à utiliser car vous n'avez plus besoin de correctifs pour le vin. Tout ce que vous avez à faire est de : (1) installer mesa-libd3d9 à partir du gestionnaire de paquets de votre distribution (2) installer Nine sur votre préfixe wine en utilisant winetricks ou le script d'installation.

En ce qui concerne quelle est la "meilleure" option : je n'ai pas l'intention de déclencher une guerre des flammes ici, je vais donc partager ce que j'ai trouvé jusqu'à présent : https://github.com/Joshua-Ashton/d9vk/issues/ 95#issuecomment -492651741 ― cela signifie bien sûr seulement que sur mon système, Nine était plus rapide avec les titres que j'ai essayés jusqu'à présent, ce qui n'est peut-être pas représentatif de la façon dont ils fonctionneraient sur les ordinateurs d'autres personnes. EDIT: Je me rends compte que Nine n'est actuellement pas une option pour les utilisateurs de NVidia, mais cela fonctionne assez bien avec AMD (radeonsi) et Intel (iris), et s'améliorera sur NVidia une fois que zink sera suffisamment mature.

Nine standalone est un jeu d'enfant à utiliser absolument.
D'une manière ou d'une autre, * chaque fois * que vous le signalez aux développeurs, cela semble tomber dans l'oreille d'un sourd.
Je ne sais pas si les discussions n'auraient peut-être pas pu avoir lieu derrière les portes/IRC et je ne veux pas non plus flamber - mais je ne sais pas quoi dire d'autre pour qu'ils reconnaissent l'état * actuel * des affaires du foutu code, plutôt que n'importe quelle image caricaturale qu'ils ont en tête sur ce qu'était le projet il y a une demi-décennie.

Je me rends compte que Nine n'est actuellement pas une option pour les utilisateurs de NVidia, mais cela fonctionne assez bien avec AMD (radeonsi) et Intel (iris), et s'améliorera sur NVidia une fois que zink sera suffisamment mature.

Il fonctionne également bien sur r600g. Les GPU pris en charge par r600g ne prennent pas en charge Vulkan.

sur nvidia pour l'instant, je bascule entre un ubuntu avec 418 installé et un ubuntu avec Nouveau installé afin que je puisse activer mesa et gallium neuf. les performances avec les jeux linux natifs qui peuvent fonctionner sous nouveau sont acceptables et les jeux wine-gallium-nine fonctionnent très bien.

Mais évidemment, j'ai hâte que mesa soutienne également Nvidia.

Je pense que cela est résolu par D9VK maintenant. Je l'ai testé avec SC2 et quelques autres jeux et cela fonctionne très bien. Espérons que cela sera intégré dans DXVK à l'avenir et que les correctifs seront également poussés vers Proton.

d9vk fonctionne toujours bien moins bien que le gallium neuf, mais oui, même le support d9vk intégré serait génial car c'est déjà plus difficile que le gallium neuf à intégrer dans une installation de protons existante

une autre partie délicate de l'expédition de d9vk est qu'elle nécessite la dernière mesa. pas seulement la dernière version, elle est basée sur mesa-git. donc pour le rendre accessible à une grande variété de distributions, vous devrez peut-être même expédier mesa-git avec lui ou demander aux utilisateurs de comprendre comment obtenir mesa-git pour leur distribution

@shanefagan Non, d9vk est beaucoup, beaucoup plus lent que neuf, voir mes conclusions dans mon post précédent.

Il existe une version autonome qui est facile à installer. Peut-être qu'ils peuvent être livrés avec Proton et activés avec un argument. Le D9VK est génial, mais comme d'autres l'ont dit, il est plus lent et utilise souvent des pilotes à la pointe de la technologie. L'installation de Gallium via winetricks fonctionne, mais avoir une option intégrée serait vraiment bien.

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

Bonjour !~ Est-ce que quelqu'un d'autre rencontre des plantages silencieux sur 4.11-6 lors du lancement de jeux avec Gallium Nine Standalone installé ?

@Bryophyllum même, le jeu ne se lancera pas après l'installation de la galliumnine via des protontricks.
Le pire, c'est qu'il n'y a pas de moyen facile de savoir si la galliumnine fonctionne en premier lieu.

En fait, après quelques essais et erreurs, cela a fonctionné :

Pouvez-vous regarder le résultat lorsqu'il fonctionne avec du gallium neuf ?
Donc dans les options de lancement du jeu ajoutez :

PROTON_DUMP_DEBUG_COMMANDS=1 PROTON_USE_GALLIUM_NINE=1 %command%

Lancez le jeu.
Cela déposera des scripts de protons dans /tmp/proton_<username>
Lancez ./run pour voir la sortie.

Aussi juste pour être sûr, passez à un autre proton, redémarrez la vapeur. Passez maintenant au proton de gallium neuf.

EDIT : pour ne pas polluer ce fil je pense qu'il vaudrait mieux en discuter ici : popsUlfr#2

Désolé également si cela vous a donné de l'espoir et ne fonctionne pas immédiatement. J'ai maintenu cela localement, la partie gallium neuf était plus un "et si" au cas où je pourrais tester sur amd. J'ai décidé de le partager quand même vu que cette discussion devenait plus importante et qu'il pourrait être utile de faire quelque chose sur le support du gallium neuf dans le proton :)
Les autres fonctionnalités intégrées pourraient également être utiles, donc ...

Si je lance depuis Steam, il affiche "Installation des pilotes" ou quelque chose comme ça et désactive la galliumnine avant de lancer le jeu.
Cependant, le lancement du jeu via des scripts dumpés ne désactive pas la galliumnine et le jeu se lance avec.

@tuxutku Certains des jeux avec

Le pire, c'est qu'il n'y a pas de moyen facile de savoir si la galliumnine fonctionne en premier lieu.

Pas assez. Si vous exécutez Steam Client à partir de la CLI, vous verrez un message de Gallium Nine en vert ou en rouge au démarrage d'un jeu ; cependant, dans ce cas, rien n'est sorti.

Avec PROTON_LOG=1 j'obtiens cette erreur lorsque j'essaie d'exécuter 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

Je ne sais pas ce qui le cause, ni comment le résoudre, mais, espérons-le, quelqu'un pourra trouver la racine de ce problème en rassemblant tous les indices.

Je vais ouvrir un nouveau problème sur le client Steam qui désactive la galliumnine avant le lancement du jeu, j'ai ce problème sur un autre jeu

Bonjour @tuxutku , cette demande de fonctionnalité est le bon endroit pour discuter du nouveau comportement. Il semble que le changement se soit produit en même temps que d9vk a été ajouté à Proton et peut être un effet secondaire de la gestion de Proton.

Le pire, c'est qu'il n'y a pas de moyen facile de savoir si la galliumnine fonctionne en premier lieu.

Pas assez. Si vous exécutez Steam Client à partir de la CLI, vous verrez un message de Gallium Nine en vert ou en rouge au démarrage d'un jeu ; cependant, dans ce cas, rien n'est sorti.

Avec PROTON_LOG=1 j'obtiens cette erreur lorsque j'essaie d'exécuter 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 ce n'est pas aussi facile que de voir si Native Direct3D 9 v0.5.0.356-release is active. For more information visit https://github.com/iXit/wine-nine-standalone est posté.
Par exemple, lors du lancement du jeu Tomb Raider 2013 à partir de la commande ./run évaluée, il publie la ligne car le lanceur utilise directx9, mais pas le jeu. J'ai du bidouiller un registre avec regedit pour jouer au jeu avec galliumnine

Les jeux avec VAC fonctionnaient avec le vin, autant que je sache. mais maintenant ils ne le font pas pour une raison quelconque. CSGO se plaint que les signatures de fichiers ne correspondent pas. TF2 ne donne aucune raison précise.

Pour une raison quelconque, PROTON_DUMP_DEBUG_COMMANDS=1 n'a pas fonctionné sur Team Fortress 2 et j'ai dû copier et modifier un script d'un autre jeu.

#!/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[@]}}"

sortie TF2

sortie csgo

Voici également le script généré automatiquement par 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[@]}}"

je n'ai pas essayé csgo mais tf2 s'exécute et n'a pas de problème de vide sous wine steam

@tuxutku pourquoi

@tuxutku
Qu'est-ce que cela a à voir avec Gallium 9 ?

Je demandais parce que je suis vraiment curieux. arrêter les votes négatifs

@tuxutku pourquoi

parce que les jeux source 1 ne fonctionnent pas assez bien sous Linux ?
Ils ont fait pire avec la galliumnine, mais cela ne veut pas dire que les ports natifs se portent bien. Ils font très mal par rapport à leurs homologues Windows.
Les nouvelles cartes des zones de danger de CS:GO sont directement injouables (~15fps) sur amd a10-9620p + rx 540.
Lorsqu'il y a trop de géométrie dans le paysage, la fréquence d'images chute fortement dans tous les jeux source 1 que j'ai testés jusqu'à présent (nuclear dawn, cs: go, tf2, half-life 2, half-life 2 team death match).
left4dead2 est une exception et il utilise en fait assez bien le GPU

l'hypothèse est "le code est mauvais" plutôt que "les appels sont interprétés via GL plutôt que vulkan", n'est-ce pas ?

si vous avez un jeu natif vulkan fonctionnel, les résultats ne seraient-ils pas meilleurs 100% du temps en natif ?

Étant donné que cela est disponible en externe à partir de proton avec protontricks, je dirais que cette demande de fonctionnalité est plutôt remplacée.

Si être réparable manuellement l'appelait un jour, alors nous pourrions résoudre la moitié des problèmes ici.

Étant donné que cela est disponible en externe à partir de proton avec protontricks, je dirais que cette demande de fonctionnalité est plutôt remplacée.

Steam lui-même désactive toujours la galliumnine lors du lancement du jeu ou de la confirmation du cache. De plus, il n'y a pas de drapeau proton pour l'activer et cela nécessite des mises à jour manuelles.

J'ai trouvé que la galliumnine est souvent non seulement plus rapide que la traduction par défaut de wined3d (sur r600), mais elle semble résoudre les problèmes de plein écran pour de nombreux jeux (commandant suprême FA par exemple), l'ajouter à proton semble être assez facile étant donné la version autonome, je ne dirais pas que cela devrait être une option "prise en charge", mais ce serait bien de l'avoir intégrée comme solution de contournement/amélioration.

je crois que cela est pris en charge depuis le proton 5

EDIT : nvm je pense à d9vk

je crois que cela est pris en charge depuis le proton 5

EDIT : nvm je pense à d9vk

Ouais ... d9vk ne fonctionnera pas avec r600, malheureusement. :/

Ce problème doit être pris en compte, nous devrions être en mesure d'activer le gallium neuf sans recourir à des hacks (tels que des protontricks) uniquement par des variables d'environnement.

C'est facile à réparer (vous avez déjà beaucoup de forks et de solutions de contournement pour résoudre ce problème), Gallium Nine a maintenant une meilleure prise en charge du GPU (fonctionne désormais avec les derniers pilotes Intel) et donne une amélioration des performances de 1,5 à 2 fois par rapport à DXVK et wined3d.

Et vous avez déjà reçu un tas de rapports de jeux parlant d'une compatibilité améliorée simplement en utilisant 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

Je sais que ce n'est probablement pas une priorité pour vous puisque cela ne s'applique qu'aux anciens jeux, mais allez, il existe un énorme catalogue de grands jeux qui bénéficieront de Gallium Nine.

Une mise à jour sur ce sujet? @popsUlfr a malheureusement cessé de fournir de nouvelles versions de Proton avec prise en charge native de D3D9 il y a plus d'un an.

Une mise à jour sur ce sujet? @popsUlfr a malheureusement cessé de fournir de nouvelles versions de Proton avec prise en charge native de D3D9 il y a plus d'un an.

J'ai utilisé un proton normal + gallium neuf autonome. Je l'ai installé avec winetricks et désactivé DXVK

J'ai utilisé un proton normal + gallium neuf autonome. Je l'ai installé avec winetricks et désactivé DXVK

Bon à savoir! Quelle version de Proton avez-vous utilisée et comment avez-vous désactivé DXVK ? WineD3D interférait la dernière fois que j'ai essayé cela.

@crt0mega galliumnine ("d3d9") sera toujours remplacé par 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 = []

ça doit être réparé...

ou on peut utiliser Proton-5.9-GE-8-ST/dist/bin/wine sans proton (et sans jeux steam)
ps : configuration 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 --force galliumnine