WhiteCat a écrit 699 commentaires

Un profil pour détecter les océans absurdes et trucs du genre ?
Le driver n'a pas ce pouvoir, un driver ne peut pas refuser de charger spécifiquement des shaders. Et quand bien même ce serai possible, le code source est fermé donc ce serai pas facile.

Bien sûr que si c'est possible, le driver fait tout ce qu'il veut ! C'est lui qui lit de code source OpenGL, qui le transforme et qui le compile en code machine (ISA).
Détecter un programme spécifique, Mesa le fait (par exemple pour contourner des bugs de programmation GLSL dans les benchmarks Unigine). Alors ensuite détecter les shaders pour les transformer arbitrairement, y'a aucun soucis. J'imagine que détecter une tesselation 128x ça doit pas être bien compliqué.

C'est principalement dû au fait que Nvidia offre "gratuitement" ses cartes au médias alors que AMD non….

Et qu'attends AMD pour faire pareil ?
Voilà c'est ça… ils sont nuls en marketing, CQFD.

Je t'avoue que mon commentaire était biaisé. J'aurais plutôt du dire : certains constructeurs (dont Asus et Creative) se foutent royalement du support Linux et donc le support de leurs cartes est laissé au soin de la communauté qui n'a pas quatre bras d'où les problèmes de support complet pour certaine carte :)

Pour revenir à ta carte, je ne connaissais pas, le support ALSA est clairement stipulé sur la page web du fabricant donc c'est cool, au moins ça montre qu'il y porte un intérêt donc pas étonnant que le support soit bon, tant mieux ! Tu as une entrée microphone aussi ? Et tu utilises Pulseaudio avec ça ?

Qu'est ce qui manque pour avoir un son de qualité sous Linux ?

Il manque quand même des bons pilotes pour beaucoup de carte audio. À titre d'exemple, je possède une carte haut de gamme (Asus Essense STX) et l'entrée microphone (qui est censé être super donc) ne fonctionne pas…

Et Pulseaudio ne sait pas gérer plusieurs "canaux de fréquence" en même temps (44,1 kHz, 48 kHz, 96 kHz, etc.). Je ne sais pas si c'est le bon terme, mais en gros dans la config de Pulseaudio c'est marqué que le format par défaut est 44,1 kHz. Donc tout ce que tu vas lui balancer sera lu directement dans ce format, même si tu ouvres un fichier audio master 24-bit 96 kHz. C'est con… surtout que ça fait travailler le CPU qui doit convertir le flux en 44,1 kHz. Encore plus con quand tu possèdes comme moi une carte audio haut de gamme qui peut lire ces formats de manière parfaite.

Y'a une référence à Inkscape dans le journal quand même.

Y'a des options "EHCI Hand-off support" et "xHCI Hand-off support" souvent dans les BIOS/UEFI. J'ai jamais trop pigé sur quelle valeur (enabled ou disabled) c'était mieux de mettre ça… À tester chez vous peut-être ?

Merci pour cette info édifiante, et vraiment pitoyable de la part d'NVIDIA (et des développeurs du jeu surtout en fait…).

Ceci dit, qu'est ce qui empêche AMD de faire un profil pour détecter cette dégradation volontaire de performance et ainsi la désactiver ? Rien. Donc qu'est ce qu'ils foutent ?
Pour rejoindre un peu ce qu'à dit "Pif le Chien" plus haut dans les commentaires, AMD fait du bon matos mais niveau support et marketing ce sont des zéros, ils restent là à pleurnicher et voir leurs ventes diminuer petit à petit. Faut vraiment qu'ils changent de stratégie et qu'ils se sortent les doigts du luc.

La création de la table de partition est instantanée. C'est la création du système de fichiers qui est plus longue (quelques minutes).

Essaye de jouer un jeux du type counter-strike 1.6 à 60 fps et à 100 fps sur un écran 60 hz, tu verras ce que je veux dire. Ta presque tout qui change, niveau ping, ta ton ping minimal que à 100 fps plus tu diminues le fps plus ta le ping qui augmente, niveau mouvement souris, bref presque tout le jeux repose sur le fps.

