0
Ca se passe presque de commentaire....Today Novell announced the release of Xgl and Compiz, the new window manager/composition manager to go with it.
http://tirania.org/blog/archive/2006/Feb-07-1.html
> Lire le journal (45 commentaires, moyenne: 2).
Vous avez demandé le commentaire #679257.
Run by 
Cette page a été générée par Templeet en 0.1129s (dont 0.0245 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Flashy mais...
... est-ce les APIs pour accèder aux services opengl des GPU modernes seront proprement "normalisées"?
Bon, j'avoue ne pas avoir regardé dans le code source pour voir comment ça marche mais il faut faire attention à la manière d'exposer la puissance des GPU modernes aux applications graphiques.
De ce que j'ai compris, il semble que la vrai "normalisation" soit liée à OpenGL ES et EGL (remplacement de GLU et GLX et cela explique Xegl).
Prenons un cas concret: je suis dèveloppeur d'une application graphique, j'utilise gtk/cairo pour dessiner et je voudrais faire des effets en programmant les shaders de mon GPU sur un widget particulier. Quelle API je vais utiliser?
De tout ça, je pense ne pas trop m'avancer en prédisant une complexification significative des drivers des GPUs. Une ouverture du code de ces drivers serait plus qu'utile pour aider à leur stabilisation.
[^]Re: Flashy mais...
De tout ça, je pense ne pas trop m'avancer en prédisant une complexification significative des drivers des GPUs. Une ouverture du code de ces drivers serait plus qu'utile pour aider à leur stabilisation.
Ca c'est l'idéal. En étant plus pragmatique et plus réaliste, je penses qu'un changement important va effectivement aider à stabiliser et standardiser les APIs des cartes graphiques... ce n'est pas le code source des dits drivers, mais... DirectX. En effet le prochain DirectX de Windows Vista ne proposera plus d'accéder directement aux spécificités du matériel, c'est tout le monde à la même enseigne.
"L’idée principale de DirectX 10 est l’uniformisation du matériel. L’idéal serait à terme de faire disparaître la notion de CAPS qui, sur les versions actuelles de DirectX, permet d’interroger les cartes pour en connaître leurs possibilités. Les capacités graphiques deviendraient identiques quelque que soit la marque de la carte graphique et la différence se ferait donc uniquement sur les performances."
MonoFrance
[^]Re: Flashy mais...
J'oubliais ma source :
http://www.pcinpact.com/articles/a/172/0.htm?pge=8
(dossier fort intéressant à lire au passage)
MonoFrance
[^]Re: Flashy mais...
L'dée principale de DirectX 10 est l'uniformisation du matériel. L'idéal serait à terme de faire disparaître la notion de CAPS qui, sur les versions actuelles de DirectX, permet d'interroger les cartes pour en connaître leurs possibilités. Les capacités graphiques deviendraient identiques quelque que soit la marque de la carte graphique et la différence se ferait donc uniquement sur les performances.
OpenGL fait ça depuis le début, modulo la gestion des extensions. Il suffit de se rappeler ce qu'a été l'introduction du 'Texture and lighting' dans les 2 API. Dans OpenGL, tous les progs l'ont utilisés sans le savoir, dans DirectX, il fallait interroger les CAPS du matériel pour savoir si c'était disponible, pour les utiliser. C'est quand même le but d'une API que de masquer les différences entre les matériels.
Programmeur Linux, Atari
Developpement, jeux
[^]Re: Flashy mais...
OpenGL fait ça depuis le début, modulo la gestion des extensions.
Tout est dans le modulo :) Une couche d'abstraction fait entièrement abstraction ou n'en est pas une. DirectX le faisait en parti aussi si tu veux. Peut êtes pas aussi bien que OpenGL mais faisait aussi de l'abstraction. Cela dit il y avait toujours une porte dérobée, que ce soit en OpenGL ou DirectX pour exploiter spécifiquement tel ou tel matos, bref la course aux fonctionnalités non standardisées. DirectX 10 se propose d'être une vraie couche d'abstraction (en tout cas sur le papier), d'où tout l'intérêt.
MonoFrance
[+] [^]Re: Flashy mais...
t'attend quoi pour implementer ca sous linux si cela est si beau que ca???
[+] [^]Re: Flashy mais...
j'oubliais en utilisant mono naturellement
[^]Re: Flashy mais...
ben dis donc ca manque d'humour enfin bon ...
[^]Re: Flashy mais...
Y'a humour et humour, visiblement l'humour sarcastique répétitif et sans rapport avec la choucroute n'est pas vu comme pertinent :)
MonoFrance
[^]Re: Flashy mais...
parceque parler de directx dans une news sur XGL c'est plus pertinent????
[^]Re: Flashy mais...
Ben oui, un personne disait que ca serait bien que les API des cartes graphiques soient standardisés, parcque justement avec XGL ca va pas marcher chez tout le monde. Moi j'ai précisé qu'on avait de forte chance de voir les APIs des cartes graphiques se stabiliser avec le prochain DirectX. Et forcé de constater que MS et DirectX ont beaucoup plus d'impact sur nVidia et Ati que l'OpenGL ou même Novell avec XGL. Bref, je pense que DirectX profitera aussi à nous linuxien de manière indirect.
MonoFrance
[^]Re: Flashy mais...
MS et DirectX ont beaucoup plus d'impact sur nVidia et Ati
Ah bon ? et tu tiens cette information de qui ? quoi ? quel article ?
All those moments will be lost in time, like tears in the rain.
[+] [^]Re: Flashy mais...
Toi t'es un gros malin.
J'emploi impact dans le sens d'une "influence". Par définition l'influence est un phénomène intellectuel et moral que chacun est à même d'apprécier à sa façon. Je te laisse donc toi même te documenter sur les "faits", sur l'importance des relations entre ATI/nVidia et MS, pour en juger toi même.
MonoFrance
[^]Re: Flashy mais...
directX va profiter a une plateforme sur lequels il n'existe pas???? Tu rigoles???? A moins de faire comme j'ai dit plus haut (et donc mon commentaire etait pas inutile pour le premier en tout cas quoique meme le second si directX est implemente en C# dans le futur).
Mais bon je vois comment directX serait profitable a linux tant qu'il existera pas dessus et je vois pas trop l'avantage de rajouter une couche completement dependante d'un concurrent quand au spec et donc sans aucun pouvoir pour influencer tel ou tel choix...
[^]Re: Flashy mais...
Et qu'est-ce qui empèchera un constructeur de rajouter des api perso en sus de directx ? parce que bon, si nvidia/ati et consort sorte une carte avec une fonctionnalité non prise en charge dans le directx courant, ben pour l'utiliser il faudra bien passer par une extension constructeur...
Et je ne pense pas que les dev se priveront d'utiliser une extension constructeur (comme il ne s'en prive pas actuellement), donc à part par un moyen inconnu microsoft enmpêche de créer une extension quelconque (voir lib à part qui gère ça), je vois mal comment les "extensions" disparaîtront.
All those moments will be lost in time, like tears in the rain.
[^]Re: Flashy mais...
Et qu'est-ce qui empèchera un constructeur de rajouter des api perso en sus de directx ?
Des pilotes signés numériquement par Microsoft par exemple.
MonoFrance
[^]Re: Flashy mais...
Et ouais et tu crois qu'ils vont pas signer un driver de monsieur nvidia car monsieur nvidia a rajouté une dll pour accéder a des fonctionnalités non prises en charge par directx ? je crois que tu rêves.
All those moments will be lost in time, like tears in the rain.
[^]Re: Flashy mais...
Bon je vais sureemnt sortir une connerie (qui a dit comme d'habitude?), mais l'émulation logiciel Mesa n'est pas "partiellement utilisable"?
Traduction:
Pour les vieilles cartes qui supportent que opengl 1.2 et pas 2.0, c'est pas possible de combler les lacunes en utilisant la libMesa pour ce que la carte sait pas faire? (au prix de performances desastreuses mais bon c'est mieux que rien)
(Maintenant que j'y penses, Mesa c'est pas seulement opengl 1.2?)
[^]Re: Flashy mais...
Maintenant que j'y penses, Mesa c'est pas seulement opengl 1.2?
Mesa 6.x supporte OpenGL 1.5:
http://www.mesa3d.org/RELNOTES-6.0
http://www.mesa3d.org/VERSIONS
Evidemment, pour tout ce qui est pixel/vertex shader/program/choucroute, ca passe par des extensions (GL_ARB_vertex_program, GL_ARB_vertex_shader) jusqu'à intégration dans le core pour la prochaine version. Par contre, pour ce qui est du support matériel de ceux-ci dans Mesa, cela dépend du driver.
Programmeur Linux, Atari
Developpement, jeux
[^]Re: Flashy mais...
Prenons un cas concret: je suis dèveloppeur d'une application graphique, j'utilise gtk/cairo pour dessiner et je voudrais faire des effets en programmant les shaders de mon GPU sur un widget particulier. Quelle API je vais utiliser?
GLSL( http://www.opengl.org/documentation/oglsl.html ) est pas l'API standard pour faire ce genre de truc normallement ?
[^]Re: Flashy mais...
Cette norme de shaders fait partie d'OpenGL 2.0. Mais ce n'est pas là où je voulais en venir. Je suis développeur d'une application graphique, j'utilise gtk/cairo pour dessiner mon application: à partir de gtk/cairo, comment je fais pour récupérer un "context" ou je ne sais quoi pour pouvoir programmer les shaders ou autre chose de mon GPU "à la opengl" sur un widget?
[^]Re: Flashy mais...
A mon avis ca va être difficilement possible parce que dans ce cas ton application va dépendre de OpenGL... hors gtk/cairo ne dépendent pas de OpenGL et heureusement d'ailleurs. Alors peut être un jour il y aura moyen de rajouter des effets ( optionnels ) OpenGL mais pas dans l'immédiat. XGL n'est qu'un serveur X !
[^]Re: Flashy mais...
Toute la difficulté est là. Il faut pouvoir exposer de manière plus ou moins standard la puissance des GPUs modernes à ces applications. Il faudrait une extension de cairo ou GTK qui nous permette de récupérer ce "contexte" bas niveau, ici un truc à la OpenGL ou EGL, ou je sais quoi encore.
Perso, je pense que c'est une évolution naturelle du desktop et je ne pense pas qu'on puisse parler de véritable innovation. En tout cas c'est bien que Nat F. ait donné un coup de projo sur le sujet, maintenant que les gars de X.org ont finit le refactoring modulaire, ils vont surement avoir plus de temps à consacrer à cet épineux défi.
D'ailleurs, je me demande bien quelles API les demos de Nat F. utilisent: uniquement des extensions de X11 ou des trucs batards? Pour faire ce que fait son window manager, il doit utiliser OpenGL comme API racine. Est-ce que quelqu'un est rentré dans son code pour voir? (j'ai la flemme).
[^]Re: Flashy mais...
alors tu utilises une surface glitz avec cairo
[^]Re: Flashy mais...
J'ai jeté un oeil sur glitz, donc on peut effectivement constuire une surface cairo à partir d'une surface glitz. Mais je ne vois pas à quel moment de la contruction de la surface glitz je peux récupérer un objet me permettant d'accéder directement à l'API opengl pour cette surface. Il semblerait que glitz offre la semantique de l'extension X11 render, mais ne permettent pas d'accéder à la couche inférieure (GLX, EGL, AGL, PIXMAN etc...) pour les applications qui le désirent.