Gaming Rig Linux

[Deleted member 47804]

Salut salut,

Mon PC de jeu est en bout de course, et je pense monter une nouvelle machine.
J'ai toujours eu du mal avec Windows, et aimerais tenter l'aventure Linux maintenant que de plus en plus de jeux sont disponible.
Pour le moment, je pensais à Elementary OS +:
_Steam
_Wine
_Vmware

Mes questions sont:
Est ce simple d'installer des jeux Steam sous Elementary OS? Qu'en est il des performances? Est ce mieux que sur Mac. (je trouve les performances des jeux macs degeulasses.)
Que vaut le support des cartes graphique sous Vmware Linux? Je sais que sous Mac la souris peut déconner quand je virtualiser un Mac. (Je joue de temps en temps à SWTOR)

Merci pour vos opinions.

 

[Locke]

Que vaut le support des cartes graphique sous Vmware Linux?

Dans une machine virtuelle avec VMware, ça restera toujours une émulation, donc impossibilité d'utiliser la carte graphique d'un Mac.

Je sais que sous Mac la souris peut déconner quand je virtualiser un Mac.

Dans toutes mes machines virtuelles sous VMware Fusion ou Parallels Desktop, je n'ai jamais eu de problème.

 

[Deleted member 47804]

Est ce que tu penses que Vmware Linux est moins développé que Vmware MacOs?
Je n'ai pas la patience d'attendre un nouveau Mac Pro et je ne crois plus dans la plateforme d'Apple pour mes distractions... Linux me parait donc la solution. Windows devenant de plus en plus infecte...

 

[Locke]

Est ce que tu penses que Vmware Linux est moins développé que Vmware MacOs?

Aucun rapport, que ce soit sous VMware ou Parallels Desktop la puissance d'une machine virtuelle est liée avec le processeur, la carte graphique et la quantité de mémoire d'un Mac. La boîte à outils, en fait l'équivalent des Préférences Système sous macOS, permet de faire des réglages fins dans certaines options.

Par exemple avec mon iMac 27 2015, processeur i7 4 coeurs, 24 Go de mémoire et carte graphique de 4 Go, je peux attribuer une puissance processeur entre 2 et 4 coeurs, 12 Go de mémoire et 2 Go de mémoire pour l'émulation de la carte graphique. Il faut bien comprendre que tout est émuler. Une machine virtuelle est un paquetage (contenant) entièrement indépendant de macOS.


Quelle que soit le type de machine virtuelle avec n'importe quelle installation d'un OS (Operating System), la puissance virtuelle est toujours liée avec le processeur et la carte graphique qui sont installées d'origine dans le Mac.

Est ce mieux que sur Mac. (je trouve les performances des jeux macs degeulasses.)

C'est comme avec un PC, la qualité est liée avec la puissance de la carte graphique.

Que vaut le support des cartes graphique sous Vmware Linux?

Il faut que tu comprennes ce que j'ai déjà mentionné, une carte graphique dans une machine virtuelle sera toujours une émulation et ce quelle que soit l'OS que l'on installera.

 

[Deleted member 47804]

Ca je le comprend depuis le départ, me servant aussi de Machine Virtuelle sous Mac Os.
Le mot employé aurait du être moins bien émulé?

PS: Est ce que quelqu'un peut répondre à mes questions qui portaient essentiellement sur 1) la fiabilité d'élementary OS pour faire tourner Steam. 2) Les performances natives sous Steam
3)Les performances des machines virtuelles LINUX (et non mac) pour émuler Windows?

 

[Locke]

Il n'y a pas beaucoup d'informations pour steam 2 sous linux

Si tu ne veux pas de machine virtuelle pour exploiter totalement la mémoire et la carte graphique d'un Mac, il faut te créer une partition dédiée pour Linux un multi boot avec rEFInd ou rEFIt, je ne sais plus lequel des deux est le meilleur. Je ne comprends pas ton point 3) ?

 

[bompi]

Il n'y a pas beaucoup d'informations pour steam 2 sous linux

Si tu ne veux pas de machine virtuelle pour exploiter totalement la mémoire et la carte graphique d'un Mac, il faut te créer une partition dédiée pour Linux un multi boot avec rEFInd ou rEFIt, je ne sais plus lequel des deux est le meilleur. Je ne comprends pas ton point 3) ?

rEFIt n'est plus maintenu donc rEFInd est l'outil à prendre.
Cela dit, si on ne veut plus de macOS, on peut s'en passer et installer Linux directement.
Sur mon MBA, qui est un peu en désordre, je peux même démarrer sur macOS ou KUbuntu, alors que je n'ai pas installé rEFInd...

