1. Pour les threads, la compatibilite etant toujours assure via la norme posix thread le probleme ne se pose meme pas (xfree ne fait pas dans les internes des implementations).
Tout a fait vrai pour les applis (en theorie hein, on va pas parler des exceptions type wine), par contre completement faux pour le hardware, surtout dans si le noyau preemptif devient le standard. La gestion de thread dans une application OpenGL acceleree qui est par exemple multifenetres (donc plusieurs fenetres accelerees), risque de changer pas mal. En fait le probleme n'est pas XFree en lui meme mais plutot les differents drivers. Cote XFree c'est les drivers GLX et DRI qui m'inquietent un peu. Mais d'un autre cote c'est aussi les drivers qui font la force d'XFree. L'initialisation et la relache du mode DRI sont aussi loin d'etre evident, et une fois de plus comme on jongle avec du hardware d'un cote, c'est pas evident de changer.
Pour faire simple si une ancienne application demande a creer des threads ancien format le wrapper fait son office et tout va bien. Par contre si une nouvelle application demande a creer des threads nouveaux formats avec des fonctions qui font appel a un driver ancien format, la je ne sais pas trop ce qui se passe et comme c'est XFree qui fait tampon ...
2. Pour le noyau, les besoins en APIs de Xfree/DRI/AGP* sont assez minimaux: du genre allocations de DMA, communications PCI, ... donc la aussi la question de l'evolution ne se pose meme pas.
Oui si on part du principe que des fonctions de type transparences hard, T&L, shaders, couleur en flottant et j'en passe ne sont pas interressantes ou doivent etre integralement releguees a X. Perso j'aime bien l'idee de pouvoir me servir de la puissance de calcul de ma CG sans pour autant avoir une session XFree ouverte(il y a un paquet de clusters Maya qui partagent mon opinion).
3. Pour l'openGL, tout le probleme vient du fait que l'API a tres mal vieillit pas rapport, par exemple, aux evolutions de D3D. Pour gerer ce qu'entrevoit les premiers drafts de l'openGL2.0 il faudra pas mal de modifs mais ca ne sera pas en gardant l'ancien principe de developpement de Xfree86 que ca sera possible.
Ah non, OpenGL ca veillit super bien. Le seul truc est de savoir pourquoi ca a ete fait au depart. OpenGL a ete pense comme un generateur d'etats, et n'a pas du tout ete oriente temps reel a la base. Dire que OpenGL a du retard sur D3D c'est comme de dire qu'Acrobat writter est encore loin derriere Word. C'est vrai qu'Acrobat writter comme traitement de texte c'est assez leger. Mais c'est pas fait pour ca.
De plus l'architecture extremement souple d'OpenGL lui permet souvent d'etre au contraire plutot en avance sur D3D d'un point d evue global meme si l'ARB a plutot du retard, je suis bien d'accord.
Le seul probleme avec OpenGL 2.0 c'est surtout qu'on ne sait pas ce qui va etre utilise et/ou implemente. Avant la gueulante de Carmac il ne serait venu a l'idee d'aucun fabriquant de CG de faire des couleurs en flottant. De meme la fonction Render to Render (permet de refaire passer une image completement a travers le pipeline) n'a jamais ete utilisee, ou implementee, ca rend justement la mise en place de Mesa comme nerf de la guerre un peu delicate a l'heure actuelle.
C'est vrai que la meilleure facon d'avoir un systeme propre, rapide, modulaire et avec autant de "bonbon pour les yeux" que l'on veut est de passer par OpenGL. Mais en ce moment ca me parait un peu casse-gueule.
[^] # Re: Vous etes sur que c'est le bon moment ?
Posté par Jerome Herman . En réponse à la dépêche Fork d'XFree86. Évalué à 4.
Tout a fait vrai pour les applis (en theorie hein, on va pas parler des exceptions type wine), par contre completement faux pour le hardware, surtout dans si le noyau preemptif devient le standard. La gestion de thread dans une application OpenGL acceleree qui est par exemple multifenetres (donc plusieurs fenetres accelerees), risque de changer pas mal. En fait le probleme n'est pas XFree en lui meme mais plutot les differents drivers. Cote XFree c'est les drivers GLX et DRI qui m'inquietent un peu. Mais d'un autre cote c'est aussi les drivers qui font la force d'XFree. L'initialisation et la relache du mode DRI sont aussi loin d'etre evident, et une fois de plus comme on jongle avec du hardware d'un cote, c'est pas evident de changer.
Pour faire simple si une ancienne application demande a creer des threads ancien format le wrapper fait son office et tout va bien. Par contre si une nouvelle application demande a creer des threads nouveaux formats avec des fonctions qui font appel a un driver ancien format, la je ne sais pas trop ce qui se passe et comme c'est XFree qui fait tampon ...
2. Pour le noyau, les besoins en APIs de Xfree/DRI/AGP* sont assez minimaux: du genre allocations de DMA, communications PCI, ... donc la aussi la question de l'evolution ne se pose meme pas.
Oui si on part du principe que des fonctions de type transparences hard, T&L, shaders, couleur en flottant et j'en passe ne sont pas interressantes ou doivent etre integralement releguees a X. Perso j'aime bien l'idee de pouvoir me servir de la puissance de calcul de ma CG sans pour autant avoir une session XFree ouverte(il y a un paquet de clusters Maya qui partagent mon opinion).
3. Pour l'openGL, tout le probleme vient du fait que l'API a tres mal vieillit pas rapport, par exemple, aux evolutions de D3D. Pour gerer ce qu'entrevoit les premiers drafts de l'openGL2.0 il faudra pas mal de modifs mais ca ne sera pas en gardant l'ancien principe de developpement de Xfree86 que ca sera possible.
Ah non, OpenGL ca veillit super bien. Le seul truc est de savoir pourquoi ca a ete fait au depart. OpenGL a ete pense comme un generateur d'etats, et n'a pas du tout ete oriente temps reel a la base. Dire que OpenGL a du retard sur D3D c'est comme de dire qu'Acrobat writter est encore loin derriere Word. C'est vrai qu'Acrobat writter comme traitement de texte c'est assez leger. Mais c'est pas fait pour ca.
De plus l'architecture extremement souple d'OpenGL lui permet souvent d'etre au contraire plutot en avance sur D3D d'un point d evue global meme si l'ARB a plutot du retard, je suis bien d'accord.
Le seul probleme avec OpenGL 2.0 c'est surtout qu'on ne sait pas ce qui va etre utilise et/ou implemente. Avant la gueulante de Carmac il ne serait venu a l'idee d'aucun fabriquant de CG de faire des couleurs en flottant. De meme la fonction Render to Render (permet de refaire passer une image completement a travers le pipeline) n'a jamais ete utilisee, ou implementee, ca rend justement la mise en place de Mesa comme nerf de la guerre un peu delicate a l'heure actuelle.
C'est vrai que la meilleure facon d'avoir un systeme propre, rapide, modulaire et avec autant de "bonbon pour les yeux" que l'on veut est de passer par OpenGL. Mais en ce moment ca me parait un peu casse-gueule.
Kha