C'est très certainement une exception dans l'histoire du jeu vidéo. Faut pas généraliser. Si le ping était directement lié au nombre de FPS ça se saurait. Et encore une fois, si on a 60 FPS, personne vient se plaindre d'une chute de FPS.

Avec le graphique d'avant Ça marchait bien mais c'était un peu limite au niveau performance graphique. Avec la nouvelle carte il a une baisse mais c'est à cause du pilote libre qui diminue très fortement les performances.

Il tournait avec son ancienne carte avec le pilote libre aussi…

Peut-être de base il avait une vingtaine de fps et avec la nouveau carte il est limiter à 60

Non il a clairement dit qu'il y avait une chute de FPS avec sa nouvelle carte.

ça parait mieux à 60 que 20 mais on peut faire mieux

Si t'as pas d'écran adapté (120/144 Hz), au delà de 60 FPS ça sert quasiment à rien. Et encore une fois, s'il était limité à 60 FPS, il ne viendrait pas se plaindre vu que 60 FPS tu peux pas avoir mieux en terme de fluidité sur un écran standard !

+1
À mon avis c'est un problème avec le jeu.

Si tu as acheté ta carte en ligne il y a moins de 14 jours, tu peux te la faire rembourser sans justification.

Si la synchro verticale était activée, au "pire" il serait "limité" à 60 FPS. Ça ne ramerait donc pas du tout !

Je ne saurais pas te dire pourquoi tu ne vois d'amélioration de performance avec Torcs. À mon avis tu devrais te renseigner auprès des développeurs du jeu pour comprendre pourquoi ta carte n'exploite pas mieux le jeu (ou réciproquement plutôt !).

Concernant la détection de la carte dans le bench, ce n'est pas anormal. Aussi étonnant que cela puisse paraitre, les manières normalisées pour les applications de détecter ça sont assez récentes. Donc souvent chaque application a sa manière de faire. Plus d'infos : https://bugs.freedesktop.org/show_bug.cgi?id=72575

Par curiosité, c'est quoi la référence exacte de ta carte graphique ? Car c'est la première fois que j'en entends parler, elle n'est pas référencée sur Wikipedia encore, ni même sur le site de Sapphire en fait !

Est-ce que tu peux comparer les performances entre les 2 cartes avec le benchmark Unigine Valley par exemple. Tu peux le télécharger ici :
https://unigine.com/products/benchmarks/valley/
Ensuite il suffit de l'exécuter via le shell. Et le rendre exécutable avant si besoin (chmod u+x).

Que donne ces commandes :

$ uname -a
$ lspci -nnk |grep VGA
$ glxinfo |grep "OpenGL renderer string"

Quelle est le modèle de ta carte mère ?

Une mise à jour du BIOS/UEFI c'est vraiment pas compliqué. Durant ces 15 dernières années j'ai flashé un nombre de BIOS que je ne peux plus calculer, via les utilitaires Windows, DOS avec disquette, FreeDOS, flashrom sur Linux, via le BIOS même, via le UEFI même, bref aucun soucis… ça se passe bien. La seule couille qui pourrait arriver en fait c'est un panne électrique pendant les quelques secondes qui se passent. Ça serait juste pas de chance.

De plus, s'il y a un bug au niveau du BIOS qui amène ton problème d'@MAC, la correction propre est de fixer le BIOS, pas des scripts dans l'OS.

En plus de ça, les mise à jours apportent parfois des améliorations intéressantes à faire, même sans bug particulier connu par l'utilisateur.

Ceci dit, je doute que ton soucis vienne du BIOS mais plutôt du pilote Linux qui n'est pas le bon. Je crois que j'avais eu ça (@MAC 00:00:00:00:00:00) sur une CentOS 6 avec une carte mère assez récente qui avait un chipset Realtek trop récent. Sur une distribution plus récente l'@MAC était bien reconnue.