Pour en revenir aux questions :
a) eOS est basé sur Ubuntu (donc, ultimement, sur Debian). On peut estimer que tu auras des résultats similaires à une utilisation de Ubuntu.
L'utilisant à l'occasion, je n'ai jamais décelé, pour les applications traditionnelles, le moindre problème, même avec Wine.
Pour des jeux, je ne vois malheureusement que le test en grandeur nature pour s'en assurer.
b) Concernant Steam, il faut noter qu'ils utilisent une version modifiée (et sans doute améliorée) de Wine. Avec Wine, il ne s'agit pas d'émulation mais de reconstruction des bibliothèques Windows, donc on peut espérer des performances convenables.
c) Ta question me semble plutôt : est-ce que VMWare Workstation (sur Linux) est plus/moins/également performant que VMWare Fusion (sur macOS), entre autres lorsqu'on utilise une machine virtuelle Windows ?
N'utilisant pas mes VMs pour des travaux intensifs, je n'ai pas poussé aux limites les deux solutions. Pour autant, dans mon utilisation quotidienne, c'est tout-à-fait équivalent.
L'intégration de VMWare Fusion à macOS est plus poussée que son équivalent sous Linux mais c'est une question d'ergonomie, pas de performances.

 

[Deleted member 47804]

Merci Bompi, c'était exactement mes question. Je construis la machine, et ce ne sera pas un Hackintosh, donc je ne devrais pas avoir besoin de solution triple boot.

 

[Locke]

Ouais, ben moi je ferais mieux de ne pas prendre autant de LSD comme dans ta signature.

 

[bompi]

Merci Bompi, c'était exactement mes question. Je construis la machine, et ce ne sera pas un Hackintosh, donc je ne devrais pas avoir besoin de solution triple boot.

Note que eOS a un défaut : il n'y a pas de méthode officielle de mise à jour avec conservation de l'existant.
Jusqu'ici, à chaque nouvelle version, il est conseillé de tout réinstaller.
Vu la qualité des systèmes de paquetage de Linux, leur souplesse et leur fiabilité, on pourrait espérer mieux.
(Il existe des méthodes officieuses, toutefois).

Si tu construis ta machine, tu vas décider de sa configuration à tout point de vue.
Si je peux hasarder un conseil : réserve-toi un peu d'espace pour un autre système.
Même si Linux a énormément progressé, il est toujours possible qu'une mise à jour casse ton système [je le redis : ça ne m'est pas arrivé depuis des lustres]. En redémarrant avec la touche Shift enfoncée, on pourra choisir un noyau précédent mais dans certains cas ça ne suffit pas. Il est alors simple de démarrer sur une clef et de réparer le bazar. Si on a une clef...
C'est là que disposer d'un système complètement indépendant est pratique. Une petite distribution légère ne prendra que quelques GB (et même : sur des disques de 500 GB ou 1 TB, on peut bien bloquer 50 GB) et te rendra service.
Accessoirement, cela permet aussi de tester d'autres versions de Linux (Fedora (bof), Kali, *Ubuntu, Debian etc.)

Sur mon PC principal, le Linux de base est une version hybride (KUbuntu repassé manuellement en autre chose...) mais à côté, j'ai justement un petit eOS pour test et dépannage.

 

[Deleted member 47804]

Merci pour ces conseils!
et de me pointer ce défaut de eOs. Je vais encore faire un peu de recherche sur les différentes versions de linux pour lesquelles peuvent convenir.

 

[byte_order]

Il faut que tu comprennes ce que j'ai déjà mentionné, une carte graphique dans une machine virtuelle sera toujours une émulation et ce quelle que soit l'OS que l'on installera.

Ce n'est plus tout à fait vrai.

Il a de plus en plus de support "3D pass-through" pour exposer à l'OS guest une carte GPU virtuelle qui derrière n'est qu'un tuyau quasi direct avec la GPU du host, bypassant un max de couches intermédiaires de l'OS host, à l'instar de ce qui ce fait également avec SRV-IO. Cela se fait en général via une version de la libGL.so qui se contente de transporter les commandes (et les réponses) jusqu'au pilote OpenGL de l'OS host, qui lui les exécute sur la GPU.

Pour un jeu vidéo en full screen, l'overhead de ce tunnel entre l'OpenGL du guest et l'OpenGL du host n'est plus vraiment sensible en comparaison des gains que l'usage réel de la GPU apporte dans les temps de calcul.