ATI ? AMD, tu veux dire ? Ca, je n'en sais rien... j'évite fglrx comme la peste.
... par contre, pour ce qui est des drivers libres, ils vont tous passer à la casserole, à un moment ou à un autre, en ce qui concerne Gallium3D...
Phoronix [1] fait d'ailleurs état de travaux sur un driver libre "Radeon MS" qui devrait utiliser Gallium3D ; apparemment, il implémente surtout une initialisation propre des cartes pour l'instant, et devrait fusionner avec le driver libre Radeon actuel...
Driver Radeon qui se tire la bourre (façon de parler) avec RadeonHD (celui dont les progrès sont relatés dans le journal), en ce moment, sur l'utilisation ou non des AtomBIOS (BIOS proprios des cartes, servant de couche d'abstraction pour éviter de taper directement dans les registres du GPU... pour info, AMD vient de lâcher les dernières versions, apparemment librement redistribuables, à la communauté... reste que l'entièreté des AtomBIOS ne sera sans doute pas documentée, notamment les parties aidant au décodage matériel des codecs "type HD", puisqu'apparemment matériellement trop liés à la gestion des drm)...
- Radeon veut utiliser AtomBIOS (et le fait) ;
- RadeonHD veut utiliser les registres et (presque) pas AtomBIOS (et le fait) ;
- AMD veut que le driver libre utilise AtomBIOS (et semble faire pression sur les gars de RadeonHD pour qu'ils l'utilisent) ;
... du coup, c'est un peu le bordel... il semble que RadeonHD ait un support plus propre des R500/R600, pour l'heure, mais l'implémentation est plus lente, puisqu'ils n'utilisent pas trop AtomBIOS en guise de framework, mais tapent plutôt dans les registres à l'ancienne...
Radeon se met cela dit à supporter les R500 et R600 (a priori à partir des versions 6.8.x du driver), et pourrait, grâce à AtomBIOS, implémenter le support de nouvelles cartes plus rapidement que RadeonHD...
De toute façon, pour l'heure, l'essentiel des efforts semblent se concentrer sur le support de toute la gamme en 2D/3D via l'actuel DRI, afin de ne pas laisser des possesseurs de GPU ATI/AMD sur le carreau (enfin, avec fglrx ou vesa, mais pour ce que ça change)... et Gallium3D de partout est encore lointain...
Perso, ce qui m'intéresserait le plus serait de voir revenir le support du multi-GPU avec randr1.3 dans xserver 1.5 (soit X.org 7.4)... avec mes X800XL en tri-écran, le plus simple est encore de se limiter à X.org 7.2 et le vieux driver radeon sans randr 1.2 (et pas d'accélération... mais au moins, ça marche bien en 2D et avec Xv)... et ça risque d'arriver plus tôt que Gallium3D (que ses propres développeurs qualifiaient il y a moins d'un mois de "plus ou moins au stade alpha" [1, cf première page])...
Bref, ça bouge, dans le clickodrome... il y a plein de bonnes choses à venir (notamment, l'implémentation de nouveaux codecs dans XvMC par Intel, et même le futur remplaçant de XvMC, toujours par Intel, à savoir VA-API), on a presque la doc des 2/3 des fabricants (AMD en lâche beaucoup, ces temps-ci), ... il ne reste plus qu'à attendre (pour les pauvres mortels comme moi, qui ne peuvent que baver devant l'évolution, voire tout au plus bugreporter) ou à contribuer (pour les fous furieux à qui l'on doit toutes ces jolies couleurs)...
... après la longue période de modularisation, qui dut suivre l'enracinement chronique pre-X.org, chez XFree86, qui s'en plaindra ?
[^] # Re: Bof
Posté par Aefron . En réponse au journal Accélération 3D ATI : Ça débute !. Évalué à 10.
... par contre, pour ce qui est des drivers libres, ils vont tous passer à la casserole, à un moment ou à un autre, en ce qui concerne Gallium3D...
Phoronix [1] fait d'ailleurs état de travaux sur un driver libre "Radeon MS" qui devrait utiliser Gallium3D ; apparemment, il implémente surtout une initialisation propre des cartes pour l'instant, et devrait fusionner avec le driver libre Radeon actuel...
Driver Radeon qui se tire la bourre (façon de parler) avec RadeonHD (celui dont les progrès sont relatés dans le journal), en ce moment, sur l'utilisation ou non des AtomBIOS (BIOS proprios des cartes, servant de couche d'abstraction pour éviter de taper directement dans les registres du GPU... pour info, AMD vient de lâcher les dernières versions, apparemment librement redistribuables, à la communauté... reste que l'entièreté des AtomBIOS ne sera sans doute pas documentée, notamment les parties aidant au décodage matériel des codecs "type HD", puisqu'apparemment matériellement trop liés à la gestion des drm)...
- Radeon veut utiliser AtomBIOS (et le fait) ;
- RadeonHD veut utiliser les registres et (presque) pas AtomBIOS (et le fait) ;
- AMD veut que le driver libre utilise AtomBIOS (et semble faire pression sur les gars de RadeonHD pour qu'ils l'utilisent) ;
... du coup, c'est un peu le bordel... il semble que RadeonHD ait un support plus propre des R500/R600, pour l'heure, mais l'implémentation est plus lente, puisqu'ils n'utilisent pas trop AtomBIOS en guise de framework, mais tapent plutôt dans les registres à l'ancienne...
Radeon se met cela dit à supporter les R500 et R600 (a priori à partir des versions 6.8.x du driver), et pourrait, grâce à AtomBIOS, implémenter le support de nouvelles cartes plus rapidement que RadeonHD...
De toute façon, pour l'heure, l'essentiel des efforts semblent se concentrer sur le support de toute la gamme en 2D/3D via l'actuel DRI, afin de ne pas laisser des possesseurs de GPU ATI/AMD sur le carreau (enfin, avec fglrx ou vesa, mais pour ce que ça change)... et Gallium3D de partout est encore lointain...
Perso, ce qui m'intéresserait le plus serait de voir revenir le support du multi-GPU avec randr1.3 dans xserver 1.5 (soit X.org 7.4)... avec mes X800XL en tri-écran, le plus simple est encore de se limiter à X.org 7.2 et le vieux driver radeon sans randr 1.2 (et pas d'accélération... mais au moins, ça marche bien en 2D et avec Xv)... et ça risque d'arriver plus tôt que Gallium3D (que ses propres développeurs qualifiaient il y a moins d'un mois de "plus ou moins au stade alpha" [1, cf première page])...
Bref, ça bouge, dans le clickodrome... il y a plein de bonnes choses à venir (notamment, l'implémentation de nouveaux codecs dans XvMC par Intel, et même le futur remplaçant de XvMC, toujours par Intel, à savoir VA-API), on a presque la doc des 2/3 des fabricants (AMD en lâche beaucoup, ces temps-ci), ... il ne reste plus qu'à attendre (pour les pauvres mortels comme moi, qui ne peuvent que baver devant l'évolution, voire tout au plus bugreporter) ou à contribuer (pour les fous furieux à qui l'on doit toutes ces jolies couleurs)...
... après la longue période de modularisation, qui dut suivre l'enracinement chronique pre-X.org, chez XFree86, qui s'en plaindra ?
[1] http://www.phoronix.com/scan.php?page=article&item=galli(...)