Quelle version d'Ubuntu tu utilises ?
Et c'est quoi le chipset réseau ? (lspci -nnk)

Bonsoir,

Quelle version de Debian tu comptes utiliser ?

Tu n'installe surtout pas la swap dans le ssd, ça ferait vieillir prématurément le ssd en raison des nombreux cycles d'écriture, la partition d'échange (swap) se place sur le disque dur.

En usage normal le SWAP ne représente que quelques dizaines de Mo, généralement même rien. L'usage du SWAP se règle par ailleurs très bien avec le swapiness.
En condition anormale (manque de RAM), dans ce cas c'est très bien que le SWAP soit sur le SSD pour ne pas rendre le PC complètement lent.

Microsoft et Red Hat estiment que c'est une bonne chose de mettre le SWAP sur SSD.

Oui si tu veux un contexte OpenGL 3.3, il faut utiliser :

SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 3);

Ah et donc pour conclure : inutile d'essayer de mettre à jour ta pile graphique, tu as déjà ce qui se fait de mieux en matière de support OpenGL pour ta puce.
Tu pourras revoir ça dans les semaines à venir avec les prochaines versions de Mesa.

À l'heure actuelle, le pilote de ta puce (HD Graphics "GT1") supporte effectivement OpenGL 3.3.
glxinfo te donne notamment 2 lignes :

OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.0.5
OpenGL version string: 3.0 Mesa 11.0.5

La première est la version "Core" d'OpenGL. Et c'est ça qui est important.

La deuxième ligne, c'est la version "Compatibility" d'OpenGL. Celle-là est limitée à OpenGL 3.0 et le restera toujours, aux dires unanimes des développeurs Mesa. Personne n'utilise ça.
Plus d'infos ici : OpenGL.org Core And Compatibility in Contexts. Perso je ne comprends toujours pas très bien tout le merdier Core/Compatibility/Forward Compatible mais on va dire qu'on s'en fou, ce qui compte c'est le Core profile.

Il est très probable que dans les mois à venir ta puce aurait le droit à un pilote OpenGL 4.0, 4.1 puis 4.2. En revanche, pour 4.3 et +, je ne sais pas…

Il y a ce tuto qui me semble bien fait aussi :
https://openclassrooms.com/courses/developpez-vos-applications-3d-avec-opengl-3-3

Sauf que l'IndexedDB contient potentiellement des données importantes (contenus modifiés et non-synchronisés, etc.). En plus, les modifications ne sont pas journalisées dans l'IndexedDB.

C'est pas le problème de l'utilisateur ça. Comme expliqué sur la page Mozilla, c'est au développeur de se prémunir de ce genre de chose : https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB#Warning_About_Browser_Shutdown

Du coup, si l'utilisateur choisit de supprimer l'historique de la dernière heure, tu fait comment pour remettre les DBs des sites visités dans leurs états précédents ?

Ben on fait pas, puisque l’utilisateur a choisi de tout effacer volontairement ! Remplace les mots "historique" et "DBs" de ta phrase par "cookies" et tu verrais que c’est choquant.

Tu trouveras le détail du support des 2 phases à cette page (au point 6) :
https://support.microsoft.com/en-gb/gp/lifepolicy

Pour info Red Hat dispose également de ce genre de support par phases, dont les détails sont disponibles ici :
https://access.redhat.com/fr/support/policy/updates/errata

Or, OpenGL EST libre, c'est l'avant dernière version de GL, qui elle ne l'est pas; lorsque Silicon Graphics aura une nouvelle version, la version actuelle de GL sera libre.

Euh je ne suis pas expert dans le domaine, mais ce schéma SGI GL "n+1" pas libre et OpenGL "n" libre n'est plus d'actualité d'au moins deux décennies. Je me demande même si ça a un jour exister…

Je m'excuse publiquement si tu me montres qu'SGI dispose d'un "SGI GL" 4.6 quelque part (et quels constructeurs en dispose d'une implémentation qui peut en tirer parti ?)