Non ils s'entendent pas trop.
Surtout que ce sont eux qui ont pousse a ce que wine devienne GPL apres avoir vu que transgaming ne participait pas comme eux.
NdM : c'était déjà possible, c'est une mise à jour, c'est propriétaire, c'est payant, et c'est 55$ (+ le prix de MS Office).
Faux ce n'es pas propietaire: CodeWeavers Wine c la version GPL de wine mieux packagee et pre-configuree (en fonction de ce que tu veux faire, d'ou les 2-3 versions).
En fait, tout dépend de la version de D3D dont on parle. Il faut bien avouer qu'avant DX8 (ou c'était le 7), et l'arrivée du support de T&L, OpenGL était supérieur à D3D. Cependant, D3D a maintenant ratrappé, et même dépassé OpenGL 1.2.
On est bien d'accord et meme le 1.4 d'ailleurs.
La force d'OpenGL était d'être un standard fort touffu à l'époque, ce qui permet à des vieux OpenGL d'atteindre des fps très impressionnants sur nos machines actuelles (eg: Quake2, Halflife), alors que des vieux jeux D3D (4 ou 5) avec un moteur mal fait reste lents. Désolé, je n'ai pas d'exemple en tête sur ce coup, mais je suis sur que quelqu'un doit en avoir un.
C aussi vrai en OpenGL. Un moteur mal fait sera toujours mal fait que cela soit en openGL ou en DX. Maintenant vu l'archi de l'ancien D3D, c vrai que generalement un moteur mal fait D3D<7 sera encore plus mauvais actuellement.
L'intérêt était donc vraiment d'avoir une surabondance de fonctions, et de les utiliser, même si on savait que cela allait se faire en 'soft', et non en 'hard'.
Je ne suis pas sur le la "surabondance de fonction", car openGL a tjs longtemps eut pleins de fonctionnalites en plus que d3d (surtout splines, ...) qui etaient tres souvent que dispo vai le software et bcp trop souvent inutiles/inutilisables. Directx a tjs plus ou moins suivis les besoins des jeux, modeleurs 3d au fur a mesure.
Sinon il faut savoir que openGL 1.4 supporte tjs plus de fonctionnalites que
d3d via des extensions proprietaires (par exemple les textures_shaders de nvidia ou ati)
Mais bon, vu la frénésie du mondes des cartes graphiques 3D, avec chaque constructeur quiy va de ses innovations, je n'y crois pas trop.
Je ne crois pas que chaque fabricant y aille "de ses innovations". Generalement, ils offrent tjs des innovations tres similiaires qui finissent par convergee en une seule (afin d'eviter betement de decupler le boulot, ils sont pas fous). Et celles qui sont reelement une innovation specifique, si elle est pertinente elle finira par etre adoptee par les autres (par exemples compressions de textures sans pertes, programmation de shaders hardwares, ...)
Mais pour info openGL 2.0, prend la voie prise par direct3d au niveau des nouveautes et de la mise en avant rapide des nouvelles idees. Et au regard des drafts je pense que cela est bien mieux penser que ddraw/direct3d :)
Manque plus que qqu'un fasse des OpenInput,OpenNet,OpenMedia ;)
Non je compare, OpenGL 1.4 a DirectX9. (les dernieres versions des deux APIs).
Microsoft n'est pas un fabriquant de HW
Il m'avait sembler que c'etait le mieux qu'il faisait le HW ;)
Et vu les personnes qui travaillent chez eux sur dx et la xbox, t'inquiete il savent ce qu'ils font (malheureusement d'ailleurs)
je trouve dommage que ça soit eux qui choisissent comment doivent evoluer les choses.
Partiellement vrai, ils ont tjs travailler en collaboration avec les fabricants de cg pour les specs dx. Un peu comme le consortium openGL, sauf que la c microsoft qui tranche.
En fait sur tout les parties en dehors de direct3d/directdraw, il y a collaboration. Apres au niveau du coeur (ntdll, kernel32, wineserver) comme c'est principalement developper par codeweaver, transgaming n'a pas acces a la majorite des fixs (obliges de reimplementes a chaque fois).
Pour info, la partie ddraw/d3d ne sera/ne pourra etre jamais partagee car elles ne fonctionnent pas du tout pareil: transgaming simule l'archi driver/HAL de MS alors que wine officiel ne fait qu'une implementation de l'API directx. De plus juste de voir le code d3d de transgaming, j'en veut pas ;)
OpenGL ne nivelle pas par le bas les fonctionnalité HW de ta cg.
Ouh la, tu devrait en refaire un peu pour revoir.
Deja D3D ne nivelle jamais par le bas les fonctionnalites des CG, meme pousse les evolutions des cg vers l'avant (regarde d3d9 et les drafts pour d3d9+). Si ta carte ne gere pas un effet dx peut tjs le simuler de facon soft (a condition que ca soit pas trop lent pour celle-ci au quel cas le soft est desactive) ...
De l'autre cote l'openGL ne fournis de base que le strict minimum, des que tu veux faire qques chose soit tu passe par les extension ARB (quand tu fait pas encore du trop pousse), soit tu est oblige (trop souvent) de passer par des extensions proprietaires et la ca devient trop horrible (et souvent du n'importe quoi). De plus comme tu peut pas facilement savoir quelle carte est derriere tu ne peut eviter les bugs specifiques fabricants (car pas possible de desctiver/rebrancher en soft des fonctionnalites simplement)...
Donc ne sort pas les arguments pro-dx contre lui ;)
On est obligé d'utiliser WineX pour faire fonctionner WC3 à cause de DirectDraw, et pas de Direct3D.
Je pensait que s'etait surtout directplay et directinput qui servait. Et la rien n'existe sous unix pour ca (me dites pas sdl).
L'aspect positif de WineX, c'est qu'il accelere l'arrivé de drivers de cg et qu'il permet dans certains cas de se debarrasser de Windows.
Je suis pas sur la. Les drivers cg ne sont reelement arrives que qd sgi a decide de faire du linux et que les gros des effets sepciaux sont passes sous linux.
c normal car de plus en plus de la version packagee ne peut etre divulgee (NDA, brevets, ...) en clair c plus une perte de temps qu'autre chose le cvs sf pour eux.
En fait ils ont forker wine lors du passage de ce dernier en GPL/LGPL. Depuis ils ont demandes a chaque devs wine si il acceptait la double licence GPL/BSD automatique pour chacun des leurs patchs.
Donc rewind ne sert que d'integrations des patchs bi-licence de wine dans le vieux tree forke (pour pre-intergration winex) et des patchs libres de transgaming a redescendre dans wine (histoire de ne pas trop s'eloigner).
Pas mal de devs (surtout ceux de codeweavers) ont refuse d'etre dans la liste double-licence (et n'e font que des patchs GPLs), d'autres sont en status non definis.
Donc transgaming ne viole en rien la GPL mais par contre va tendre a avoir les couches basses de son "wine" divergees de plus en plus de la version officielle.
La sdl n'a meme pas la moitie des possibilites de DirectX et ca n'importe quel dev de jeux te le diras. Donc si ca peut te faire plaisir, oui on peut faire des trucs avec la sdl mais au prix de pas mal de choses a refaire (ou avoir encore pliens de libs par dessus). D'ailleurs au final elle n'a ete utilisee avec succes que pour des portages de moteur deja grandement generiques/autonomes.
Il est techniquement lamentable d'en venir a "wrapper" tous les appels aux libraries windows afin de les faire tourner sur linux. Pense au gachis de puissance processeur,...
wine(x) n'est pas un "emulateur", ou un simple "wrapper", c'est une reecriture des apis windows. Et dans le cas de directx ca se situe comme la sdl: une suite de libs par dessus x et l'opengl pour faciliter le dev d'applis multimedia. Maintenant si passer par ce que tu considere un "wrapper" je vois pas pkoi tu utilise encore la sdl, l'opengl au lieu d'essayer le code x natif.
Et je ne parle pas de la base de registres, encore consideree parfaite par son createur il n'y a pas si longtemps,
Ca je n'aime pas non plus, personne ne semble vraiment aimer et pourtant on retrouve souvent le meme principe (cf GConf, et autres confs d'applis libres). Enfin un moindre mal celle de wine est encore lisible avec un editeur texte.
Wine ne marche que sur x86.
Partiellement faux, la libwine marche sur de nombreuses plateformes. Pour la partie "runtime/linker windows" elle ne marche bien que sous x86 mais actuellement un projet en plein essort permet deja de faire tourner de simples applis sous PPC.
L'ideal pour moi est la liberalisation du code, quitte a laisser les donnees sous license proprietaire.
Je suis d'accord, mais pour ca faudrait deja que Winex (licence alladin modifiee) n'existe plus mais que seul wine reste (LGPL). Apres on n'a plus qu'a esperer.
Wine y joue un role important, je ne saurais dire de quel cote.
Actuellement c'est surement, via la libwine, une des APIs de programmation les plus generiques et haut nivo sous unix. Pour avoir la meme chose avec des apis "plus natives", il faudrait utiliser les APIs kde/gnome, la sdl, Xlib, gstreamer, ... Donc meme si de locale pas mal de ces APIs natives sont mieux concues, globalement elles ne peuvent tout fournir et entraine donc de l'inconsistance (car obliger d'utiliser d'autres choses qui ne fonctionnent pas pareil, ...)
Si ils peuvent "indirectement", winex utilise pas mal de code proprietaire/techno protegees a l'interieur. Par exemple la gestion des protections macromedia, etc...
Et Microsoft peut facilement faire pression dessus ses boites pour attaquer
- quand on quitte la session (menu K / Quitter), ...
Ca ca vient de kde, il detecte si il a ete lancer a partir de *dm ou bien de la ligne de commande, surement configurable dans le control center/login manager.
- Quand on ajoute un "bouton d'application...
Kde aussi, c un bug "connu" mais il ne perd que des confs de placements des icones, etc... (donc rien de bien mechant, mais tres tres chiant)
... Je dois le lancer en ligne de commande avec "xine -A oss ". ...
urpmi xine-alsa
urpmi libalsa2
... la distrib a détecté ma pauvre vieille imprimante ...
JE suis plus sur comment mais cups (le gestionnaire d'impression) supporte bien toutes les imprimantes canon (ptet via un driver binaire)
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).
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.
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.
Il faudrait clairement integrer "le futur Mesa" au coeur de Xfree dans une sorte de "gros pipeline programmable" et coller par dessus des couches d'abstraction/compatibilite X.
Je pense que en pensant bien la chose on doit pouvoir faire ca en chamboulant pas mal l'architecture mais tout en gardant la grand majorite du code (et economiser tout idee utopique de reecriture complete meme partielle).
En fait il a une grosse limite le Fresco/Berlin: il est livrer avec son propre toolkit.
En clair il c'est un gros moteur graphique avec un toolkit livrer de base a l'interieur, les APIs reelement utilisables ne fournissant que des primitives de haut nivo (dans ce cas l'API toolkit).
Autre chose, il est tres oriente effets "Eye candy" au niveau architecture (voir les possibilites de mult-channels/rotations en blending) donc tres eloigne du necessaire pour une utilsation desktop decente.
Pour moi la voie a suivre serait celle prise par les mini-serveurs compatible-X utilises dans l'embarque (comme celui de qnx).
Sachant que wine utilise openGL mais que le support de l'alpha dans la couche D3D n'est que tres minime (partiellement code du moins pour la couche d3d < 7 tout simplement pcque les jeux utilisent peu de ses fonctionnalites)
Etant donne que XFree est base sur un moteur de modules gerant intelligamenet la compatibilite binaire (merci au don de la chose par acceleratedX) le probleme cite ne se posera clairement pas.
Le probleme risquerait plutot que si "Xwin" devien l'implementation de reference du consortium X (ce qui parait bien parti) XFree aura vraiment du mal a suivre les evolutions de protocoles, extensions, ... meme si on peut supposer que l'on ne fasse que des "portages"
Par exemple, xawtv en mode "fullscreen", n'est à ma connaissance disponible que sous XFree.
Ca a rien a voir avec Xfree, c l'extension Xv qui gere ca (et que d'autres serveurs X implementent)
La transparence dans les menus
Ou tu as vu que XFree gerait ca ? Ca n'est pas pcque kde le "fait" que XFree le gere. En principe ca fonctionne en faisant un screenshot de la root window et apres on fait du blending software (donc technique bien horrible). La seule appli qui fait de la vrai transparence c'est enlightenment 0.17 qui fait du pur opengl :)
C pourtant pas dur de comprendre, le code noyau cite est tjs, et sera tjs la dans le 2.5 car:
1 - il est utiliser par la NTPL autant que les NGPT
2 - il peut servir a bcp d'autres choses qui ont besoin d'avoir acces a des primitives de synchro et de controle noyau (du genre la libc)
3 - le peut de code reelement specifique aux NGPT pourra aussi servir a la NTPL dans des evolutions futures
De plus tu ne peut pas dire que NGPT est "inclus" dans le noyau ce qui est totalement faux (NGPT et NPTL sont des patchs pour la libc) mais plutot que le noyau a ete patche avec le support NGPT (des kernels calls necessaires aux threads)
C'est plutot toi qui a ptet pas assez aprofondi tes infos :)
Sache que ce dev "NGPT" est en fait un developpement qui permet a une appli user d'avoir acces a certaines primitives kernel surtout utilise pour des implementations de libs de gestionsde thread (donc sert autant a NTPL que NGPT).
Pkoi il a ete nomme NGPT ? Tout simplement pcque la NTPL avait besoin de bcp moins du kernel que les NGPT (plus eactement le besoin des NGPT contenait aussi le besoin NTPL) donc ils ont fait le necessaire pour le NGPT et au passage pour la NTPL c'etait ok.
C'est NGPT qui n'a pas tenu ces promesses
Comment dire ... renseigne toi un peu. Je peut te dire que d'ici la sortie du 2.6 La NPTL aura implementer les extensions des NGPT (en gros une fusion en bonne et du forme, ce pourquoi IBM fait le forcing) voila pkoi IBM a "abandonne" son proto.
c'est les NGPT (IBM) qui sont une tentative d'ameliorer les posix thread tout restant compatible avec l'existante norme (on pourrait par exemple l'appeler posix thread 2.0 implementation reference si tu prefere) et non les NTPL (actuellement dans ta glibc).
La NTPL c juste une reecriture complete des LinuxThreads (la vraie norme posix actuelle, et ca a fait que du bien).
Et moi je suis partisant des NTPL au sens que c'etait pas possible de continuer avec les LinuxThreads mais je voudrait que la NTPL evolue afin d'implementer les nouvelles APIs de la NGPT (surtout le suspend)
c clair, ca n'etait que la partie noyau qui exporte des primitives necessaires (elles servent partiellement aussi a NPTL), le gros se trouvant dans la libc. Hors il se trouve que les devs de la libc n'ont jamais voulus integrer la NGPT (demander au moins pour le 2.5) et on preferer la NTPL.
Un effet de bord assez rigolo quand j'avais testé la NGPT: les linux-threads d'une appli qui n'utilise pas la NGPT (comme le jdk par exemple, qui ne fonctionne pas du tout avec NGPT et qui donc doit tourner en linux-thread) ne reçoit plus tout les signaux. La fête.
Vi ca c'est un effet de bord facheux de NGPT non integrer dans la libc et sans le nouveau noyau (quoique qu'avec le 2.5 il vaut mieux aussi intgerer les NGPT dans la libc sinon ca devient drole).
Ne soit pas presomptueux, en quoi tu peut dire que tu connait mieux le LL que lui ?
Redhat comme ibm veux la meilleur implémentation thread possible.
La on est d'accord. Maintenant ils ne sont pas d'accord sur laquelle est la meilleure: RH montre ses perfos, IBM montre son architecture.
Redhat a fait un meilleur implémentation.
En quoi tu peut dire ca, tu a regarder le code ? tu as des arguments ?
Pour etre honnete, je pense que la "meilleure" implementation, en terme d'architecture, c les NGPT. Maintenant la "meilleure" au niveau coding/proprete/optimisation c'est les NPTL (lit les docs et regarde le code tu verra de toi meme).
Actuellement redhat préfère ext3 pour le mode ordored et la comptabilité ext2.
Ca a rien a voir avec le schmilblick. RH utilise ext3fs pcque il est compatible avec l'ext2fs (facilite la migration) et que c'est le plus tester et le mieux integrer des fs dans les kernel 2.4 (pour le 2.5 le choix n'est plus aussi simple)
Le free software, c'est la concurrence et après on prend le meilleur pour une tâche donnée.
Ahhh jeune innocent :)
Il y a plein de developpement ibm dans le noyau et on ne dit pas qu'ibm a cherché à imposé leur développement.
hmmm un peu qd meme sur certaines choses (ex: JFS)
Il ont fait un bon taf, personne a fait mieux, donc c'est dans le noyau. C'est aussi simple que ça.
Generalement, aucun groupe ne bosse seul dans un coin. Tous travaillent en commun et donc il y a normallement jamais de projs qui rentrent en conflits. Hors dernierement RH et IBM ont pas mal de projets "conflictuels" appuyes par differentes personnes tierces.
J'aime pas ca, et c pour ca que je le dis. La faute n'etant pas de RH ni d'IBM mais souvent des gros comptes UNIX de ceux-ci (pour RH pas mal de choses sentent la patte de SUN).
De plus, c'est un bench réalisé par le team NGTL. Le bench a été peut-être (je dis bien "peut-être") choisi car il favorise NGTL. C'est de bonne guerre :-)
Le bench qui avait servit pour montrer les gains du passage aux NPTL avait ete fait par RH donc 1-1 :)
Plus serieusement les NPTL sont plus rapide sur un 2.4 et, un peu moins, sur un 2.5 cela pour une utilisation simple des threads. Maintenant dans les cas de gros stress, de bcp de proc, ... c les NGPT qui sont devant sachant qu'elle ne sont pas optimisees (c une sorte de proto alors que les NPTL sont une vrai implementation performante et propre d'un norme)
Mais si NGTL est meilleur, je fais confiance à l'intelligence des developpeurs Linux pour l'utiliser.
En fait je serait pour etendre les NPTL pour implementer les nouveautes NGPT (ca serait le plus propre)
Notes aussi :
- "No changes were made to the kernel patches and thanks to the NPTL effort, all changes required to run NGPT on the latest 2.5.x kernels are already included."
Vi, les dependances de NPTL etait aussi des dependances des NGPT (bien que celle-ci en ait plus)
Enfin pour etre precis, techniquement, on pourrait "fusionner" les NGPT et les NPTL (sachant que la premiere peut s'apparenter a une refonte complete des LinuxThread et la deuxieme a une tentative de nouveau standard posix thread) mais politiquement ca passe pas. (Y a eut pas mal de frittage/pressions au niveau de la libc pour l'integration d'une des solutions)
Maintenant il faut savoir que pour un kernel 2.4 utiliser les NGPT c'est vraiment pas terrible (car utilise pas mal de fonctionnalites des threads reelement utilisable dans le 2.5) alors qu'a l'oposee les NPTL n'utilisent pas les capacites du 2.5 a fond (d'ou le fait que des que l'on augmente le nombre de processeurs, ou qu'on joue avec bcp bcp de threads un gros ecart de perf apparait) bien que dans une utilisation minimaliste la NPTL est plus performante (car plus optimisee que NGPT)
Au final c juste une histoire de "politique", qd il se seront mis d'accord et que le 2.6 sortira je pense que l'on aura un bon hybride des deux (l'optim des NTPL et les nouveautes des NGPT), d'ici la...
Et pour info il n'y a pas incompatibilité binaire en linux-thread, NPTL, NGTL
heureusement a la base ces 3 libs sont toutes des implementations compatible posix thread.
Il faut que les programmes fassent une utilisation Posix des thread
Je me repete mais je croit que tu as tjs pas compris que du aux limitations actuelles de la norme posix thread, certains programmes critiques doivent avoir acces aux internes des implementations (si ca n'etait pas necessaire croit moi que les LinuxThread n'exporterait pas ses interfaces internes). Le seul cas un peu gore c'est valgrind qui doit, en plus d'emuler des calls kernels, emuler les internes des LinuxThreads pour les applis dans le cas sus-cite.
Le bon cote des choses c qu'avec les nouvelles fonctionnalites apportees par les NGPT il n'y aura theoriquement plus d'appli qui aurait besoin d'acceder au internes des implementations.
Si tout est posix, ça tourne indépendament avec linux-thread ou NPTL ou NGTL
Ca peut devenir faux! Si les NGPT deviennent comme le propose IBM la nouvelle norme posix thread (les NGPT sont juste une implementation pour montrer que ca marche, mais elle reste compatible avec l'ancienne qu'elle ne fait qu'etendre) ben un code nouveau Posix (a la NGPT) ne sera plus fonctionnel avec la NTPL
Les "gros" avec 8 cpus utiliseront NGTL les petit NPTL, etc...
Comme dis ci-dessus ca n'est pas aussi simpliste, le choix devrait, pour moi, tjs etre les NGPT mais a condition qu'ils integrent les optims des la NTPL.
[^] # Re: Faire tourner des applications MS sous Linux
Posté par Raphael Junqueira . En réponse à la dépêche Faire tourner des applications MS sous Linux. Évalué à 1.
Surtout que ce sont eux qui ont pousse a ce que wine devienne GPL apres avoir vu que transgaming ne participait pas comme eux.
# Re: Faire tourner des applications MS sous Linux
Posté par Raphael Junqueira . En réponse à la dépêche Faire tourner des applications MS sous Linux. Évalué à 1.
Faux ce n'es pas propietaire: CodeWeavers Wine c la version GPL de wine mieux packagee et pre-configuree (en fonction de ce que tu veux faire, d'ou les 2-3 versions).
[^] # Re: D3D Vs OpenGL
Posté par Raphael Junqueira . En réponse à la dépêche Sortie de WineX 3.0. Évalué à 2.
On est bien d'accord et meme le 1.4 d'ailleurs.
La force d'OpenGL était d'être un standard fort touffu à l'époque, ce qui permet à des vieux OpenGL d'atteindre des fps très impressionnants sur nos machines actuelles (eg: Quake2, Halflife), alors que des vieux jeux D3D (4 ou 5) avec un moteur mal fait reste lents. Désolé, je n'ai pas d'exemple en tête sur ce coup, mais je suis sur que quelqu'un doit en avoir un.
C aussi vrai en OpenGL. Un moteur mal fait sera toujours mal fait que cela soit en openGL ou en DX. Maintenant vu l'archi de l'ancien D3D, c vrai que generalement un moteur mal fait D3D<7 sera encore plus mauvais actuellement.
L'intérêt était donc vraiment d'avoir une surabondance de fonctions, et de les utiliser, même si on savait que cela allait se faire en 'soft', et non en 'hard'.
Je ne suis pas sur le la "surabondance de fonction", car openGL a tjs longtemps eut pleins de fonctionnalites en plus que d3d (surtout splines, ...) qui etaient tres souvent que dispo vai le software et bcp trop souvent inutiles/inutilisables. Directx a tjs plus ou moins suivis les besoins des jeux, modeleurs 3d au fur a mesure.
Sinon il faut savoir que openGL 1.4 supporte tjs plus de fonctionnalites que
d3d via des extensions proprietaires (par exemple les textures_shaders de nvidia ou ati)
Mais bon, vu la frénésie du mondes des cartes graphiques 3D, avec chaque constructeur quiy va de ses innovations, je n'y crois pas trop.
Je ne crois pas que chaque fabricant y aille "de ses innovations". Generalement, ils offrent tjs des innovations tres similiaires qui finissent par convergee en une seule (afin d'eviter betement de decupler le boulot, ils sont pas fous). Et celles qui sont reelement une innovation specifique, si elle est pertinente elle finira par etre adoptee par les autres (par exemples compressions de textures sans pertes, programmation de shaders hardwares, ...)
Mais pour info openGL 2.0, prend la voie prise par direct3d au niveau des nouveautes et de la mise en avant rapide des nouvelles idees. Et au regard des drafts je pense que cela est bien mieux penser que ddraw/direct3d :)
Manque plus que qqu'un fasse des OpenInput,OpenNet,OpenMedia ;)
[^] # Re: Sortie de WineX 3.0
Posté par Raphael Junqueira . En réponse à la dépêche Sortie de WineX 3.0. Évalué à 1.
Non je compare, OpenGL 1.4 a DirectX9. (les dernieres versions des deux APIs).
Microsoft n'est pas un fabriquant de HW
Il m'avait sembler que c'etait le mieux qu'il faisait le HW ;)
Et vu les personnes qui travaillent chez eux sur dx et la xbox, t'inquiete il savent ce qu'ils font (malheureusement d'ailleurs)
je trouve dommage que ça soit eux qui choisissent comment doivent evoluer les choses.
Partiellement vrai, ils ont tjs travailler en collaboration avec les fabricants de cg pour les specs dx. Un peu comme le consortium openGL, sauf que la c microsoft qui tranche.
[^] # Re: Sortie de WineX 3.0
Posté par Raphael Junqueira . En réponse à la dépêche Sortie de WineX 3.0. Évalué à 1.
Pour info, la partie ddraw/d3d ne sera/ne pourra etre jamais partagee car elles ne fonctionnent pas du tout pareil: transgaming simule l'archi driver/HAL de MS alors que wine officiel ne fait qu'une implementation de l'API directx. De plus juste de voir le code d3d de transgaming, j'en veut pas ;)
[^] # Re: Sortie de WineX 3.0
Posté par Raphael Junqueira . En réponse à la dépêche Sortie de WineX 3.0. Évalué à 6.
Ouh la, tu devrait en refaire un peu pour revoir.
Deja D3D ne nivelle jamais par le bas les fonctionnalites des CG, meme pousse les evolutions des cg vers l'avant (regarde d3d9 et les drafts pour d3d9+). Si ta carte ne gere pas un effet dx peut tjs le simuler de facon soft (a condition que ca soit pas trop lent pour celle-ci au quel cas le soft est desactive) ...
De l'autre cote l'openGL ne fournis de base que le strict minimum, des que tu veux faire qques chose soit tu passe par les extension ARB (quand tu fait pas encore du trop pousse), soit tu est oblige (trop souvent) de passer par des extensions proprietaires et la ca devient trop horrible (et souvent du n'importe quoi). De plus comme tu peut pas facilement savoir quelle carte est derriere tu ne peut eviter les bugs specifiques fabricants (car pas possible de desctiver/rebrancher en soft des fonctionnalites simplement)...
Donc ne sort pas les arguments pro-dx contre lui ;)
On est obligé d'utiliser WineX pour faire fonctionner WC3 à cause de DirectDraw, et pas de Direct3D.
Je pensait que s'etait surtout directplay et directinput qui servait. Et la rien n'existe sous unix pour ca (me dites pas sdl).
L'aspect positif de WineX, c'est qu'il accelere l'arrivé de drivers de cg et qu'il permet dans certains cas de se debarrasser de Windows.
Je suis pas sur la. Les drivers cg ne sont reelement arrives que qd sgi a decide de faire du linux et que les gros des effets sepciaux sont passes sous linux.
[^] # Re: WineX CVS ?
Posté par Raphael Junqueira . En réponse à la dépêche Sortie de WineX 3.0. Évalué à -1.
[^] # Re: Sortie de WineX 3.0
Posté par Raphael Junqueira . En réponse à la dépêche Sortie de WineX 3.0. Évalué à -2.
[^] # Re: Sortie de WineX 3.0
Posté par Raphael Junqueira . En réponse à la dépêche Sortie de WineX 3.0. Évalué à 10.
Donc rewind ne sert que d'integrations des patchs bi-licence de wine dans le vieux tree forke (pour pre-intergration winex) et des patchs libres de transgaming a redescendre dans wine (histoire de ne pas trop s'eloigner).
Pas mal de devs (surtout ceux de codeweavers) ont refuse d'etre dans la liste double-licence (et n'e font que des patchs GPLs), d'autres sont en status non definis.
Donc transgaming ne viole en rien la GPL mais par contre va tendre a avoir les couches basses de son "wine" divergees de plus en plus de la version officielle.
[^] # Re: Sortie de WineX 3.0
Posté par Raphael Junqueira . En réponse à la dépêche Sortie de WineX 3.0. Évalué à 10.
La sdl n'a meme pas la moitie des possibilites de DirectX et ca n'importe quel dev de jeux te le diras. Donc si ca peut te faire plaisir, oui on peut faire des trucs avec la sdl mais au prix de pas mal de choses a refaire (ou avoir encore pliens de libs par dessus). D'ailleurs au final elle n'a ete utilisee avec succes que pour des portages de moteur deja grandement generiques/autonomes.
Il est techniquement lamentable d'en venir a "wrapper" tous les appels aux libraries windows afin de les faire tourner sur linux. Pense au gachis de puissance processeur,...
wine(x) n'est pas un "emulateur", ou un simple "wrapper", c'est une reecriture des apis windows. Et dans le cas de directx ca se situe comme la sdl: une suite de libs par dessus x et l'opengl pour faciliter le dev d'applis multimedia. Maintenant si passer par ce que tu considere un "wrapper" je vois pas pkoi tu utilise encore la sdl, l'opengl au lieu d'essayer le code x natif.
Et je ne parle pas de la base de registres, encore consideree parfaite par son createur il n'y a pas si longtemps,
Ca je n'aime pas non plus, personne ne semble vraiment aimer et pourtant on retrouve souvent le meme principe (cf GConf, et autres confs d'applis libres). Enfin un moindre mal celle de wine est encore lisible avec un editeur texte.
Wine ne marche que sur x86.
Partiellement faux, la libwine marche sur de nombreuses plateformes. Pour la partie "runtime/linker windows" elle ne marche bien que sous x86 mais actuellement un projet en plein essort permet deja de faire tourner de simples applis sous PPC.
L'ideal pour moi est la liberalisation du code, quitte a laisser les donnees sous license proprietaire.
Je suis d'accord, mais pour ca faudrait deja que Winex (licence alladin modifiee) n'existe plus mais que seul wine reste (LGPL). Apres on n'a plus qu'a esperer.
Wine y joue un role important, je ne saurais dire de quel cote.
Actuellement c'est surement, via la libwine, une des APIs de programmation les plus generiques et haut nivo sous unix. Pour avoir la meme chose avec des apis "plus natives", il faudrait utiliser les APIs kde/gnome, la sdl, Xlib, gstreamer, ... Donc meme si de locale pas mal de ces APIs natives sont mieux concues, globalement elles ne peuvent tout fournir et entraine donc de l'inconsistance (car obliger d'utiliser d'autres choses qui ne fonctionnent pas pareil, ...)
[^] # Re: Sortie de WineX 3.0
Posté par Raphael Junqueira . En réponse à la dépêche Sortie de WineX 3.0. Évalué à 5.
Et Microsoft peut facilement faire pression dessus ses boites pour attaquer
[^] # Re: Pareil
Posté par Raphael Junqueira . En réponse à la dépêche Un test négatif (mais constructif) de la Mandrake 9.1. Évalué à 4.
Ca ca vient de kde, il detecte si il a ete lancer a partir de *dm ou bien de la ligne de commande, surement configurable dans le control center/login manager.
- Quand on ajoute un "bouton d'application...
Kde aussi, c un bug "connu" mais il ne perd que des confs de placements des icones, etc... (donc rien de bien mechant, mais tres tres chiant)
... Je dois le lancer en ligne de commande avec "xine -A oss ". ...
urpmi xine-alsa
urpmi libalsa2
... la distrib a détecté ma pauvre vieille imprimante ...
JE suis plus sur comment mais cups (le gestionnaire d'impression) supporte bien toutes les imprimantes canon (ptet via un driver binaire)
[^] # Re: Vous etes sur que c'est le bon moment ?
Posté par Raphael Junqueira . En réponse à la dépêche Fork d'XFree86. Évalué à 2.
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.
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.
Il faudrait clairement integrer "le futur Mesa" au coeur de Xfree dans une sorte de "gros pipeline programmable" et coller par dessus des couches d'abstraction/compatibilite X.
Je pense que en pensant bien la chose on doit pouvoir faire ca en chamboulant pas mal l'architecture mais tout en gardant la grand majorite du code (et economiser tout idee utopique de reecriture complete meme partielle).
[^] # Re: Quid de Fresco???
Posté par Raphael Junqueira . En réponse à la dépêche Fork d'XFree86. Évalué à 1.
En clair il c'est un gros moteur graphique avec un toolkit livrer de base a l'interieur, les APIs reelement utilisables ne fournissant que des primitives de haut nivo (dans ce cas l'API toolkit).
Autre chose, il est tres oriente effets "Eye candy" au niveau architecture (voir les possibilites de mult-channels/rotations en blending) donc tres eloigne du necessaire pour une utilsation desktop decente.
Pour moi la voie a suivre serait celle prise par les mini-serveurs compatible-X utilises dans l'embarque (comme celui de qnx).
[^] # Re: Fork d'XFree86
Posté par Raphael Junqueira . En réponse à la dépêche Fork d'XFree86. Évalué à 0.
Sachant que wine utilise openGL mais que le support de l'alpha dans la couche D3D n'est que tres minime (partiellement code du moins pour la couche d3d < 7 tout simplement pcque les jeux utilisent peu de ses fonctionnalites)
[^] # Re: Fork d'XFree86
Posté par Raphael Junqueira . En réponse à la dépêche Fork d'XFree86. Évalué à 6.
Le probleme risquerait plutot que si "Xwin" devien l'implementation de reference du consortium X (ce qui parait bien parti) XFree aura vraiment du mal a suivre les evolutions de protocoles, extensions, ... meme si on peut supposer que l'on ne fasse que des "portages"
Par exemple, xawtv en mode "fullscreen", n'est à ma connaissance disponible que sous XFree.
Ca a rien a voir avec Xfree, c l'extension Xv qui gere ca (et que d'autres serveurs X implementent)
La transparence dans les menus
Ou tu as vu que XFree gerait ca ? Ca n'est pas pcque kde le "fait" que XFree le gere. En principe ca fonctionne en faisant un screenshot de la root window et apres on fait du blending software (donc technique bien horrible). La seule appli qui fait de la vrai transparence c'est enlightenment 0.17 qui fait du pur opengl :)
[^] # Re: Test de la RedHat 9
Posté par Raphael Junqueira . En réponse à la dépêche Test de la RedHat 9. Évalué à 1.
[^] # Re: Test de la RedHat 9
Posté par Raphael Junqueira . En réponse à la dépêche Test de la RedHat 9. Évalué à 0.
Et c clair maintenant ?
[^] # Re: Test de la RedHat 9
Posté par Raphael Junqueira . En réponse à la dépêche Test de la RedHat 9. Évalué à 1.
Y A PAS EUT DE RETOUR ARRIERE!
C pourtant pas dur de comprendre, le code noyau cite est tjs, et sera tjs la dans le 2.5 car:
1 - il est utiliser par la NTPL autant que les NGPT
2 - il peut servir a bcp d'autres choses qui ont besoin d'avoir acces a des primitives de synchro et de controle noyau (du genre la libc)
3 - le peut de code reelement specifique aux NGPT pourra aussi servir a la NTPL dans des evolutions futures
De plus tu ne peut pas dire que NGPT est "inclus" dans le noyau ce qui est totalement faux (NGPT et NPTL sont des patchs pour la libc) mais plutot que le noyau a ete patche avec le support NGPT (des kernels calls necessaires aux threads)
[^] # Re: Test de la RedHat 9
Posté par Raphael Junqueira . En réponse à la dépêche Test de la RedHat 9. Évalué à 1.
Sache que ce dev "NGPT" est en fait un developpement qui permet a une appli user d'avoir acces a certaines primitives kernel surtout utilise pour des implementations de libs de gestionsde thread (donc sert autant a NTPL que NGPT).
Pkoi il a ete nomme NGPT ? Tout simplement pcque la NTPL avait besoin de bcp moins du kernel que les NGPT (plus eactement le besoin des NGPT contenait aussi le besoin NTPL) donc ils ont fait le necessaire pour le NGPT et au passage pour la NTPL c'etait ok.
C'est NGPT qui n'a pas tenu ces promesses
Comment dire ... renseigne toi un peu. Je peut te dire que d'ici la sortie du 2.6 La NPTL aura implementer les extensions des NGPT (en gros une fusion en bonne et du forme, ce pourquoi IBM fait le forcing) voila pkoi IBM a "abandonne" son proto.
[^] # Re: Test de la RedHat 9
Posté par Raphael Junqueira . En réponse à la dépêche Test de la RedHat 9. Évalué à 4.
tu n'a rien compris a ce que j'avait dis :)
c'est les NGPT (IBM) qui sont une tentative d'ameliorer les posix thread tout restant compatible avec l'existante norme (on pourrait par exemple l'appeler posix thread 2.0 implementation reference si tu prefere) et non les NTPL (actuellement dans ta glibc).
La NTPL c juste une reecriture complete des LinuxThreads (la vraie norme posix actuelle, et ca a fait que du bien).
Et moi je suis partisant des NTPL au sens que c'etait pas possible de continuer avec les LinuxThreads mais je voudrait que la NTPL evolue afin d'implementer les nouvelles APIs de la NGPT (surtout le suspend)
[^] # Re: Test de la RedHat 9
Posté par Raphael Junqueira . En réponse à la dépêche Test de la RedHat 9. Évalué à 2.
c clair, ca n'etait que la partie noyau qui exporte des primitives necessaires (elles servent partiellement aussi a NPTL), le gros se trouvant dans la libc. Hors il se trouve que les devs de la libc n'ont jamais voulus integrer la NGPT (demander au moins pour le 2.5) et on preferer la NTPL.
Un effet de bord assez rigolo quand j'avais testé la NGPT: les linux-threads d'une appli qui n'utilise pas la NGPT (comme le jdk par exemple, qui ne fonctionne pas du tout avec NGPT et qui donc doit tourner en linux-thread) ne reçoit plus tout les signaux. La fête.
Vi ca c'est un effet de bord facheux de NGPT non integrer dans la libc et sans le nouveau noyau (quoique qu'avec le 2.5 il vaut mieux aussi intgerer les NGPT dans la libc sinon ca devient drole).
[^] # Re: Test de la RedHat 9
Posté par Raphael Junqueira . En réponse à la dépêche Test de la RedHat 9. Évalué à 1.
Ne soit pas presomptueux, en quoi tu peut dire que tu connait mieux le LL que lui ?
Redhat comme ibm veux la meilleur implémentation thread possible.
La on est d'accord. Maintenant ils ne sont pas d'accord sur laquelle est la meilleure: RH montre ses perfos, IBM montre son architecture.
Redhat a fait un meilleur implémentation.
En quoi tu peut dire ca, tu a regarder le code ? tu as des arguments ?
Pour etre honnete, je pense que la "meilleure" implementation, en terme d'architecture, c les NGPT. Maintenant la "meilleure" au niveau coding/proprete/optimisation c'est les NPTL (lit les docs et regarde le code tu verra de toi meme).
Actuellement redhat préfère ext3 pour le mode ordored et la comptabilité ext2.
Ca a rien a voir avec le schmilblick. RH utilise ext3fs pcque il est compatible avec l'ext2fs (facilite la migration) et que c'est le plus tester et le mieux integrer des fs dans les kernel 2.4 (pour le 2.5 le choix n'est plus aussi simple)
Le free software, c'est la concurrence et après on prend le meilleur pour une tâche donnée.
Ahhh jeune innocent :)
Il y a plein de developpement ibm dans le noyau et on ne dit pas qu'ibm a cherché à imposé leur développement.
hmmm un peu qd meme sur certaines choses (ex: JFS)
Il ont fait un bon taf, personne a fait mieux, donc c'est dans le noyau. C'est aussi simple que ça.
Generalement, aucun groupe ne bosse seul dans un coin. Tous travaillent en commun et donc il y a normallement jamais de projs qui rentrent en conflits. Hors dernierement RH et IBM ont pas mal de projets "conflictuels" appuyes par differentes personnes tierces.
J'aime pas ca, et c pour ca que je le dis. La faute n'etant pas de RH ni d'IBM mais souvent des gros comptes UNIX de ceux-ci (pour RH pas mal de choses sentent la patte de SUN).
[^] # Re: Test de la RedHat 9
Posté par Raphael Junqueira . En réponse à la dépêche Test de la RedHat 9. Évalué à 1.
Le bench qui avait servit pour montrer les gains du passage aux NPTL avait ete fait par RH donc 1-1 :)
Plus serieusement les NPTL sont plus rapide sur un 2.4 et, un peu moins, sur un 2.5 cela pour une utilisation simple des threads. Maintenant dans les cas de gros stress, de bcp de proc, ... c les NGPT qui sont devant sachant qu'elle ne sont pas optimisees (c une sorte de proto alors que les NPTL sont une vrai implementation performante et propre d'un norme)
Mais si NGTL est meilleur, je fais confiance à l'intelligence des developpeurs Linux pour l'utiliser.
En fait je serait pour etendre les NPTL pour implementer les nouveautes NGPT (ca serait le plus propre)
Notes aussi :
- "No changes were made to the kernel patches and thanks to the NPTL effort, all changes required to run NGPT on the latest 2.5.x kernels are already included."
Vi, les dependances de NPTL etait aussi des dependances des NGPT (bien que celle-ci en ait plus)
[^] # Re: Test de la RedHat 9
Posté par Raphael Junqueira . En réponse à la dépêche Test de la RedHat 9. Évalué à 2.
Maintenant il faut savoir que pour un kernel 2.4 utiliser les NGPT c'est vraiment pas terrible (car utilise pas mal de fonctionnalites des threads reelement utilisable dans le 2.5) alors qu'a l'oposee les NPTL n'utilisent pas les capacites du 2.5 a fond (d'ou le fait que des que l'on augmente le nombre de processeurs, ou qu'on joue avec bcp bcp de threads un gros ecart de perf apparait) bien que dans une utilisation minimaliste la NPTL est plus performante (car plus optimisee que NGPT)
Au final c juste une histoire de "politique", qd il se seront mis d'accord et que le 2.6 sortira je pense que l'on aura un bon hybride des deux (l'optim des NTPL et les nouveautes des NGPT), d'ici la...
Et pour info il n'y a pas incompatibilité binaire en linux-thread, NPTL, NGTL
heureusement a la base ces 3 libs sont toutes des implementations compatible posix thread.
Il faut que les programmes fassent une utilisation Posix des thread
Je me repete mais je croit que tu as tjs pas compris que du aux limitations actuelles de la norme posix thread, certains programmes critiques doivent avoir acces aux internes des implementations (si ca n'etait pas necessaire croit moi que les LinuxThread n'exporterait pas ses interfaces internes). Le seul cas un peu gore c'est valgrind qui doit, en plus d'emuler des calls kernels, emuler les internes des LinuxThreads pour les applis dans le cas sus-cite.
Le bon cote des choses c qu'avec les nouvelles fonctionnalites apportees par les NGPT il n'y aura theoriquement plus d'appli qui aurait besoin d'acceder au internes des implementations.
Si tout est posix, ça tourne indépendament avec linux-thread ou NPTL ou NGTL
Ca peut devenir faux! Si les NGPT deviennent comme le propose IBM la nouvelle norme posix thread (les NGPT sont juste une implementation pour montrer que ca marche, mais elle reste compatible avec l'ancienne qu'elle ne fait qu'etendre) ben un code nouveau Posix (a la NGPT) ne sera plus fonctionnel avec la NTPL
Les "gros" avec 8 cpus utiliseront NGTL les petit NPTL, etc...
Comme dis ci-dessus ca n'est pas aussi simpliste, le choix devrait, pour moi, tjs etre les NGPT mais a condition qu'ils integrent les optims des la NTPL.