Non, la raison pour laquelle ils font ça, c'est car bientôt, les microcodes devront être signés par NVIDIA. Alors on pourra tjs essayer d'écrire le notre et le faire signer (comment on le teste en attendant?), mais ça serait bien plus simple si on pouvait utiliser ceux d'NVIDIA. La raison pour laquelle NVIDIA fait ça, c'est pour augmenter la sécurité. Actuellement, les microcodes ont souvent la possibilité d'accéder à la mémoire centrale, sans contrôle. C'est pas acceptable! Du coup, la seule solution quand c'est nécessaire, c'est de faire confiance au code. Mais si n'importe qui peut remplacer les firmwares, c'est impossible de faire confiance.
On a donc les problèmes suivants:
Impossible de mettre à jour/fixer les microcodes --> Open source impossible ici. Faut se dire que c'est comme du hardware.
On a besoin de se mettre d'accord sur l'interface et l'implémentation --> d'où l’intérêt qu'on ait accès aux devs
On aussi besoin de montrer le code aux utilisateurs pour garantir ce qu'ils font --> On a un décompilateur en cours d'écriture (ils sont moyen chauds pour ça, mais ils ont pas le choix)
Pour une certaine definition de optimale ;-) Pour certain cas d'utilisation, tel que editer du code dans un editeur texte quand on est sure batterie, le fait d'utiliser OpenGL pour faire le compositing au lieu du CPU augmente sensiblement la consomation de batterie (Je perds 1W, ce qui represente sur mon PC 1h d'autonomie).
C'est étonnant et contraire à mon expérience. Mais c'est possible que si très peu de choses sont modifiées à l'écran, le CPU peut être plus efficace. C'est quelque chose que je le driver devrait prendre en compte!
D’après le wiki de nouveau, il faut que j’attende Linux 3.12 et Mesa 9.3 pour avoir l’accélération graphique pour ma carte (moteur VP4). Doh.
Et ça suffira que si tu veux accélérer le décodage mpeg1/2. Pour h264, ça marche pas encore et le dev sait pas encore pourquoi. Il devrait s'y re-pencher assez rapidement.
Parce que là, si je comprends bien la situation, en imaginant que l'on reprogramme un moteur de rendu comme PovRay en OpenCL, il faudrait le compiler 3 fois, une fois pour chaque fabriquant…
La compilation est faite par le driver, c'est caché pour le développeur d'applications. C'est la même chose pour les shaders en opengl.
Donc ça veut dire que le firmware s'occupe un peu plus que d'accélération vidéo nan ?
Oui, les microcodes sont nécessaires. C'est une bonne chose qu'il y ait des microcodes, mais par contre faudrait qu'ils soient libres. D'où le besoin de reverse engineering!
l'architecture de Wayland permettra-t-elle de se passer de la couche pilote userspace (type xf86-video-intel) que l'on connait avec X ? Si oui, pourquoi ?
Oui car toutes les opérations nécessaires pour allouer un contexte graphique et gérer des buffers graphique a été standardisé, c'est EGL. Avec ça, les applications peuvent utiliser le GPU pour faire du rendu (via OpenGL/VG ou toute autre API) et partager ses buffers graphiques avec un compositeur wayland.
C'est implémenté dans mesa pour intel, radeon et nouveau.
Cela dit, y'a plein de façon de communiquer avec un compositeur wayland, celle là est simplement la plus optimale (tout sur le GPU).
Sauf que je préfère l'option "faire pression économique sur AMD" pour obtenir le retrait des firmwares que l'option rétro-ingénierie des firmwares.
Pfff, comme si ils avaient le choix … à moins que tu acceptes de perdre toute accélération graphique! Les avocats d'AMD doivent empêcher la libération pour une bonne raison. La seule solution acceptable est donc la rétro-ingénierie. C'est trop facile de rester dans son fauteuil et dire qu'une entreprise est pas assez libre…
La question 13 en particulier me semble plus lourde de conséquence que les débats Xorg/Mir/Wayland. J'aimerais un jour comprendre pourquoi il faut un SDK par marque (intel, AMD, Nvidia) pour compiler un programme OPENCL alors que c'est un standard approuvé par toutes ces marques !!!! °_° !!!!! TONNERRE DE BREST !
Simplement parce que le standard est sur l'interface, pas sur l'implémentation. Dois-je te rappeler que chaque chipset a sa façon de travailler, son langage? Oui on peut factoriser du code (Gallium), mais au final, les implémentations vont forcement différer à un moment. Tu as vision trop logicielle du problème, on parle de compilateur et de driver là.
Et je pense que ça va bien simplifier la vie de ceux qui naviguent régulièrement entre le pilote libre et le non-libre (les deux pourront être installés en même temps, car plus de conflit entre la libGL et celle de Nvidia).
Oui, mais je sens venir la tonne d'utilisateurs pas content qui ne comprendront pas pourquoi utiliser le module nvidia avec xf86-video-nouveau ne marche pas! Cela dit, j'attend quand même ça avec impatience!
Donc les microcodes propriétaires de décodage vidéo ne sont ni réécrits en libre, ni embarqués dans le code (puisque non libres).
Exact.
Il n'y a pas de décodage vidéo du tout ? C'est le CPU qui gère et on n'exploite pas le bloc matériel dédié ?
Pas de décodage vidéo sans microcodes sur les cartes modernes, en effet. Seul le redimensionnement et quelques effets de lissage sont gérés (via XV) dans ce cas.
Si tu veux en savoir plus, j'ai mieux expliqué la situation dans la dépêche "Linux pour Workgroups 3.11" qui devrait paraître à la fin de la semaine, à la sortie de Linux 3.11.
Et tu n'aimerais pas par exemple voir AMD publier les specs pour ces firmwares ?
Tu sais, ça fait autant chier les devs AMD que toi cette situation. Franchement, AMD fait un boulot excellent. Reverser un micro code, c'est long et laborieux mais ça n'a aucune mesure avec le développement d'un driver complet. Si cette situation te gène, considère ça comme un bon moyen de commencer à bosser sur ce projet.
Autre question : Ce que les gens de Coreboot appellent le "VGA BIOS", c'est la même chose que le firmware ou c'est complètement différent ? Parce qu'il me semble que là aussi AMD ne joue pas le jeu…
Tu dois parler du VBIOS. Non, ce bios n'est pas libre non plus. Il est inclu par le fabriquant du matériel dans la carte à sa fabrication. Pareil pour NVIDIA/nouveau.
Pour les firmwares NVidia j'étais pas au courant. Les gens qui ont un GPU NVidia doivent installer un firmware proprio en plus du driver ?
Non, on reverse et on ré-écrit la plupart de nos microcodes (exception faite de ceux pour le décodage vidéo car ils sont pas essentiels et personne est vraiment motivé pour l'instant).
Quand on utilise nouveau on utilise forcément le firmware libre ou c'est un projet à part ?
Oui, tu utilises des microcodes libres, ils sont écrit en dur dans le code donc tu les vois pas.
Il suffira qu'une application ne supporte pas un changement de contexte pour que l'on ne puisse pas éteindre un GPU. Cela dit, on pourra toujours lancer une appli sur le GPU de son choix.
Justement, dans quelle mesure est-ce que l'énorme code dump d'AMD permettra d'aider à la rétro-ingénierie de la gestion de l'énergie chez Nvidia ?
Si ce dump avait été fait il y a 3 ans, j'aurai pu mieux comprendre ce qu'il y avait à faire. Maintenant, c'est trop tard.
Les infrastructures sont-elles très différentes ?
Les concepts doivent être les mêmes (ce qui ressort de mes conversations avec les développeurs AMD), mais l'implémentation n'a rien à voir. Celle pour NVIDIA a l'air aussi plus difficile. Dans le cas d'AMD, le vbios contient la liste des opérations à faire pour reclocker, ce qui n'est pas DU TOUT le cas pour NVIDIA (à part un petit script pour le changement de fréquence de la mémoire).
Étendre le support à tous les GPU semble une tâche énorme et très certainement rébarbative pour un petit nombre de personnes, comment comptez-vous faire?
En général, ce n'est pas rébarbatif. Je suis presque certain que le code peut être majoritairement le même. C'est juste que certaines cartes sont plus sensibles à certaines opérations que d'autres ce qui permet d'exposer plus de problèmes sur mon code. Mais en effet, c'est beaucoup de travail.
Avez-vous mis en place une suite de test, des scénarios qui pourraient être executés par des tiers, comprendre la communauté, et qui génereraient des données, statistiques que vous pourriez exploiter? Quelle serait l'approche?
Il existe déjà un programme à exécuter pour tracer ce que fait le driver propriétaire. Cela dit, nous avons déjà assez de traces. Ce qu'il nous manque maintenant, c'est du temps et du courage. Je n'ai pas pu travailler sur le reclocking depuis plus d'un an à cause de mon travail sur ptherm et la gestion de la température en général. Mon doctorat me prend aussi pas mal de temps. Mais j'espère m'y remettre très bientôt.
La raison pour laquelle je publie autant est que je suis actuellement en déplacement pour plusieurs mois et donc, je suis loin de mes ordinateurs et cartes graphiques. Je peux donc que travailler sur ce genre de choses. Cela dit, ça fait longtemps que j'aurai du le faire!
il y à quelques mois il nous avait donné le plaisir d'assister à une conférence vidéo sur ces recherches qui permettait d'avoir un premier aperçu fort intéressant.
Par contre, je ne le retrouves pas……. Peut être qu'une bonne âme pourra reposter le lien du journal, ou peut être feras tu une recherche fructueuse.
La retro-ingienerie, pour moi, ca ressemble a de la magie noire tellement que ca a l'air complexe. J'aimerai bien comprendre la demarche, peut etre qu'un article vulgarisateur pour aider, si tu n'es pas contre.
Hmm, on a des projets de documentation sur certains outils qu'on utilise pour faire de la rétro-ingénierie, mais y'a pas vraiment de recette magique. En général, ce qu'il faut c'est en premier pouvoir analyser les résultats de ce que tu veux reverser. Ensuite, tu peux potentiellement avoir besoin d'un outil pour tracer ce que fait le driver officiel. Et finalement, il te faut des outils pour modifier les contenus dans les registres et analyser l'impact sur ce que tu recherches. Ensuite, tu dois répéter ad nauseam!
Au passage, j'aimerai mettre en lumiere un autre projet qu'il mene, un IDE Arduido, arduide, en C++/Qt qui a sous le capot un debuggeur et qui est agreable a utiliser ! :)
Ce projet est un peu à l'abandon mais j'y pense toujours oui. Je dois le porter à la version beta du sdk qui va enfin me permettre de virer les tonnes d'options par défaut nécessaires pour compiler un projet. Cool.
Et ça ne serait pas possible de changer de pilote à chaud avec Wayland (comme ce qui est fait sous Windows >= Vista)?
Ça devrait être possible oui. Le compositeur sera normalement capable de supporter ça. Mais les applications qui utilisaient le GPU devront être tuées méchamment à moins qu'elle supporte l'extension à OpenGL appelée Robustness. Cette extension indique à une application graphique qu'elle doit ré-ouvrir le device (ou un autre device) et re-uploader son contexte. J'en sais pas beaucoup plus.
Impossible sans reboot de X. Ça sera potentiellement possible avec Wayland. C'est clairement pas notre priorité et ça n'a rien à voir avec Nouveau. Cependant, ça serait bien sympa d'avoir ça, en effet!
Bref, ça avance dans le bon sens, continuez comme ça (et si nouveau pouvait être compatible avec vdpau, ça serait super!)
Hmm, VDPAU marche déjà plus ou moins si tu sais extraire les firmwares vidéos. Je dis plus ou moins car j'ai jamais testé. Mais les gens s'en plaignent pas en général.
On a pas vraiment fait de la pub mais c'est là. On va essayer de rendre l'extraction des firmwares plus simple pour tout le monde, comme proposé pour VP2. Ça pourrait ensuite être automatisé par les distros. L'écriture des firmwares vidéos en open source est une tache immense, donc faut être motivé mais on accepte les volontaires ;)
[^] # Re: Licence ? Devil's in the deails ?
Posté par Martin Peres (site web personnel) . En réponse au journal Effort d'ouverture de la part de Nvidia. Évalué à 10.
Non, la raison pour laquelle ils font ça, c'est car bientôt, les microcodes devront être signés par NVIDIA. Alors on pourra tjs essayer d'écrire le notre et le faire signer (comment on le teste en attendant?), mais ça serait bien plus simple si on pouvait utiliser ceux d'NVIDIA. La raison pour laquelle NVIDIA fait ça, c'est pour augmenter la sécurité. Actuellement, les microcodes ont souvent la possibilité d'accéder à la mémoire centrale, sans contrôle. C'est pas acceptable! Du coup, la seule solution quand c'est nécessaire, c'est de faire confiance au code. Mais si n'importe qui peut remplacer les firmwares, c'est impossible de faire confiance.
On a donc les problèmes suivants:
[^] # Re: drivers graphiques
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. Évalué à 4.
Oh, j'avais zappé que tu avais marqué "compositeur software". Forcement que la conso augmente!
Tu sais que enlightenment supporte aussi la composition opengl? Pourquoi tu actives la composition software?
[^] # Re: drivers graphiques
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. Évalué à 4.
Quand j'ai regardé, j'utilisais linux 3.10 / mesa 9.1 et KDE/kwin. Je suis sur Arch.
[^] # Re: drivers graphiques
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. Évalué à 4.
Hmm, bizarre, c'est exactement le même matériel que toi et mes résultats sont presque inverses, même en idle.
[^] # Re: drivers graphiques
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. Évalué à 6.
C'est étonnant et contraire à mon expérience. Mais c'est possible que si très peu de choses sont modifiées à l'écran, le CPU peut être plus efficace. C'est quelque chose que je le driver devrait prendre en compte!
Tu utilises quoi comme pilote?
[^] # Re: Beaucoup de boulot
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Linux pour Workgroups 3.11, le noyau prêt pour le bureau. Évalué à 4.
Et ça suffira que si tu veux accélérer le décodage mpeg1/2. Pour h264, ça marche pas encore et le dev sait pas encore pourquoi. Il devrait s'y re-pencher assez rapidement.
[^] # Re: Parfait. Les questions comme les réponses.
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. Évalué à 10.
La compilation est faite par le driver, c'est caché pour le développeur d'applications. C'est la même chose pour les shaders en opengl.
[^] # Re: Parfait. Les questions comme les réponses.
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. Évalué à 5.
Oui, les microcodes sont nécessaires. C'est une bonne chose qu'il y ait des microcodes, mais par contre faudrait qu'ils soient libres. D'où le besoin de reverse engineering!
[^] # Re: drivers graphiques
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. Évalué à 10. Dernière modification le 01 septembre 2013 à 02:20.
Oui car toutes les opérations nécessaires pour allouer un contexte graphique et gérer des buffers graphique a été standardisé, c'est EGL. Avec ça, les applications peuvent utiliser le GPU pour faire du rendu (via OpenGL/VG ou toute autre API) et partager ses buffers graphiques avec un compositeur wayland.
C'est implémenté dans mesa pour intel, radeon et nouveau.
Cela dit, y'a plein de façon de communiquer avec un compositeur wayland, celle là est simplement la plus optimale (tout sur le GPU).
[^] # Re: Parfait. Les questions comme les réponses.
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. Évalué à 10.
Pfff, comme si ils avaient le choix … à moins que tu acceptes de perdre toute accélération graphique! Les avocats d'AMD doivent empêcher la libération pour une bonne raison. La seule solution acceptable est donc la rétro-ingénierie. C'est trop facile de rester dans son fauteuil et dire qu'une entreprise est pas assez libre…
Simplement parce que le standard est sur l'interface, pas sur l'implémentation. Dois-je te rappeler que chaque chipset a sa façon de travailler, son langage? Oui on peut factoriser du code (Gallium), mais au final, les implémentations vont forcement différer à un moment. Tu as vision trop logicielle du problème, on parle de compilateur et de driver là.
[^] # Re: Et la couche graphique d'Android? (SurfaceFlinger/SurfaceTexture/GraphicBuffer)
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. Évalué à 1.
Oui, mais je sens venir la tonne d'utilisateurs pas content qui ne comprendront pas pourquoi utiliser le module nvidia avec xf86-video-nouveau ne marche pas! Cela dit, j'attend quand même ça avec impatience!
[^] # Re: comment faire ?
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. Évalué à 8.
Exact.
Pas de décodage vidéo sans microcodes sur les cartes modernes, en effet. Seul le redimensionnement et quelques effets de lissage sont gérés (via XV) dans ce cas.
Si tu veux en savoir plus, j'ai mieux expliqué la situation dans la dépêche "Linux pour Workgroups 3.11" qui devrait paraître à la fin de la semaine, à la sortie de Linux 3.11.
[^] # Re: comment faire ?
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. Évalué à 10.
Tu sais, ça fait autant chier les devs AMD que toi cette situation. Franchement, AMD fait un boulot excellent. Reverser un micro code, c'est long et laborieux mais ça n'a aucune mesure avec le développement d'un driver complet. Si cette situation te gène, considère ça comme un bon moyen de commencer à bosser sur ce projet.
Tu dois parler du VBIOS. Non, ce bios n'est pas libre non plus. Il est inclu par le fabriquant du matériel dans la carte à sa fabrication. Pareil pour NVIDIA/nouveau.
Non, on reverse et on ré-écrit la plupart de nos microcodes (exception faite de ceux pour le décodage vidéo car ils sont pas essentiels et personne est vraiment motivé pour l'instant).
Oui, tu utilises des microcodes libres, ils sont écrit en dur dans le code donc tu les vois pas.
[^] # Re: comment faire ?
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. Évalué à 10.
J'allais le dire :D https://reblog.0x04.net/
[^] # Re: question de n00B
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Entretien avec Paul Kocialkowski, développeur Replicant. Évalué à 4.
Le N9 utilise une base debian et ça marche bien :)
[^] # Re: Changement de pilote
Posté par Martin Peres (site web personnel) . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 10.
Exactement. Voilà l'extension qui devra être utilisée par les applications: https://www.opengl.org/registry/specs/ARB/robustness.txt
Il suffira qu'une application ne supporte pas un changement de contexte pour que l'on ne puisse pas éteindre un GPU. Cela dit, on pourra toujours lancer une appli sur le GPU de son choix.
[^] # Re: Contribution d'AMD
Posté par Martin Peres (site web personnel) . En réponse au journal Rétro-ingénierie de la gestion d'énergie sur les cartes graphiques NVIDIA. Évalué à 7.
Si ce dump avait été fait il y a 3 ans, j'aurai pu mieux comprendre ce qu'il y avait à faire. Maintenant, c'est trop tard.
Les concepts doivent être les mêmes (ce qui ressort de mes conversations avec les développeurs AMD), mais l'implémentation n'a rien à voir. Celle pour NVIDIA a l'air aussi plus difficile. Dans le cas d'AMD, le vbios contient la liste des opérations à faire pour reclocker, ce qui n'est pas DU TOUT le cas pour NVIDIA (à part un petit script pour le changement de fréquence de la mémoire).
[^] # Re: Youpi !
Posté par Martin Peres (site web personnel) . En réponse au journal Rétro-ingénierie de la gestion d'énergie sur les cartes graphiques NVIDIA. Évalué à 2.
En général, ce n'est pas rébarbatif. Je suis presque certain que le code peut être majoritairement le même. C'est juste que certaines cartes sont plus sensibles à certaines opérations que d'autres ce qui permet d'exposer plus de problèmes sur mon code. Mais en effet, c'est beaucoup de travail.
Il existe déjà un programme à exécuter pour tracer ce que fait le driver propriétaire. Cela dit, nous avons déjà assez de traces. Ce qu'il nous manque maintenant, c'est du temps et du courage. Je n'ai pas pu travailler sur le reclocking depuis plus d'un an à cause de mon travail sur ptherm et la gestion de la température en général. Mon doctorat me prend aussi pas mal de temps. Mais j'espère m'y remettre très bientôt.
La raison pour laquelle je publie autant est que je suis actuellement en déplacement pour plusieurs mois et donc, je suis loin de mes ordinateurs et cartes graphiques. Je peux donc que travailler sur ce genre de choses. Cela dit, ça fait longtemps que j'aurai du le faire!
[^] # Re: Youpi !
Posté par Martin Peres (site web personnel) . En réponse au journal Rétro-ingénierie de la gestion d'énergie sur les cartes graphiques NVIDIA. Évalué à 4.
Je suppose que tu as assisté à une de ces conférences:
- Introduction to GPUs and to the Linux Graphics Stack
- A Deeper Look Into GPUs and the Linux Graphics Stack
Ah ah, merci. Ma prochaine conférence prévue est à l'XDC2013 à Portland. Je serai probablement aussi à la FOSDEM 2014 à Bruxelles. On verra ensuite.
[^] # Re: Youpi !
Posté par Martin Peres (site web personnel) . En réponse au journal Rétro-ingénierie de la gestion d'énergie sur les cartes graphiques NVIDIA. Évalué à 2.
De rien, on s'amuse comme on peut ;)
Hmm, on a des projets de documentation sur certains outils qu'on utilise pour faire de la rétro-ingénierie, mais y'a pas vraiment de recette magique. En général, ce qu'il faut c'est en premier pouvoir analyser les résultats de ce que tu veux reverser. Ensuite, tu peux potentiellement avoir besoin d'un outil pour tracer ce que fait le driver officiel. Et finalement, il te faut des outils pour modifier les contenus dans les registres et analyser l'impact sur ce que tu recherches. Ensuite, tu dois répéter ad nauseam!
Ce projet est un peu à l'abandon mais j'y pense toujours oui. Je dois le porter à la version beta du sdk qui va enfin me permettre de virer les tonnes d'options par défaut nécessaires pour compiler un projet. Cool.
[^] # Re: Que du bon
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Le noyau Linux 3.10 est sorti. Évalué à 4.
Ça devrait être possible oui. Le compositeur sera normalement capable de supporter ça. Mais les applications qui utilisaient le GPU devront être tuées méchamment à moins qu'elle supporte l'extension à OpenGL appelée Robustness. Cette extension indique à une application graphique qu'elle doit ré-ouvrir le device (ou un autre device) et re-uploader son contexte. J'en sais pas beaucoup plus.
[^] # Re: Que du bon
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Le noyau Linux 3.10 est sorti. Évalué à 4.
Impossible sans reboot de X. Ça sera potentiellement possible avec Wayland. C'est clairement pas notre priorité et ça n'a rien à voir avec Nouveau. Cependant, ça serait bien sympa d'avoir ça, en effet!
[^] # Re: Que du bon
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Le noyau Linux 3.10 est sorti. Évalué à 4.
Hmm, VDPAU marche déjà plus ou moins si tu sais extraire les firmwares vidéos. Je dis plus ou moins car j'ai jamais testé. Mais les gens s'en plaignent pas en général.
Pour Fermi/Kepler: http://nouveau.freedesktop.org/wiki/NVC0_Firmware/
Pour les NV50: http://nouveau.freedesktop.org/wiki/VP2/
On a pas vraiment fait de la pub mais c'est là. On va essayer de rendre l'extraction des firmwares plus simple pour tout le monde, comme proposé pour VP2. Ça pourrait ensuite être automatisé par les distros. L'écriture des firmwares vidéos en open source est une tache immense, donc faut être motivé mais on accepte les volontaires ;)
[^] # Re: Que du bon
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Le noyau Linux 3.10 est sorti. Évalué à 2.
Ah ah! J'avais bien compris, ne t'en fais pas! :D
[^] # Re: Que du bon
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Le noyau Linux 3.10 est sorti. Évalué à 2.
Yep, je peux totalement comprendre! On y travaille :s